Menu
Menu
If you see this error, one of the “rua” or “ruf” email addresses in your report does not have a DNS TXT record verifying that they wish to receive DMARC reports for your domain.
If you want to send your DMARC reports to a domain other than the one that the record is for, then the recieving domain needs to configure a DNS record so that Email Serivce Providers know that the recipient is authorizing the the reports.
From RFC-7489
Verifying External Destinations
It is possible to specify destinations for the different reports that are outside the authority of the Domain Owner making the request. This allows domains that do not operate mail servers to request reports and have them go someplace that is able to receive and process them. Without checks, this would allow a bad actor to publish a DMARC policy record that requests that reports be sent to a victim address, and then send a large volume of mail that will fail both DKIM and SPF checks to a wide variety of destinations; the victim will in turn be flooded with unwanted reports. Therefore, a verification mechanism is included.
For example: If your domain is domain.com and you want to send your reports to mxtoolbox.dmarc-report.com, then the recipient domain (in this case MxToolbox) needs to have a TXT DNS record domain.com._report._dmarc.mxtoolbox.dmarc-report.com which has the content v=DMARC1.
Note: This record is something that the recipient of your DMARC reports needs to configure.
In the majority of cases the recipient domain will create a wild card record, which essentially means the domain is willing to receive DMARC reports for ANY domain. A wildcard record would look like this: *._report._dmarc.example.com with a value of “v=DMARC1”
When you configure MxToolbox to receive your DMARC reports, we are automatically setup to receive your reports.
From RFC 7489 in Section 6.6.3 Policy Discovery
If the remaining set contains multiple records or no records, policy discovery terminates and DMARC processing is not applied to this message.
This Warning indicates that the DMARC record for this domain is not currently protected against phishing and spoofing threats. To resolve this Warning you will need to set a Quarantine or Reject policy on the domain’s DMARC record. Setting a Quarantine or Reject value will prevent fraudsters from spoofing the domain as mail servers will Quarantine or Reject messages that fail authentication tests.
Note: It is advised to not set a Quarantine or Reject policy until you have evaluated your DMARC reports to make sure you don’t have any legitimate senders that have email delivery problems.
A name server will no longer consider itself Authoritative if it hasn’t been able to refresh the zone data in the time limit declared in this value.
Why you need authoritative servers
Additional Information
Each DNS host has their own interface, but you are looking for either a setting labeled Expire Value or you might have to enter your SOA details manually. If you have to enter your SOA then the Expire value will be second to last number in the SOA.
Your DNS records are hosted on two or more DNS servers that are supposed to be in regular contact with each other so that they have up to date copies of your DNS records. The Expire Value setting tells each slave server how long it is allowed to continue giving out authoritative replies after it has no longer heard from the master server.
The serial number is an unsigned 32 bit value assigned to your SOA record must be between 1 and 4294967295.
We will issue a warning if your serial is either invalid by being outside of the allowed range or if it does not conform to this format.
It has become common to set your serial number with a date format to make it easier to to manage. This format uses 10 digits to represent the date and then a two digit sequence number with the format of YYYYmmddss.
This value configures how often a name server should check it’s primary server to see if there has been any updates to the zone which it does by comparing Serial numbers. We issue a warning if it is less than 20 minutes or greater than 12 hours.
Receiving this warning does not mean that your DNS is failing, but may indicate the set SOA Refresh Value is causing your name servers to not be performing as optimally as recommended. This test will warn you if your name server is checking more or less frequently than recommended, as you may be using a high volume of bandwidth or not checking for updates frequently enough.
If we detect that you have more than one name server in the same class C subnet (the first three numbers of their IP are the same), we will issue this warning.
Having more than one (1) name server in the same class C subnet is not recommended, as this increases the likelihood of a single failure disabling all of your name servers.
If your servers are actually dispersed or you have other means in place to generate redundancy in your DNS, you can feel free to filter this warning with our Custom Filters settings.
An error occurred when we tried to resolve your hostname via a DNS Server.
Under normal circumstances, when an http hostname is requested (e.g. example.com typed into your browser), the request goes out to a DNS server and gets converted into an ip address.
This problem is usually followed by a HTTP Connect failure.
Try running a DNS Lookup on your domain to see if there are any issues with your DNS servers.
If you have a monitor configured on MxToolbox, you can perform the lookup on our server. You can then view the monitor’s history to see when and what the exact cause of the problem might be. Also, if you are a paid customer, you can request support from us and we’d be happy to help explain the results.
We were unable to connect to your server.
When the http address is checked by our servers, we wait a standard 15 seconds for a response. If we do not detect a response, this error will be triggered.
Under normal circumstances, when an http hostname is requested (e.g. example.com typed into your browser), the request goes out to a DNS server and gets converted into an ip address.
Your request can fail in two ways. Either the hostname could not resolve into an ip or the address simply does not exist.
If the problem was due to your hostname not resolving into an IP Address, there will also be a HTTP DNS problem listed as well.
The SMTP banner issued by your email server did not contain the hostname we resolved for your server’s IP address.
Email servers answer connections on port 25 with a string of text called an SMTP Banner whose purpose is to announce the server and any information that the administrator would like to convey to the world.
It is best practice to put the name of your server in your SMTP banner so that anybody who connects via your IP Address has a clue as to who they are talking to. You will get this warning if the name you present yourself as is not in the same domain as the hostname we get when we perform a PTR lookup on your IP Address.
For a time many servers would “mask” their SMTP banners by replacing the characters with asterisks to anybody outside of their network. The logic behind this was often that you did not want to broadcast any information about your network to people outside for fear of giving them any information that might help them in an attack against your server. The benefits of doing this are minimal and many servers perform a banner check as part of spam mitigation, so it has a negative cost associated with the practice. Our tool will issue a warning if your banner is masked.
Some receiving mail servers may use a mismatched or masked banner as an indication of a possible spam source in a scoring system, but most will not reject incoming mail solely on this basis.
If you do not have a PTR record, or your record does not match your hostname, we recommend that you contact your ISP and ask them to setup a reverse (PTR) record that matches the hostname of your mail server.
Your SMTP email server does advertise support for TLS. After connecting to your mail server we issue an EHLO command to introduce ourselves and to request that your server announce which commands and protocols it supports. Your server’s response did not include “250-STARTTLS” indicating TLS support.
TLS stands for Transport Layer Security and allows email servers to exchange emails over an encrypted connection using the same type of mechanism as HTTPS uses to secure websites. In all but a few cases, you should still be able to send and receive email but your messages will be transmitted in plain text without TLS encryption.
We were able to connect to your mail server on port 25, but the connection took much longer than expected. This could indicate that your email server is under heavy load.
Here are the levels for which we issue warnings and alerts:
Having this warning on your lookup does not necessarily mean that you will have a problem receiving mail. It is simply a warning that things are less than optimal. This could end up causing users to experience delays with inbound mail.
It is also possible your server is “Tar pitting.” Tar pitting is a technique used by some email servers to slow down spammers. The idea is that legitimate senders will wait longer to establish a connection than spammers will.
Here is a link to a link to the TechNet article with more information about Tarpitting
Here are the levels for which we issue warnings and alerts:
Having this warning on your lookup does not necessarily mean that you will have a problem receiving mail. It is simply a warning that things are less than optimal. This could end up causing users to experience delays with inbound mail.
During our diagnostics we attempt to simulate sending a message to a fake email address. We do this to try to detect if your server is an open relay, which means that it accepts mail to domains for which it is not responsible and then passes it along to the proper server. Your server responded with a 200-accepted code to our RCPT TO command. This does not mean you are operating an open relay, only that you may be an open relay.
Many servers now pretend to accept incorrectly addressed email but then discard those message without forwarding them. This technique is used to prevent a directory harvest attack. In a directory harvest attack a spammer will attempt to send to thousands of email address at your domain trying to find real ones. When your server responds with an error (5xx), the spammer knows that it is not a real email address. When your server accepts the message (2xx), the spammer knows that was a real email address.
We were unable to perform a reverse lookup (PTR) on the IP Address of your mail server. This is a problem because many organizations will not accept email from a server without a PTR record.
We recommend performing a Reverse Lookup on the IP Address for your mail server to try to find the cause of the error. You will need to contact your ISP and ask them to setup a correct PTR record for you. You should ask that this record be the same as the hostname of your mail server. We also recommend configuring your server to include this name in your SMTP banner.
When a sending server makes a connection to the recipient server, the recipient server notes the sending IP address and performs a reverse lookup, called a PTR lookup, named after the type of DNS record used. If the result of the reverse lookup matches the result of a forward DNS Lookup, then it’s much more likely that the message is legitimate. If the IP address doesn’t match, it’s much more likely that the sending address was spoofed and therefore much more likely that it’s unwanted and could be considered spam.
An additional test that can be performed is an SMTP Banner check which compares the hostname announced by the server upon initial connection with the forward and reverse lookups.
Only the organization which controls an IP can configure PTR records. PTR record queries are sent to the owner of the IP address which is the ISP, unlike other DNS queries which are sent to the DNS server of whoever owns the domain.
The forward lookup (A) of the hostname hostname did not match the reverse lookup (PTR) for the IP Address.
Some receiving mail servers may use this as an indication of a possible spam source in a scoring system. Most will not reject incoming mail solely on this basis. We recommend that you contact your ISP and ask them to setup a reverse record (PTR) that matches the hostname of your mail server.
Your SPF record required more than 10 DNS Lookups to be performed during the test. The number of “include” mechanisms and chained “redirect’ modifiers should be kept to a minimum.
According to RFC 7208, ‘SPF implementations MUST limit the number of mechanisms and modifiers that do DNS Lookups to at most 10 per SPF check, including any lookups caused by the use of the “include” mechanism or the “redirect” modifier”‘. The mechanisms of: “include”, “mx”, “a”, “ptr”, and “exists” count against the limit of 10 lookups. The “all, “ip4”, and “ip6” mechanisms do not count against the limit of 10 since they do not require a DNS Lookup.
SPF implementations should restrict the number of DNS Lookups to 10 per check in order to explicitly limit how much data will be accepted to:
If you use the “include” in your SPF record, it will have referenced SPF records evaluated with your SPF record and as a direct result the DNS Lookup count is dependent upon third parties. If you are close to reaching your limit of 10 DNS Lookups and someone in your “include” adds additional DNS records to their own SPF record, you could easily go over your limit of 10.
This test will perform an SPF check against the given domain and IP address to verify that the IP is included in the SPF record. If the specified IP address is not included in the SPF record this test will produce an error.
Hostname returned invalid syntax for SPF record. We detected a problem with the syntax of your SPF record. This may cause email delivery issues to your message recipients.
A syntax error is the result of having one of more misconfigured mechanisms that do not meet guidelines in RFC 7208. This error will cause your SPF record to be read incorrectly and block legitimate email.
Common SPF syntax errors are:
Full list of SPF Mechanisms and examples
A hidden syntax error can make it very difficult to know why messages are being blocked, as SPF is used by all mail servers to authenticate the sender and the resulting block error may not specify that it is an SPF Record Syntax issue that is causing the problem.
If you are on the UCEPROTECTL2/L3, you have an IP address from your ISP that falls into a poor reputation range (i.e., the entire range of IP addresses is blocked as a result of the provider hosting spammers).
About Blocklist Reliability:
MxToolbox receives many questions about the reliability of certain blocklists. MxToolbox opts to try to educate users on the potential impact of lists over removing a list from our tool. If you are troubleshooting an email issue, regardless of whether it is a good idea for the recipient to use a particular blocklist to evaluate inbound email, users should be aware that they are listed. Otherwise, someone might run a check trying to resolve a problem and get an ‘all good’ result, then move on when really they are having a problem with an obscure or unreliable blocklist that is being used by their recipient.
If you are having email delivery problems, we recommend checking with the recipient if they are using a list and if the MxRep score for that list is very low. A low MxRep score means our evaluation is that few inbox providers use this list to evaluate inbound email.
Paying for Delisting:
MxToolbox does not ever recommend paying for delisting. This usually only removes you for a short time and does not resolve the problem. We recommend that you evaluate any list that you appear on and determine if your recipients may be using that list. If you do not have bouncebacks referencing a specific list or that you are being blocked due to a blacklisting, we recommend exploring other avenues.
Subnet-based Blacklists are used to reject email from entire ranges of IP Addresses, i.e. providers that are hosting companies sending spam, as well as single IP Addresses that may fall in that range of IP Address.
Host-reputation Blacklists will list either single IP Addresses that host multiple domains or entire ranges of IP Addresses from DNS &/or Email Hosts that host email for their registered domains on shared email servers. When one company sends Spam Mail or Unsolicited Bulk Email (UBE), the entire ranges can be reported as blacklisted.
Spam-based Blacklists are those that will list either single IP Addresses or entire ranges that have actually received Spam, i.e. Unsolicited Bulk Email (UBE) in their Spamtraps from an IP-Address. This could be a result of a compromised email account, an Open Relay, or simply sending mass emails / marketing and not following best practices according to the “CAN-SPAM Act of 2003” (ref: https://en.wikipedia.org/wiki/CAN-SPAM_Act_of_2003)
This blacklist does not offer any form of manual request to delist. Your IP Address will either automatically expire from listing after a given timeframe, or after time expires from the last receipt of spam into their spamtraps from your IP Address.
This blacklist does support a manual request to remove, delist, or expedite your IP Address from their database upon Payment or Donation of fees to their organization. Please note the following; 1) MxToolBox does not in any way advocate the paying of removal from any blacklists. 2) Removal requests that are submitted without addressing the core problem will likely result in your IP Address being relisted in the database which can cause subsequent problems and extended listing periods without release.
More information about UCEPROTECTL3 can be found at their website: http://www.uceprotect.net
A listing by SPFBL DNSBL indicates that the IP address has been identified as unsuitable for sending email. SPFBL lists IP addresses that have sent spam, as well as IPs that are not configured correctly to send email. SPFBL is a Brazilian blacklist that primarily focuses on reducing the volume of Brazilian spam. It was created in late 2015 and was opened up for use by any MTAs to block spam sources and IPs unsuitable for sending mail.
This blacklist does support a manual request to remove or delist your IP Address from their database. Please note that removal requests that are submitted without addressing the core problem will likely result in your IP Address or Domain being relisted in that database, which can cause subsequent problems and extended listing periods without release.
This blacklist does support a manual request to remove, delist, or expedite your IP Address from their database upon Payment or Donation of fees to their organization. Please note the following; 1) MxToolBox does not in any way advocate the paying of removal from any blacklists. 2) Removal requests that are submitted without addressing the core problem will likely result in your IP Address being relisted in the database which can cause subsequent problems and extended listing periods without release.
More information about SPFBL DNSBL can be found at their website: http://www.spfbl.net/dnsbl/english/index.html