Permissive SPF policy

A hard fail asks receivers to reject mail from servers not on the list. It is the strongest position and the one to reach.

A soft fail asks them to accept it and mark it as suspicious. This is the sensible position during a rollout and a defensible one long-term.

A neutral ending explicitly tells receivers to treat unlisted servers no differently from listed ones, which discards the entire point of the record.

A pass-all ending authorises everyone. It is rare, it is almost always a mistake, and it actively vouches for forgers.

The difference between the useful endings and the useless ones is a single character in the record.

A record is written permissively on purpose during testing, to avoid breaking mail while the sender list is established, and the tightening step never happens.

A delivery problem is blamed on SPF and the ending is loosened as a quick fix, which resolves the symptom and removes the protection.

A record is copied from documentation or from another domain without the ending being reconsidered.

A pass-all ending is occasionally inherited from a provider's default template, which is the one case where it was never a decision at all.

In every case the record shows as present and valid in any tool that only checks for existence.

It reads like caution and it is not: it is an explicit instruction that unlisted servers carry no signal.

A soft fail is the actual middle ground — it accepts the mail and tells the receiver to weigh it accordingly.

So a domain wanting to be careful during a rollout wants a soft fail, not a neutral ending.

Under DMARC the distinction matters more: a neutral SPF result does not produce a pass, so alignment through the SPF path is unavailable regardless of how the record is otherwise configured.

Publish a DMARC record with an aggregate reporting address first, and read the reports for a few weeks.

The reports name every source sending as your domain and whether each authenticated, which is the list you need before tightening anything.

Add includes for the legitimate sources that are failing, one at a time, confirming each in the next report.

Move the ending from permissive to soft fail once the recurring legitimate sources pass, and to hard fail once that has held for a few weeks.

Keep an eye on the lookup count while adding includes, since the ten-lookup limit is reached faster than most people expect.

`dig +short TXT example.com` and read the last mechanism in the SPF record.

Look specifically at the character before `all`: it is what decides everything discussed here.

A record with no `all` mechanism at all behaves as if it ended neutrally, which is the same problem in a less obvious form.

Confirm the record is the only one, since a duplicate makes the ending irrelevant.

Read the authentication results in a real message's headers to see what a receiver actually computed.

`email.spf.all` reads the ending qualifier and reports whether it is restrictive.

`email.spf.present` and `email.spf.single` establish that a single record exists to have an ending at all.

`email.spf.ptr` reports the deprecated reverse-lookup mechanism, which several receivers ignore entirely and which weakens a record in a different way.

`email.spoofing_exposure` combines this with DKIM and DMARC into the overall statement, since a permissive SPF matters most when DMARC is relying on it.

A domain that sends no mail at all wants a record authorising nothing, ending in a hard fail with no mechanisms before it.

That is the strongest SPF statement available, and it is the correct one for a parked domain, a brand-protection registration or a subdomain used only for a website.

Paired with a DMARC policy of reject and an empty DKIM posture, it makes the name unusable for forgery.

Non-sending domains are attractive targets precisely because nobody monitors their mail, so the absence of a record there is worth more attention than on a busy domain.

The same applies to subdomains, which is what the DMARC subdomain policy tag exists to cover in one place.