SPF, DMARC, and the Grades Nobody Checks

TL;DR: "We have SPF" tells you almost nothing. A record ending in +all authorizes the entire internet to send as your domain. Two SPF records make receivers ignore SPF completely. And p=none, the most common DMARC policy deployed, is a monitoring mode that blocks no spoofed mail. Audit any domain with the DNS / SPF/DMARC Inspector.

Email authentication is a rare corner of security where the checks are public, the records are a single DNS lookup away, and almost nobody looks. You can audit any domain on the internet in a second, including your own, and the results are frequently bad in ways the domain owner would be alarmed to learn.

Our inspector runs 18 distinct checks across MX, SPF and DMARC and scores from 100 down. Here is what it is actually looking for, and why each finding carries the weight it does.

SPF: the record that often protects nothing

An SPF record is a TXT record starting with v=spf1 that lists who may send mail for your domain. It ends with an "all" mechanism that says what to do about everyone else, and that final qualifier is the entire point.

-all (hardfail). Reject anything from an unlisted server. The strongest position.

~all (softfail). Treat unlisted senders as suspicious but deliver. This is the industry standard when paired with an enforcing DMARC policy, and it is what most well-configured domains use.

?all (neutral). Do nothing either way. We deduct 15 points, because a neutral result gives receivers no basis to act.

+all (pass everything). Explicitly authorize every server on the internet to send as your domain. We deduct 35 points, more than we deduct for having no SPF record at all, and that is deliberate. A missing record leaves receivers to fall back on other signals. A +all record actively asserts that the spoofed mail is legitimate. It is worse than silence.

The two-record trap

This one catches competent teams. RFC 7208 is explicit: if a domain publishes more than one SPF record, receivers must treat the result as permerror and ignore SPF authentication entirely.

It happens naturally. Marketing adds a record for a mail platform, IT already had one for the mail server, and nobody notices because both records look correct in isolation. The domain now has less protection than it did with one record, and the failure is silent. We deduct 25 points and flag it as a distinct finding rather than folding it into a generic "SPF issue", because the fix is specific: merge the mechanisms into a single record.

DMARC: the policy that ties it together

SPF says who may send. DMARC says what to do when the check fails, and asks receivers to report back. It lives at _dmarc.yourdomain.com, which is a separate lookup that plenty of audit tools forget to make.

The p= tag carries the policy:

• p=reject tells receivers to refuse failing mail at the gateway. Full marks.
• p=quarantine routes it to spam. Strong.
• p=none asks receivers to deliver it anyway and just send reports.

p=none is the most widely deployed DMARC policy in the world, and it is worth being blunt about what it does: nothing, defensively. It is a monitoring mode, designed as a temporary stage while you find out which legitimate senders would break under enforcement. An organization can spend years at p=none, see "DMARC: configured" on a compliance checklist, and remain exactly as spoofable as a domain with no DMARC record at all. We deduct 15 points and say so plainly.

A DMARC record with no valid p= tag is worse still, since receivers have nothing to apply. That is a 20-point deduction.

Reporting

The rua= tag is where aggregate reports go. Without it you get no visibility into who is sending as your domain or how much of it is failing, which is the main practical benefit of deploying DMARC in the first place. Small deduction, 5 points, but it is the difference between a policy you can tune and one you are guessing at.

The grade is a conversation starter, not a verdict

Scores map to a letter: A+ at 95 or above, A at 90, B at 80, C at 70, D at 55, F below that. The grade exists because "your domain scores 45, here are the four reasons" starts a useful conversation with someone who does not think about mail authentication, in a way that a raw record dump does not.

It is a heuristic, not an authority. Every finding names the specific record and the specific fix, and the raw TXT values are shown next to the analysis so you can check our reading rather than take it on faith. Findings carry stable identifiers internally, which is what makes it possible to re-audit a domain later and see precisely which check changed.

Privacy Note: All lookups go from your browser straight to public DNS-over-HTTPS resolvers. The domains you audit are never sent to Utilora, and there is no server to log them.

What we do not check yet

DKIM verification requires knowing the selector, which is not discoverable from DNS alone, so we do not claim to check it. MTA-STS and BIMI are also absent. Any tool that reports "DKIM: pass" without asking for a selector is guessing, and we would rather list the gap than pad the report.

Audit a domain's SPF and DMARC →