SPFFailing01 / 09
(no v=spf1 record published)
The issue
No SPF record found. Receiving servers have no list of who may send for this domain, so nothing legitimate can prove it belongs.
If left unfixed
Anyone can send as your domain, and your real bulk mail has no baseline to align to. Gmail and Yahoo throttle or spam it the moment you send at volume.
SPF · 12 / 10 lookupsFailing02 / 09
v=spf1 include:_spf.a.com include:_spf.b.com include:mail.c.net include:relay.d.io ~all
The issue
The include chain crosses the 10-DNS-lookup limit (RFC 7208). SPF returns a PermError and fails authentication for every message from the domain.
If left unfixed
Every message from every platform fails SPF silently, with no inbox-side notice. Add one more sending tool and healthy mail starts getting filtered overnight.
DKIM · selectorNeeds work03 / 09
google._domainkey.yourdomain.com → no key (DKIM is selector-specific)
The issue
No DKIM key at the selector checked. DKIM is selector-specific, so a healthy domain can look broken if the wrong selector is audited. The real one lives in the s= value of a sent message's headers.
If left unfixed
Without a signing selector, forwarded mail can't stay aligned, and at DMARC enforcement it gets rejected. It's also the most misread result on any checker.
DMARC · p=noneNeeds work04 / 09
The issue
Policy is p=none: monitoring only. Records are read but failures are never acted on, which falls short of the Gmail and Yahoo bulk-sender enforcement minimum.
If left unfixed
Anyone can spoof your domain and DMARC won't stop it, and you fail the bulk-sender requirement. Move to p=quarantine once your legitimate mail aligns.
BIMI · MTA-STSOptional05 / 09
(no v=BIMI1 / v=STSv1 record; never affects your grade)
The issue
The optional hardening layer isn't present. Absence never lowers your grade, but presence signals a mature, deliberately configured sender.
Worth doing once core is enforced
BIMI puts your verified logo beside your name in the inbox; MTA-STS forces inbound mail over encrypted TLS. Layer them on after SPF, DKIM, and DMARC are at enforcement.
SPF · 2 recordsFailing06 / 09
v=spf1 include:_spf.old-crm.com ~all + v=spf1 include:_spf.new-esp.com ~all
The issue
Two v=spf1 records on one hostname. RFC 7208 is unambiguous: multiple records return PermError — the same hard failure as blowing the lookup limit. It usually happens mid-migration, when the new platform says “add our record” and someone adds instead of merges.
If left unfixed
Mail from both platforms fails authentication silently — the old one and the new one you just paid for. Merge every mechanism into a single record. One v=spf1 per hostname, ever.
SPF · void lookupsNeeds work07 / 09
v=spf1 include:_spf.crm.com include:spf.retired-vendor.net ~all
The issue
An include pointing at a hostname that publishes no SPF record is a void lookup. RFC 7208 recommends a limit of two, and some receivers enforce it as a PermError. The record parses cleanly and every naive checker passes it — the rot is invisible until someone counts.
If left unfixed
Retired vendors accumulate. Two voids and some receivers hard-fail the whole record, before you’ve touched the 10-lookup ceiling. This auditor counts voids separately, because they fail domains that “pass” everywhere else.
DKIM · 2048-bitLooks broken — isn’t08 / 09
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…" "…4jWQIDAQAB"
The issue
DNS caps a single TXT string at 255 characters, so every 2048-bit DKIM key is published as two strings the receiver joins back together. Some validators read only the first string and report a healthy key as malformed.
If misread
Teams “fix” a working key — rotating or deleting it mid-send — and break signing for real. This auditor reassembles multi-string TXT the way receivers do before judging anything. If a checker flags your split key, check the checker first.
SPF · -allStricter ≠ safer09 / 09
v=spf1 include:_spf.esp.com -all
The issue
Hardfail looks like discipline, but SPF breaks on forwarding by design — the forwarder’s server was never in your record. A -all can get legitimate forwarded mail refused before DMARC ever weighs the DKIM signature that would have saved it.
The senior take
With DMARC at enforcement, ~all plus aligned DKIM protects forwarded mail — DMARC makes the rejection decision with full evidence. That’s why this auditor recommends softfail once p=quarantine or p=reject is live, and why “stricter” checkers mis-grade it.