SPF PermError: What It Means and How to Fix It

The short answer

Your sending IP can be allowed, but SPF can still break if the DNS policy is malformed or too large.

SPF PermError means the receiving mail server hit a permanent problem while checking SPF. SPF is the DNS-based check that lets a domain list which hosts may send mail using that domain in the MAIL FROM or HELO identity. The SPF record is the TXT record that starts with v=spf1. RFC 7208 defines PermError as a result for policy records that cannot be interpreted correctly, including records that exceed SPF's DNS lookup limit.

The key word is permanent. This is different from a temporary DNS timeout. A receiver can try again later on a TempError. With PermError, the published policy needs repair. Gmail, Microsoft, and other mailbox providers use authentication results along with reputation, complaints, message content, and local policy. A broken SPF check can weigh against the message, but the receiver decides whether to accept, spam-folder, or reject it.

Why SPF PermError happens

Most SPF permanent errors come from a record that is too complex, duplicated, or written in a way the SPF checker cannot parse.

• More than 10 DNS lookups during SPF evaluation. RFC 7208 says include, a, mx, ptr, exists, and redirect count toward this limit. If evaluation goes over 10, the receiver must return permerror.
• Multiple SPF records on the same hostname. A domain should publish one SPF TXT record that starts with v=spf1. Split records make the SPF result invalid.
• Bad syntax, such as a missing space, a malformed include, a typo in ip4 or ip6, an unknown mechanism, or a modifier written in the wrong format.
• A broken include chain. Your record may be short, but an included vendor record can include more records and push the total over the limit.
• DNS answers that do not match what SPF expects, such as an include target with no valid SPF record.

The common trap is adding every vendor that sends mail, then leaving old vendors in place. SPF has no memory of which vendor is active. It follows the DNS path every time a receiver checks the message.

What it does to delivery

A PermError means SPF did not pass. That matters most when DMARC needs SPF to prove the visible From domain is allowed to send.

SPF checks the envelope sender, often called the Return-Path or MAIL FROM domain. It does not directly check the address a person sees in the From header. DMARC connects those worlds by asking whether SPF or DKIM passed and whether the passing domain aligns with the visible From domain.

If DKIM passes and aligns, DMARC can still pass even when SPF has a PermError. If DKIM is missing, broken, or signed by a vendor domain that does not align, the SPF error can make DMARC fail. With DMARC p=none, the owner is monitoring. With p=quarantine, the owner asks receivers to treat failing mail as suspicious, often by placing it in spam or a similar area. With p=reject, the owner asks receivers to reject failing mail. RFC 7489 also says final handling is always up to the receiving system, so no DNS record can force inbox placement.

Google's sender guidelines say all senders need SPF or DKIM, and high-volume senders to Gmail need SPF, DKIM, and DMARC. Microsoft describes SPF, DKIM, DMARC, and ARC as related parts of email authentication and says its filtering also uses reputation, history, and behavior signals. That is why a PermError is worth fixing even if some mail still gets through.

How to fix it

Fix the record you have before adding anything new. The goal is one valid SPF record that lists only current senders and stays under the lookup limit.

• Find the exact hostname that sends mail. Check the root domain and any subdomain used in bounce or Return-Path addresses.
• Publish only one TXT record that begins with v=spf1 for that hostname.
• Remove vendors you no longer use. Old includes are the easiest way to waste lookups.
• Count lookups across nested includes and redirects, including vendor records outside your domain.
• Prefer ip4 and ip6 entries when your mail platform gives stable ranges and says this is supported. Those mechanisms do not count toward the 10 lookup limit.
• Avoid ptr. RFC 7208 lists it as a lookup mechanism, marks it as do not use, and it can be slow and fragile.
• Keep DKIM working for every sender. DKIM uses selectors and DNS public keys, and aligned DKIM can keep DMARC passing when SPF fails.
• Use DMARC aggregate reports with a rua address to see which sources pass, fail, and align before moving from p=none to quarantine or reject.

For a quick outside check, run the domain through the free InboxRadar scorecard at the domain checker. Use it as a second view, then make DNS changes in your provider's control panel and test again after DNS has had time to update.

SPF, DKIM, DMARC, MX, and blocklists

SPF PermError is one auth problem. It does not explain every spam-folder result by itself.

DKIM signs mail with a private key and publishes the matching public key in DNS under a selector. If the signature is valid and the signing domain aligns with the From domain, DMARC can pass through DKIM. DMARC then lets the domain owner publish p=none, p=quarantine, or p=reject, and ask for aggregate reports through rua.

MX records are different. They say where inbound mail for your domain should be delivered. A bad MX record can break receiving mail, but it is not what SPF uses to authorize most outbound senders unless your SPF record uses the mx mechanism.

Blocklists are also separate. A clean SPF record will not erase a poor sending reputation, spam complaints, compromised accounts, or a listed sending IP. Gmail and Microsoft look at authentication, reputation, user complaints, message content, forwarding behavior, and local policy. SPF repair removes one clear failure from that larger delivery picture.