SPF Policy Strength

SPF (Sender Policy Framework) is a DNS TXT record at your apex listing which IPs and hosts are allowed to send mail "from" your domain. The qualifier at the end of the record (-all, ~all, ?all, or +all) tells receivers what to do with senders that are not on the list. -all is the only strong qualifier; the rest leave room for forged mail to be accepted.

This check only runs when your domain has a non-null MX (it is treated as a mail-active domain). If you have only a null MX or no MX, the check shows as not applicable rather than failing.

How the verdict maps to evidence

• Pass: the SPF record ends with -all (hard fail). Receivers should reject mail from unauthorized IPs.
• Warn: the record ends with ~all (soft fail). Receivers may quarantine but not reject. Common as a transitional state during SPF rollout.
• Warn: the record uses ?all, +all, or has no all mechanism at all. No real policy on unlisted senders.
• Fail: no SPF record found at the apex.

Fail: no SPF record

Publish a single TXT record at the apex (yourdomain.tld, not _spf.yourdomain.tld). List the providers that legitimately send mail for you, then close with -all. If you only send through one provider, this is a one-line record:

yourdomain.tld.   IN  TXT  "v=spf1 include:_spf.google.com -all"

yourdomain.tld.   IN  TXT  "v=spf1 include:spf.protection.outlook.com -all"

Most providers document the include they want; use what they say, not what looks similar.

Multiple senders

If you send through more than one provider (mailbox provider plus a transactional sender plus a marketing platform, for example), list each include in one record. SPF allows exactly one v=spf1 record per domain; publishing two is a syntax error that breaks SPF for receivers.

yourdomain.tld.   IN  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net -all"

Warn: tighten ~all to -all

If your record currently ends with ~all, you have a complete-but-weak policy. Move to -all once you are confident the include list covers every legitimate sender. The audit checklist:

• Pull the last 30 days of DMARC aggregate reports if you publish DMARC. They list every IP that sent mail "from" your domain along with whether SPF passed.
• Identify any unauthorized senders in those reports. They are either legitimate services you forgot, or actual spoofers.
• Add the missing legitimate ones to your SPF record (or stop them sending from your domain).
• Tighten to -all and watch for delivery failures over the next week.

Without DMARC reports, you are flying blind on this transition. Publish DMARC at p=none with rua= reporting first (see the DMARC fix), collect a week of data, then tighten SPF.

Warn: replace ?all or +all with -all

?all (neutral) means "no opinion." +all means "every sender is authorized," which is the same as publishing no SPF at all because every IP claims authorization. Both should be replaced with -all. If you cannot move directly to -all because you have unknown legitimate senders, use the same DMARC-reporting audit above as a transition.

Verify the fix

• Run dig +short TXT yourdomain @1.1.1.1 and look for the v=spf1 record. Confirm there is exactly one such record and it ends with -all.
• Check the DNS lookup count. SPF is limited to 10 DNS lookups per RFC 7208 section 4.6.4; going over makes the entire SPF evaluation permerror at receivers (which DMARC treats as a hard fail). Each include:, a, mx, exists:, and redirect= counts toward the limit. RedScore tracks this as the SPF Lookup Count check.
• Send a test message from each legitimate sender and confirm SPF passes at receivers (Gmail's "Show original" view shows SPF, DKIM, and DMARC results explicitly).
• Re-run the RedScore lookup.

Common pitfalls

• Multiple v=spf1 records. SPF allows exactly one per domain. Two or more makes the entire record permerror at receivers, which DMARC treats as fail.
• Exceeding 10 DNS lookups. Nested includes inflate fast (one include can pull in a chain of further includes). Flatten or replace with ip4: and ip6: when you exceed.
• Using ptr. The ptr mechanism is deprecated and many receivers ignore or reject it. Remove it.
• Including senders you no longer use. After leaving a marketing platform or transactional sender, prune their include from your record. Stale includes inflate the lookup count and broaden authorization unnecessarily.
• Missing subdomain coverage. SPF records must be set per-subdomain if your transactional senders use subdomain envelope-from addresses (such as bounces@mail.yourdomain.tld). Apex SPF does not automatically cover mail.yourdomain.tld.