SPF that ends in ?all decides nothing

An SPF record that ends in ?all may look complete, but the final mechanism is neutral. It tells a receiving mail system that the domain owner has no opinion about whether an unmatched sender is authorized. For the authorization decision that SPF is supposed to communicate, that is effectively the same as providing no answer.
In OrangeStealth Security's monthly refresh for the US B2B SaaS 5-50 population, 1.0% of the population (n=11, N=1104) had neutral SPF. The aggregate was generated on 2026-10-06. This is not evidence that those domains were abused. It is a public DNS observation showing that their SPF policies did not produce a pass or fail for senders reaching ?all.
What neutral SPF actually tells a receiver
SPF evaluates whether the server sending a message is authorized by the domain named in the relevant mail-from identity. A record can explicitly authorize known services, include another provider's policy, and then use an all mechanism to describe what should happen when no earlier mechanism matches.
The qualifier changes that final result. With ?all, an unmatched sender receives a neutral SPF result. The domain is not authorizing that sender, but it is not stating that the sender is unauthorized either. The receiver remains free to use its own spam controls, reputation data and other policies. Neutral does not guarantee delivery, and it does not mean the message is safe.
Consider a hypothetical domain that authorizes its normal email provider and then ends its record with ?all. A message sent through the approved provider can pass SPF. A message from an unrelated server reaches the neutral ending instead. The second message has not passed SPF, but the record has declined to make a negative assertion about it.
Why DMARC changes the stakes
DMARC does not require both SPF and DKIM to pass. A message can pass DMARC through an aligned SPF pass or an aligned DKIM pass. Alignment means the domain authenticated by SPF or DKIM corresponds appropriately with the domain visible to the recipient in the From header.
๐ ๐ฆ๐ฒ๐ฐ๐๐ฟ๐ฒ ๐๐ถ๐๐ ๐ก๐๐ ๐๐ผ๐๐ฟ ๐ฆ๐ฃ๐ ๐ฟ๐ฒ๐ฐ๐ผ๐ฟ๐ฑ ๐ฎ๐ฐ๐๐๐ฎ๐น๐น๐ ๐ฐ๐ผ๐ป๐ณ๐ถ๐ด๐๐ฟ๐ฒ๐ฑ ๐ฐ๐ผ๐ฟ๐ฟ๐ฒ๐ฐ๐๐น๐?Microsoft tells you what SPF record to publish when setting up Exchange Online, but most organizations
A neutral SPF result is not an SPF pass, so it cannot provide the aligned SPF pass needed for that route to DMARC success. The message could still pass DMARC through aligned DKIM. It could also be blocked for unrelated reasons under a receiver's other policies.
A DMARC policy of p=none requests no DMARC-based enforcement. It also does not request reports by itself. Reports require a configured reporting destination. Moving toward quarantine or reject expresses the domain owner's requested policy, but it does not guarantee a particular receiver action.
The fix, in order
- Inventory every legitimate sender. Include the primary mail platform, marketing systems, billing tools, support platforms and any vendor that sends using the domain. Do not change the SPF ending or a DMARC enforcement policy until legitimate senders and alignment have been confirmed.
- Trace which identity each service uses. A vendor appearing in the SPF record does not automatically mean its messages align with the visible From domain. Check both SPF and DKIM paths because either aligned pass can satisfy DMARC.
- Replace ambiguity deliberately. After confirming the authorized sending estate, choose an SPF policy that accurately communicates the domain owner's position on unmatched senders. Avoid treating a stricter qualifier as a cleanup shortcut.
- Configure DMARC reporting intentionally. If reports are part of the plan, provide a valid reporting destination and review the resulting data before requesting enforcement. A bare
p=nonepolicy does not create that reporting flow. - Recheck after vendor changes. New marketing, support or billing platforms can change the sending estate. The free public checker at https://orangestealth.com/check can surface current public-facing email authentication signals. An External Security Posture Assessment is a separate, broader review of externally visible security configuration.
How this research was produced
This finding comes from passive, public-data-only observations of the US B2B SaaS 5-50 population in a monthly refresh generated on 2026-10-06. The sample size was N=1104. Results were aggregated and k-anonymised, with no company named. Public DNS and HTTP observations can identify configuration signals, but they do not prove abuse, compromise or backend behavior.
๐จยฟTienes un dominio en parking que no usas para el correo?. Evita que puedan enviar correos impersonando el nombre. Aรฑade siempre al DNS:v=spf1 -allv=DKIM1; p=v=DMARC1;p=reject;sp=reject;adkim=s;aspf=sโค๏ธยกgracias!
If your SPF record ends in ?all, start by confirming every real sender and how it aligns. The goal is not merely to make the DNS record look stricter. It is to replace an explicit non-answer with a policy that accurately reflects who is allowed to send for the domain.