Validate your Sender Policy Framework (SPF) record to ensure email deliverability and prevent spoofing.
SPF is just the first layer. ObserveOne provides full observability into your website's uptime and API health.
Side-by-side breakdowns, no fluff.
SPF (Sender Policy Framework) is an email authentication method that specifies which mail servers are authorized to send email on behalf of your domain.
SPF stops attackers from sending fake emails that appear to come from your organization.
Google and Yahoo now require SPF/DKIM/DMARC for all bulk senders to reach the inbox.
SPF is published as a single DNS TXT record listing which servers may send mail for your domain. When a receiving server gets a message, it reads that record and checks whether the sending IP is authorized. A pass supports your DMARC alignment; a fail tells the receiver the message may be spoofed.
SPF allows a maximum of 10 DNS lookups. Exceeding that limit produces a PermError, and receivers ignore the record entirely.
Publishing two or more SPF records on the same domain is invalid, and mail providers may fail the check outright. Merge every sender into one record.
Ending a record in +all authorizes anyone to send as your domain. Use ~all (softfail) or -all (hardfail) instead.
Forgetting an include: for a provider you actually send through, such as a marketing platform, silently drops that mail. Avoid the deprecated ptr mechanism too.
A PermError is not a fail. It means a receiving server refused to evaluate your record at all, and it is usually what sits behind "mail rejected despite a valid-looking SPF record." RFC 7208 (section 4.6.4) puts a hard limit on how many terms in a record may trigger a DNS lookup: the include, a, mx, ptr, and exists mechanisms, plus the redirect modifier. Cross 10 of those across the whole chain, nested includes included, and the record becomes a PermError. all, ip4, and ip6 never count, since none of them needs a lookup to evaluate.
Two things trip people up when they count by hand. First, a single mx mechanism can burn one lookup per MX record the domain publishes, not one lookup total. Second, a nested include brings its own lookups with it, so a single marketing platform can already use three or four of your ten before you have added anything of your own.
There is a second, separate way to hit PermError while staying under 10: RFC 7208 also caps "void lookups," DNS answers that come back empty or NXDOMAIN, at two. A third void lookup fails the record on its own, regardless of the total count, which is why a typo'd include: or a sender you dropped months ago can break deliverability on a record that otherwise looks well within the limit. This checker validates the syntax of your record's top-level line, but it does not resolve every include: target recursively or count the lookups inside it. To find out where you actually stand, count every include, a, mx, ptr, exists, and redirect term across the full chain by hand, or flatten the chain by replacing includes with the specific ip4/ip6 ranges they resolve to.
~all is a softfail: receivers accept the mail but flag it as suspicious. -all is a hardfail: receivers reject or bin mail from servers not listed. -all is stricter, while ~all is the common starting point until you confirm every legitimate sender is covered.
A record can parse cleanly yet still fail in practice. The two usual causes are exceeding the 10 DNS-lookup limit, which triggers a PermError so the record is ignored, and a missing include for a provider you actually send through.
Ten. Each include, a, mx, ptr, and exists mechanism counts toward the limit; going over produces a PermError and receivers treat the record as unusable.
No. A domain must publish exactly one SPF TXT record. Two or more make the result invalid, and many providers will fail the check outright. Merge every sender into a single record.
A PermError means a receiving server could not evaluate your record at all and treats it as broken, not merely failing a check. RFC 7208 defines two causes: exceeding the 10-lookup limit across include, a, mx, ptr, exists, and redirect terms, or hitting more than two void lookups, DNS answers that come back empty or NXDOMAIN. Either one gets your mail treated as unauthenticated.
The include, a, mx, ptr, and exists mechanisms, plus the redirect modifier, each cause a DNS lookup and count toward the limit of 10 for the whole chain, nested includes included. All, ip4, and ip6 never count, since none of them requires a lookup to evaluate.