SPF validation is important for a better email deliverability rate and for protecting your domain from phishing and spam attacks. However, SPF settings are complicated and you can go wrong while configuring them. Fixing and avoiding these common errors ensure there are no false positives and DMARC compliances properly to your email-sending domain.
7 Common Mistakes To Avoid When Configuring SPF Settings
Some DNS mechanisms are used to state the IPs of systems permitted to send emails with an e-mail return path address. But their incorrect usage causes errors like- exceeding the size of the SPF record, more than 10 DNS lookups, more than 2 unresolved DNS lookups, etc.
We’ve listed common SPF errors to help you avoid them when configuring SPF settings.
Mistake 1: Multiple SPF Records
There should be one SPF entry per domain, otherwise receiving servers will decline both. Remove SPF entries that aren’t currently in use, for example- obsolete services with active SPF entries.
You can resolve this SPF setting mistake by merging two or more records into one. Let’s say a user domain has an SPF record and includes an Elastic Email SPF entry but doesn’t pass verification checks. The possible reason for this is having 2 records present on the domain.
v=spf1 a mx include:_sampledomain1.com include:_spf.elasticemail.com ~all
v=spf1 a mx include:_sampledomain2.com ~all
You can resolve this by merging them into a single record like:
v=spf1 a mx include:_sampledomain1.com include:_sampledomain2.com include:_spf.elasticemail.com ~all
Mistake 2: Too Many DNS Lookups
There’s a limit of 10 ‘include’ lookups which mean you can’t generate more than 10 references to other domains. Every occurrence of parameters “include”, “a”, “mx”, “ptr”, “exists”, and “redirect” generates a lookup. Moreover, if a domain referred to in an ‘include’ contains another parameter, it’ll also be counted towards the 10 lookup limit. So, exceeding the lookup limit is one of the most common errors to happen while configuring SPF settings.
You can fix this remove ‘includes’ and references to inactive domains.
Mistake 3: Permissive all Mechanism
An SPF record is interpreted from left to right, and the ‘all’ mechanism will match the ‘all’ senders that didn’t match the preceding mechanisms. It’s suggested to place the ‘all’ mechanism at the end of your SPF record, and use it with the ~ (softfail) or – (fail) prefix. When no prefix is set, the + (pass) is used by default.
Mistake 4: The Use of the ptr Mechanism
The SPF ‘ptr’ mechanism is used for reverse DNS lookup that returns the hostname to its corresponding IP address. This information is helpful to B2B brands in particular. But this mechanism has reliability issues and causes a burden on the reverse DNS servers and email systems connected to them.
That’s why RFC7208 discourages the use of the ‘ptr’ mechanism. In the majority of cases, you can replace it with the ‘a’ mechanism.
Mistake 5: The Use of mx Mechanism
Use ‘mx’ with domain names and not mail server names. Stating mx:mailserver.sample.com is considered incorrect unless you actually require SPF validation to look up all the hosts accepting mail for the ‘mailserver.sample.com’ domain. In most cases, there won’t be any such hosts as ‘mailserver.sample.com’ is itself a host and not a domain.
You won’t come across this as a syntax error, but it won’t simply match anything.
The correct way for validating against the MX record for ‘sample.com’ is mx:sample.com. When you’ve to define a certain mail server’s hostname or IP address, a:mailserver.sample.com or ip4:x.x.x.x should be used
Mistake 6: Creating an SPF Record Without Proper Research
This is especially for ISPs. Don’t create records with half information about the domain, its owner, and the brand it belongs to. Research what email server they use otherwise you might end up blocking their outgoing email delivery path from their in-office mail server.
Mistake 7: Typos
Avoid making common mistakes while configuring SPF settings by double-checking the SPF record for typos. You may type ‘inlcude’ instead of ‘include.’ This can make the entire record invalid.
Mistake 8: Not Publishing SPF Records for HELO Names Used By Your Email Servers
Verifying HELO or EHLO names is encouraged by the SPF RFC. HELO or its developed version EHLO is used when Mail from is <> despite the recipient’s failure in doing 100% HELO checking.
Publishing a HELO protocol includes generating an SPF record corresponding to the HELO FQDN used by your mail server. For example: mailserver.sample1.com
Generally, it should be a completely distinct SPF rule from the one which checks the From address in your domain linked to ‘sample1.com’.
Mistake 9: TXT Record Content Not Displayed With Double Quotes
The content of a DNS TXT record is always within double quotes (“—”), but these should never be part of the actual DNS record content. These quotes are only for display purposes as they help separate the start and end of a TXT record content.
An SPF record should begin with v=spf1 but if it starts with “v=spf1, it won’t be recognized at all.
Still a Problem?
Every alteration in SPF settings requires some time to propagate through the internet. It may take up to 72 hours as well. But if you still face any issues, use our free SPF record checker tool or reach out to our team of experts at support@powerdmarc.com.
- Travel Cybersecurity Threats and How to Stay Protected - December 18, 2024
- Cybersecurity Best Practices for Digital Nomads in Japan - December 17, 2024
- NCSC Mail Check Changes & Their Impact on UK Public Sector Email Security - December 13, 2024