SPF record checker

SPF is recursive. Each include, each redirect and several other mechanisms cost a DNS lookup, and the includes have their own includes.

The specification caps the total at ten. Above it, receivers return a permanent error and stop — they do not evaluate what they already retrieved.

The cost is therefore not the length of your record. A record with three includes can be well over budget because one of those providers publishes a tree five levels deep.

Which is why it breaks without anyone changing anything: a provider restructures its own record, your expansion crosses ten, and your mail starts failing authentication on a day you deployed nothing.

The consequence reaches further than SPF. A permanent error means no SPF pass, which removes one of the two ways a message can align under DMARC.

A record ending in a hard fail asks receivers to reject mail from anywhere else. A soft fail asks them to accept it and mark it, which is the usual and reasonable position during a rollout.

A neutral ending gives receivers no reason to treat a forgery differently from legitimate mail. It parses, it passes validation, and it protects nothing.

A pass-all ending authorises the entire internet to send as the domain. It is rare, it is almost always a mistake, and it is worse than publishing no record at all because it looks like a policy.

Ending with a soft fail long-term is a defensible choice. Ending with a neutral or a pass-all is a defect, and the difference is one character.

Exactly one record. Several SPF records is a permanent error under the specification, and receivers treat the domain as having no SPF — the same silent total failure as exceeding the lookup budget.

Valid syntax. An unparseable record is discarded, and the usual causes are a stray character from a DNS editor or a record split across TXT strings incorrectly.

Absence of the deprecated reverse-lookup mechanism, which is slow, unreliable and explicitly deprecated by the specification. Several receivers ignore it entirely, so a record relying on it is relying on nothing.

That the record is published at the domain apex, since that is where receivers look for it.

One record, valid syntax, expansion comfortably under ten lookups with room for a provider to grow its own tree.

A restrictive ending — hard fail, or soft fail as a deliberate position rather than a leftover.

No deprecated mechanism, and no include for a provider the domain stopped using two migrations ago.

An expansion you recognise: every include belongs to a service that really sends mail as this domain.

`email.spf.present` retrieves the record. `email.spf.single` verifies uniqueness and `email.spf.syntax` verifies it parses.

`email.spf.lookups` expands the include tree and counts it against the ten-lookup limit. `email.spf.all` reads the ending qualifier. `email.spf.ptr` detects the deprecated mechanism.

`email.spoofing_exposure` combines the result with DMARC and DKIM, because SPF on its own does not establish whether a domain can be forged.

The expansion is evaluated as published at the moment of the query. A provider changing its own record changes your count without touching yours.

SPF authenticates the envelope sender, not the address a recipient sees. A passing record does not prevent the visible sender being forged — that is what DMARC alignment is for.

Whether legitimate mail passes cannot be established from the record alone. A source missing from the record fails, and only the DMARC aggregate reports show which sources those are.

No mail is sent and no message is examined.