Understanding and Fixing Sender Policy Framework (SPF) Permerror
What is SPF Permerror and Why does it Happen?
Sender Policy Framework (SPF) is an email authentication protocol designed to prevent spoofing by verifying that a sender is authorized to send mail from a specific domain. An SPF Permerror (permanent error) occurs when a domain’s SPF record has issues that prevent proper evaluation– most commonly due to exceeding the DNS lookup limit, having invalid syntax, or other misconfigurations.
Unlike an SPF fail, which indicates a failed authorization attempt, a Permerror stops the process entirely, meaning the server can’t even evaluate whether the message is legitimate. This can lead to delivery problems, failed DMARC alignment, and a general drop in email reliability.
SPF Permerror is most often caused by:
Too Many DNS Lookups
SPF records can perform a maximum of 10 DNS lookups during validation. Each include, redirect, a, or mx mechanism may trigger a lookup. Going over this limit causes SPF validation to fail and is the single most common reason why SPF Permerrors occur. More on this below.
Syntax Errors
Small mistakes in SPF syntax– like missing colons or incorrectly formatted mechanisms– can break the record. Common issues include the below, but solid guidance on which syntax to use and where to use it can be found here.
Missing colons: v=spf1 include:spf.example.com -all
Incorrect qualifiers: v=spf1 +mx a:mail.example.com -all
Redundant or Oversized Records
SPF records that include multiple servers and unused or outdated mechanisms may exceed the size or complexity limits, contributing to errors. Exceeding the 255 character limit for an SPF string will cause a Permerror. The length limit for a single string in an SPF record is 255 characters. However, a single SPF record can consist of multiple strings, which are concatenated together by the reading application. If you need to include more than 255 characters, you should split the record into multiple strings, each less than or equal to 255 characters, separated by spaces.
Improper DNS Setup
Invalid domain references or misconfigured DNS records (e.g., CNAME loops or non-existent ‘include’ mechanisms) can prevent SPF evaluation.
What is the SPF 10 DNS Lookup Limit?
One of the most common causes of SPF Permerror is exceeding the 10 DNS Lookup Limit. According to RFC 7208, SPF records may not trigger more than 10 DNS lookups when evaluated. These DNS lookups are consumed by mechanisms like include, a, mx, exists, and redirect, so using these can rapidly deplete the number of lookups any given SPF record can have.
If a single evaluation of an SPF record causes more than 10 lookups, it results in a Permerror. This protects the receiving server from being overloaded by recursive or abusive DNS queries and is also a critical anti-abuse mechanism to prevent denial-of-service attacks through SPF misconfiguration.
The 10 DNS lookup limit was defined by RFC 7208 to prevent abuse, such as recursive lookups or Denial of Service (DoS) attacks. Without this limitation, a bad actor could force a mail server to perform excessive DNS queries, overloading it with unnecessary work and slowing or preventing mail delivery.
In a situation where the organization is using plenty of mail services that may overrun the 10 DNS record limit, options are available on how to compensate for these overages below, including the almighty SPF Flattening function.
How SPF Permerror Affects Deliverability
SPF Permerrors have a direct impact on an organization’s ability to reliably reach recipient’s inboxes. When an email server encounters a Permerror, it often treats the SPF check as a failure– or ignores it entirely. This creates uncertainty in authentication, which can cascade into broader email delivery problems.
Permerrors can cause:
Emails to be delayed or rejected: Receiving mail servers may defer or outright reject messages when SPF validation cannot complete successfully.
SPF alignment failures in DMARC: If SPF is part of a DMARC policy and fails to align due to a Permerror, DMARC authentication may fail, triggering enforcement actions (like quarantine or reject).
Legitimate mail being flagged as spam: Mail that fails SPF checks– or cannot be evaluated at all– is more likely to be marked as suspicious and routed to junk or spam folders.
Missed communications and reputation damage: Critical business messages might go undelivered or unnoticed. Over time, recurring delivery issues can damage a domain’s sending reputation, reducing trust among recipients and increasing bounce rates.
How to Fix SPF Permerror
SPF Permerrors can be remediated in a few different ways, with some methods being a bit more onerous than others.
Manual Cleanup
Note: This approach sacrifices flexibility and requires ongoing maintenance when provider IPs change. It is not recommended for this reason of increased administrative complexity and if not checked frequently, can result in emails not being sent out.
Review the SPF record to identify which services are still in use. It’s common for the services an organization uses to change over time and whenever a new one comes online, it’s a good idea to check if that new service is replacing another one (either right away or at a certain end date later).
Remove unused or outdated ‘include’ mechanisms.
Replace ‘include’ mechanisms with IP addresses if necessary– use caution, as this can increase record size if provider IPs change.
Replacing Include entries with IP addresses is performed by conducting a DNS resolution against the fully qualified domain name, then replacing the Include entry with an IP entry instead. For example:
v=spf1 include:_spf.example.com include:_spf.other.com -all
Can be simplified to:
v=spf1 ip4:192.0.2.1 ip4:203.0.113.5 -all
Use Flattening Tools
SPF flattening tools, including DMARC Director, reduce DNS lookups by resolving include mechanisms into status IP lists. These tools often:
Automatically stay updated when provider IPs change.
Help avoid common manual entry errors.
Keep SPF records compliant with post-change validation of the entire record.
Avoid the PTR Mechanism
The ‘ptr’ mechanism (which checks reverse DNS records) is unreliable, deprecated, and discouraged. It’s recommended to avoid using it. Use of it may lead to caching limitations and SPF validation failures.
Eliminate Duplicates
Audit the SPF record for unnecessary or repeated mechanisms, such as multiple include statements pointing to the same domain, or excessive ‘mx’ mechanisms.
Use IP4 and IP6 Where Possible
These mechanisms don’t require lookups and are great for directly authorized senders, like an internal mail server or service which only sends from a few IP addresses.
Best Practices for SPF Maintenance
Maintaining a healthy SPF record is essential to ensuring consistent email deliverability and strong domain reputation. A poorly maintained SPF record can lead to permerrors, DMARC misalignment, and increased risk of spoofing.
Here are some best practices:
Test an SPF record regularly using SPF checkers: Tools like DMARC Director can help verify whether a record is valid, within DNS lookup limits, and aligned with email-sending behavior.
Monitor email logs to catch SPF-related deliverability issues: Keep an eye on mail server logs or email delivery platform for SPF errors or rejections. DMARC reports can also highlight SPF failures and misalignments that need attention.
Work with third-party senders: If organizations use external services like Google Workspace, Microsoft 365, Mailchimp, Salesforce, or CRMs, reach out to them for officially recommended SPF configurations. Avoid blindly copying SPF ‘include’ mechanisms without confirming what they cover and how many lookups they consume.
Stay under TXT and string limits: SPF records are stored as DNS TXT records, which are limited to 255 characters per string and 512 bytes total. If a SPF record is too long, it will need to split it properly using multiple strings, or flatten it to reduce size and lookups.
Remove unused or outdated mechanisms: Periodically audit a SPF record to eliminate legacy or unnecessary entries that consume DNS lookups but don’t reflect the current sending infrastructure.
Avoid deprecated or unreliable mechanisms: Refrain from using ‘ptr’ mechanisms and be cautious with ‘exists’ mechanisms. Stick with IP4, IP6, and validated ‘include’ mechanisms wherever possible.
Document changes and maintain version control: If multiple administrators manage DNS records, keep a change log or use a DNS provider that supports versioning to reduce misconfigurations.
How DMARC Director Can Help Prevent SPF Permerror
DMARC Director provides built-in tools that can help avoid SPF Permerror, especially when integrating complex email environments with multiple mail sources, like organizations that are transitioning to Microsoft 365 or Google Workspace.
Visualize the SPF Workload: DMARC Director allows administrators to take a view of all of their SPF-authorized services at a glance, replete with IP resolution for duplicate detection, helping organizations stay within the 10 DNS lookup limit.
SPF Flattening Included: If an SPF record includes many third-party senders, DMARC Director support can assist in implementing SPF flattening, which resolves and replaces ‘include’ mechanisms with direct IPs– keeping records short, optimized, and compliant.
Monitoring and Maintenance Guidance: DMARC Director provides tools and support to audit and optimize SPF records, identify risky mechanisms, and ensure that configurations adhere to best practices and SPF specifications.
If configuring your domain’s SPF record is proving a bit of a challenge or is simply too time consuming to chase down all the senders, let Tangent handle it for you.