MediumPolicy

SPF record ends with ?all

The record ends in ?all, the neutral qualifier, which tells receivers that the domain owner is explicitly making no statement about senders not listed. A neutral result is treated by most receivers much as a missing record would be, so the mechanisms in front of it protect nothing: anyone can send as the domain without contradicting what you published.

Check your own domainSPF checker

What causes this

?all is the neutral qualifier: it tells receivers that a sender which matched nothing in your record should be treated exactly as if you had published no SPF record at all. It is functionally close to having no policy, and it prevents SPF from contributing anything useful to a DMARC evaluation for unauthorised senders.

What it breaks

Unauthorised senders receive a neutral result rather than a failure, so SPF does not help receivers distinguish your mail from forgeries.

What the receiving server does

Neutral is defined as the absence of an assertion rather than a weak one. RFC 7208 requires it be treated the same as none, which is the result for a domain with no SPF record at all. So while the record is syntactically valid and its includes are evaluated, the outcome for any sender not matching them is that the receiver learns nothing. Under DMARC, a neutral result does not produce an SPF pass, so alignment must come from DKIM.

Neutral against softfail

The distance between ?all and ~all is small in characters and large in meaning. Both avoid outright rejection, but only one of them makes a claim a receiver can act on.

?allneutralno assertion: equivalent in effect to publishing nothing
~allsoftfailthese senders are not authorised; please treat accordingly without rejecting
-allfailthese senders are not authorised

How to fix it

Change ?all to ~all, then to -all once you are confident the sender list is complete.

  1. Confirm the record lists every service that sends mail for the domain.
  2. Change ?all to ~all.
  3. After monitoring for a week with no legitimate failures, change it to -all.

If you send with

Migrations and inherited records
?all most often appears during a mail platform migration, where nobody was confident which systems still sent mail, or in a record inherited with a domain. It is a reasonable temporary position and a poor permanent one: it is a note saying the audit was never finished.

Confirming the fix worked

  1. Publish DMARC at p=none with a reporting address if you have not already. The aggregate reports will tell you what is actually sending as your domain, which is the information ?all was standing in for.
  2. Add any legitimate sender the reports reveal to the SPF record.
  3. Move the record to ~all once you are confident the list is complete.
  4. Move to -all after a period at softfail with no surprises in the reports.

Common questions

Is ?all the same as having no SPF record?
In effect, yes, for senders that do not match an earlier mechanism. Both produce a result a receiver cannot act on. The difference is that a record with ?all still evaluates its includes, so listed senders do get an explicit pass.
Is ?all safer than ~all?
It is not meaningfully safer for your legitimate mail, and it is considerably weaker against spoofing. Softfail is not a rejection instruction: it asks receivers to treat unlisted mail with suspicion. Very little legitimate mail is lost moving from neutral to softfail.
When is ?all a reasonable choice?
As a short-lived position during a migration when you genuinely do not know the sending estate and want to avoid asserting something false. It should come with a DMARC reporting address and a date by which it will be replaced.