In this tutorial, you will learn the steps to troubleshoot some of the most frequent errors and problems while setting up an SPF record for your emails.
List of Errors:
This issue is related to the DNS query time. If a server is unable to connect to your DNS to resolve some of the TXT records, then this particular error message appears. This can be a temporary network connectivity or DNS load issue also.
In case, you're receiving this message too frequent then you should contact your NameServer provider immediately to troubleshoot this problem. Having too many timeout issues especially when someone is querying your SPF, DKIM or DMARC record may impact your email deliverability.
This is the most common problem while configuring an SPF record. As per RFC specification, each domain may have only one SPF record entry in their DNS record. If your domain contains multiple SPF entries, then the entire bunch of values in the SPF record will be treated as invalid by the recipient mail server.
How to know whether my domain contains multiple SPF record?
If you're a linux user, then you can run a simple 'dig' command from your terminal.
dig TXT example.com
This will return all the TXT records associated with your domain example.com. Not all TXT records are SPF, only TXT values starting with v=spf1 or v=spf2 are the ones which are representing the SPF record.
Generally, when people migrate between two email service providers, they end up making this mistake of adding two separate SPF entry in TXT.
If you're using two or more service providers for sending emails, then make sure all the records are merged into one SPF record in your DNS. Below is an example of multiple SPF record in TXT, which is invalid to have:
dig TXT example.com v=spf1 a mx include:pepipost.net -all v=spf1 a mx include:spf.mtasv.net -all v=spf1 a mx ip4:126.96.36.199 -all
The correct version of the above SPF should be:
v=spf1 a mx include:pepipost.net include:spf.mtasv.net ip4:188.8.131.52 -all
Summarizing the solution, either delete the records of the service providers which are not in use or else merge all of them in one record like the one above. When merging the records make sure that the SPF starts with "v=spf1" and ends with "~all" or -all parameter.
As per RFC specifications, one SPF record should be limited to 10 DNS lookups. Each "include" statement in the SPF record is actually one DNS lookup. However, there can be cases where the domain or a sub-domain mentioned in the include statement is again having some set of include statements in its SPF record. This will overall may result in the increase in the recursive lookups originating from your domain.
The recipient server generally performs up to 10 DNS lookups (including the recursive ones) to authenticate the association of a delivery IP address with the SPF record. Each instance of parameters "a", "include", "mx", "exists", "ptr", "redirect" will generate one lookup. However, if the lookups are more than 10, then you might start getting the "Too many DNS lookups" error.
In such a scenario your SPF will start failing with the recipient server which may impact your email deliverability rates too.
The only solution to this problem is to reduce the referencing to too many recursive lookups or by removing unused include statements from the SPF record.
Alternatively, you can use subdomains from sending different email streams. This will help you distribute multiple include statements in one SPF record across many sub-domains.
If you're sending many different streams of emails, then it is always recommended to segregate your mail streams between different sender domains. Example; you can send your transactional emails using example.com but for marketing emails, you should use offers.example.com or mail.example.com and so on.
Here is an example of a main domain's SPF:
maindomain.com "v=spf1 include:record1 include:record2 include:record3 include:record4 include:record5 include:record6 -all"
Now based on the requirement, you can break SPF's into following:
trans.maildomain.com: "v=spf1 include:record1 include:record2 -all" offers.maildomain.com: "v=spf1 include:record3 include:record4 -all" alerts.maildomain.com: "v=spf1 include:record5 include:record5 -all"
While merging or creating new SPF records, make sure the SPF record starts with “v=spf1” and ends with “~all”, “-all” or “?all”. Don't include multiple v=spf1 or all in the record.
"+" sign as a prefix in the include statement indicates that if the email is coming from the IP addresses mentioned in the include, then the SPF should be considered as pass. Having said that, the default meaning of "include" parameter is PASS. So, there is no explicit requirement to add "+". Removing the "+" sign will fix this problem without affecting the SPF PASS logic.
Avoid making any typos with the word "include", else your SPF will start failing.
If you're getting SPF Alignment Failed error, then this is because of your defined DMARC policy.
In a DMARC policy, the ASPF tag indicates the owner's preference for SPF alignment. Similar to ADKIM tag in DMARC policy, the ASPF tag can be used and set to relaxed (r) or strict (s) modes.
SPF will be successfully aligned to DMARC only when the Mail-From/ Return-Path address and the Header/Visible “From” address domains are same.
The default value for ASPF is relaxed (r).
Here is an example of an ASPF tag in the DMARC:
v=DMARC1; p=quarantine; pct=25 ; rua=mailto:[email protected]; aspf=strict;
In case, you found an error with SPF which is not covered in this tutorial, then please feel free to share the details below in comments.