All site contents ©2017 Casey Connor unless otherwise noted.

Diagnosing DNS-sourced SPF problems

Last Updated: Wednesday, 17 September 2014

So, your outgoing messages are failing SPF, or your own SPF verifier is failing message for no good reason, and you want to figure out why? It might be the DNS of the sending domain.

Example domain here is, e.g.,, which once had DNS troubles. Domains like will not be covered here, but the process is similar (if a bit more complicated.)

If DNS lookups fail or timeout or otherwise get weird, your software might map the SPF results to "fail" (this behavior may be correct if there is a "ptr" mechanism being used, more on that below). A good verifier knows better, but it's up to the implementer to make this distinction (and up to you to utilize the information which your verification code provides.)

Before suspecting DNS problems, confirm that they have a valid SPF record.

You can retrieve the SPF record with:

$ host -t txt descriptive text "v=spf1 a mx ip4: ~all"

But it's probably easier to use the first form at

(fill in the domain only and hit "Get SPF record"... it shouldn't give any errors. (If there is no SPF record, you can skip down to the DNS section.)

Now use the second form at that link. In the fields, fill in "" and the contents of the quoted string above: v=spf1 a mx ip4: ~all

The output includes:

The result of the test (this should be the default result of your record) was, ambiguous . The explanation returned was, SPF Ambiguity Warning: No MX records found for mx mechanism:

...their SPF record is strange: the two spaces before "~all" aren't a problem, but they should probably remove, and replace for If was actually a different IP, their record as-is could cause mail from "" sent from a IP to fail SPF, since it's IP is not properly included. However, it turns out that has the same IP as, so the whole entry is redundant as well. Additionally, the IP specified is identical to their mx, and in fact their A record as well. Their record should probably just be:

v=spf1 a ~all

...or better, because it will save a lookup:

v=spf1 ip4: ~all

Likely a case of someone not knowing what they were doing filling in a lot of stuff to be sure, or adding it all in just in case it changes in the future. In the latter case, this would suffice:

v=spf1 a mx ip4: ~all

...although it wouldn't be as efficient for resolvers on the other end because it's saying the same thing three times (a==mx==

Trying the third form at, we can put in actual values from the email that failed, or we can make up our own. I will make up our own for this example:

IP address: (You can get this from "dig +short" or "host") SPF Record: (paste in the real record you extracted already for the form) Mail from address: HELO/EHLO Address:

Submit the form and see what happens. In this example, it would pass, despite their redundant and misconfigured SPF record.

Most mail servers also require a "FCRDNS" -- a validating PTR record for the IP: take the IP of the sending mail server (from the Received header of the message) and do a reverse lookup. It will return one or more host names. One of those host names must resolve back to the IP. You may as well let the form above take care of that checking for you.

If there is a "ptr" mechanism in the SPF record (they are almost always advised against) then the PTR records discovered by the DNS lookup must additionally match or end with the domain in question in order for the "ptr" mechanism to match. Note: a DNS error when looking up the PTR records will make the "ptr" mechanism not match. A DNS error when looking up the A records for any domains discovered in the PTR lookup simply means those domains will not be able to be used as possible matches.

If SPF all checks out on the form, but not in your system, there may still be problems with DNS causing failures or intermittent failures in one place (your system) but not another (the SPF checking form website).

If you want to see if the domain lookups are failing on your system, you can check whatever logs you keep for timeouts. You might also scan /var/log/messages on your nameserver machine(s) for this kind of output (obviously, your logs may look different):

Aug 16 04:16:16 app002 named[16870]: lame server resolving '' (in ''?): Aug 16 04:16:16 app002 named[16870]: lame server resolving '' (in ''?):

In these logs, the IP at the end is the nameserver (usually one of the TLD zone nameservers) that "named" was working with, but it doesn't tell you the IP of the server that is "lame".

Note that depending on your logging and what your MX is handling, there could be lots of these messages in /var/log/messages, and you may see lots of timeouts in whatever logs you keep. This is usually normal (spammer domains, mostly.)

Let's check out the DNS records:

$ dig +trace ; <<>> DiG 9.5.1-P2 <<>> +trace ;; global options: printcmd . 13344 IN NS . 13344 IN NS . 13344 IN NS . 13344 IN NS . 13344 IN NS . 13344 IN NS . 13344 IN NS . 13344 IN NS . 13344 IN NS . 13344 IN NS . 13344 IN NS . 13344 IN NS . 13344 IN NS ;; Received 228 bytes from in 59 ms com. 172800 IN NS K.GTLD-SERVERS.NET. com. 172800 IN NS J.GTLD-SERVERS.NET. com. 172800 IN NS A.GTLD-SERVERS.NET. com. 172800 IN NS E.GTLD-SERVERS.NET. com. 172800 IN NS L.GTLD-SERVERS.NET. com. 172800 IN NS G.GTLD-SERVERS.NET. com. 172800 IN NS D.GTLD-SERVERS.NET. com. 172800 IN NS F.GTLD-SERVERS.NET. com. 172800 IN NS I.GTLD-SERVERS.NET. com. 172800 IN NS C.GTLD-SERVERS.NET. com. 172800 IN NS M.GTLD-SERVERS.NET. com. 172800 IN NS H.GTLD-SERVERS.NET. com. 172800 IN NS B.GTLD-SERVERS.NET. ;; Received 487 bytes from in 73 ms 172800 IN NS 172800 IN NS ;; Received 110 bytes from in 239 ms 3600 IN A ;; Received 43 bytes from in 89 ms

Note the first two ns* lines: these are the nameservers that the "com" nameservers lists for the zone. As it happens with this particular domain, isn't responding, and if you ran the dig command and the resolver happened to chose "ns" instead of "ns2" (the nameserver in parenthesis on the last line was the nameserver responding with the IP) the end of the above output would list a failure instead of listing the IP. Anyway, let's check each nameserver individually to see if it responds (there may be a lot in the list; in this case there are only two. Watch out for unexpected but common vs. discrepancies, etc.)

$ dig +short $ dig +short ; <<>> DiG 9.5.1-P2 <<>> +short ; (1 server found) ;; global options: printcmd ;; connection timed out; no servers could be reached

Aha, is not responding. This will cause DNS failures (and possibly inappropriate SPF failures as a result) when checking SPF for this domain.

Let's also see if there are any SOA issues ("Start of Authority", a type of DNS record). Valid SOA is not a requirement of SPF, but without it the domain will likely have problems in general.

$ host -C host: couldn't get address for 'webserver': not found

...looks like a problem. Normally, something like this comes back:

$ host -C Nameserver has SOA record 1250735855 16384 2048 1048576 2560 Nameserver has SOA record 1250735855 16384 2048 1048576 2560

This is likely the culprit:

$ dig -t SOA +short webserver. hostmaster. 11 900 600 86400 3600

Compare to:

$ dig -t SOA +short 1250735855 16384 2048 1048576 2560

...I don't know enough about DNS to really call that out as "wrong", but I'm pretty sure it is.