A full email deliverability audit checks SPF, DKIM, and DMARC together, plus MX routing and blacklist status - because mail servers judge a message by the combination, not any single record.
Why deliverability is never a single-record question
Receiving mail servers do not grade SPF, DKIM, and DMARC in isolation. A message can pass SPF and still get flagged if DKIM signing is broken, or pass both and still land in spam if DMARC alignment fails between the visible From: header and the domain that actually authenticated. Each mechanism checks a different thing: SPF authorizes which servers may send, DKIM proves the message body was not altered in transit, and DMARC ties the two together into a policy the receiving server can act on.
MX records and blacklist status sit outside that authentication chain but affect deliverability just as directly. A domain with a flawless SPF/DKIM/DMARC setup still has broken inbound mail if its MX records point at a dead server, and its outbound mail still lands in spam folders if the sending IP is listed on a DNS-based blacklist (RBL) that the recipient's spam filter consults.
A full audit runs all six checks against the same domain in one pass: SPF, DMARC, BIMI, DKIM, MX, and RBL status, each scored independently and rolled into one overall score. That is the difference between this check and the single-record pages - it shows how the pieces interact, not just whether one record is syntactically valid.
- SPF - which mail servers are authorized to send for the domain (RFC 7208)
- DKIM - cryptographic signature proving the message was not modified after signing (RFC 6376)
- DMARC - policy tying SPF/DKIM results to the visible From: domain, plus reporting (RFC 7489)
- MX - which servers accept inbound mail for the domain, in priority order (RFC 5321)
- RBL - whether the domain's sending IPs appear on DNS-based blacklists that spam filters query
- BIMI - optional brand logo display in supporting inboxes, gated on a DMARC enforcement policy
Reading the audit results
Each check reports one of four statuses: pass, warning, fail, or info (used for neutral findings like "no records to check" rather than a pass/fail verdict). The checks are grouped into six categories - SPF, DMARC, DKIM, MX, RBL, and BIMI - each rendered as its own card with the individual test names, what was found, and a fix recommendation with example record syntax where a check fails.
The overall score weights passes at full value, warnings partially, informational findings near-full value, and failures at zero, then averages across every check that ran. A domain scoring in the high range has working authentication and clean sending IPs; a domain in the middle range typically has one broken mechanism (often DKIM or DMARC alignment) dragging down otherwise solid SPF and MX configuration; a low score usually means multiple mechanisms are either missing entirely or actively misconfigured.
The RBL section resolves the domain's A record and its MX servers' addresses, then queries each of those IPs against several public DNS-based blacklists (Spamhaus, Spamcop, Barracuda, SORBS, and CBL among them) using the standard reversed-octet lookup format those lists expect. A listing on any of them is a strong signal that mail from that IP is being rejected or spam-folder'd by receiving servers that subscribe to the same list - independent of whether SPF, DKIM, or DMARC pass.
| Category | What it verifies | Typical failure mode |
|---|---|---|
| SPF | Authorized sending servers | Missing record, exceeds 10 DNS lookups, no all mechanism |
| DKIM | Message signature integrity | Selector not published, key mismatch, missing selector guess |
| DMARC | Alignment policy + reporting | No record, policy=none with no enforcement plan |
| MX | Inbound mail routing | Stale server, single point of failure, MX pointing to CNAME |
| RBL | Sending IP reputation | IP listed after a compromised account or open relay |
| BIMI | Brand logo eligibility | No DMARC enforcement (p=quarantine/reject) to qualify |
Where to fix what the audit finds
A full audit is a triage tool, not a fix tool: once it flags which category is failing, the fix usually needs mechanism-specific detail the combined view does not have room for. A failing SPF check benefits from a dedicated SPF pass because SPF failures are often about the 10-DNS-lookup limit or a redundant include chain, details a single-line summary cannot show. The same applies to DKIM selector guessing and DMARC policy staging - each has enough nuance to warrant its own focused pass once this audit tells you where to look.
The practical order for fixing multiple failures: confirm MX first (broken inbound routing is usually the most urgent and the least likely to have a subtle cause), then SPF and DKIM in either order since DMARC alignment depends on both, then DMARC policy last since tightening it before the underlying mechanisms pass will start rejecting legitimate mail. RBL listings are typically symptoms - a compromised account, an open relay, or a shared IP with a bad neighbor - so they get investigated last unless mail is bouncing right now.
FAQ
Why did my domain score differently here than in a single SPF or DMARC checker?
A full audit averages six categories - SPF, DMARC, DKIM, MX, RBL, and BIMI - into one score, so a domain that scores perfectly on SPF alone can still show a mid-range overall score if DKIM or MX has an unrelated problem. A single-record checker only ever reports on that one mechanism, so the two numbers are not measuring the same thing.
Do I need to fix every category to be considered "healthy"?
No. BIMI in particular is optional and only applies once DMARC is already enforcing a quarantine or reject policy - most domains never configure it and are not worse off for skipping it. SPF, DKIM, DMARC, and MX are the ones that affect whether mail is delivered at all; RBL matters only if a listing is actually present.
Can a domain pass SPF, DKIM, and DMARC individually but still have bad deliverability?
Yes. A blacklisted sending IP (RBL) or a broken MX configuration for inbound replies sits outside the authentication chain entirely - receiving spam filters weigh IP and domain reputation alongside authentication results, and a listing on a major blacklist can suppress delivery even from a domain with a technically perfect SPF/DKIM/DMARC setup.
What order should I fix multiple failing categories in?
MX first, since broken inbound routing is the most immediately disruptive and usually the simplest to diagnose. Then SPF and DKIM, since DMARC alignment depends on both passing. DMARC policy tightening comes last - enforcing a strict policy before SPF and DKIM are solid will cause legitimate mail to be rejected or quarantined.
Why does the RBL check look at MX server IPs as well as the domain's own IP?
Outbound mail is usually sent from the mail servers listed in MX (or a separate sending infrastructure resolvable through them), not from whatever IP the domain's A record points to for its website. Checking both catches the case where the actual sending IP, not the web server, is the one that ended up on a blacklist.
Does a good overall score guarantee mail lands in the inbox?
No. This audit checks DNS-visible configuration and public blacklist status, not spam-filter heuristics like content, sending volume, or recipient engagement, which providers like Gmail and Outlook also factor into inbox placement. A clean audit removes the technical reasons mail gets rejected or flagged; it does not control every variable a spam filter weighs.
Related tools
- Dig into SPF specifically when the audit flags a lookup-limit or syntax problem the combined view only summarizes
- Test DKIM selectors directly, including guessing selectors the combined audit did not have configured
- Walk through DMARC policy staging (none to quarantine to reject) once SPF and DKIM are both passing
- Inspect mail server priority and routing in detail if the MX category flagged a stale or missing record