Audit your domain before sending email

How to use the deliverability audit

Run a full deliverability audit in seconds: active MX, usable SPF, available DKIM selectors and an enforceable DMARC policy.

Gather the essentials

Provide the From domain, optionally add the bounce domain (return-path) and list the DKIM selectors you rely on so the check covers every path.

Launch the complete scan

The tool queries each record, aggregates diagnostics and separates blocking errors from advisory warnings so you can triage quickly.

Share the root causes

Use the suggested causes and advice to align marketing, security and deliverability teams on the same diagnostic snapshot.

Why use this deliverability audit engine?

Before a campaign or putting a new sender domain into production, verify that the entire authentication chain is published and usable. This form queries DNS, compares responses for the From, Mail From and your DKIM selectors, then classifies the result as ready, degraded or blocked. The report explains what to fix and in what order.

Quick steps

Enter the domain used in the From header.
If the return domain differs, add the Mail From to evaluate the SPF actually verified.
Indicate the DKIM selectors to check, separated by commas, for example google, selector1, brevo2.
Launch Verify and read the summary then the detailed sections.

When to launch the check

Before an important send to confirm active MX, usable SPF, present DKIM selectors and readable DMARC.
During a deliverability incident to quickly spot the faulty layer: MX, SPF, DKIM or DMARC.
After a DNS change to see the real effect and account for caches via TTL.

Understanding the report

The audit calls /v1/mail/domain-check, which aggregates MX resolution, SPF syntax and lookup diagnostics, DKIM selector lookups, DMARC parsing and BIMI health. Each category reuses the detailed codes listed in the mail-readiness documentation so you can see whether an issue comes from DNS resolution, syntax, lookup limits or weak policies.

MX: reception and signal sent

MX records indicate where your domain accepts mail. Missing or invalid MX records trigger rejections and suggest the domain is not intended for email. If you don't accept messages, publish a null MX 0 . to clarify the intention. Also verify that each MX target resolves to A or AAAA.

SPF: sender authorization

SPF describes which hosts can send on behalf of the domain. The engine validates syntax, counts DNS queries and flags traps: ten lookup limit, obsolete mechanisms like PTR or +all, broken includes, non-existent domains. Simple objective: one SPF per name, clear and under the limit.

DKIM: integrity and identity

DKIM signs the message. The check verifies the presence of the p tag, key length, invalid characters and existence of provided selectors. It alerts on missing or unusable selectors. Take the opportunity to plan key rotation and fix truncated formatting.

DMARC: policy and observability

DMARC links SPF and DKIM to a p policy that applies: none, quarantine or reject. The report highlights adkim and aspf alignment, subdomain policy sp and validity of rua and ruf addresses. Without readable reports, the move to strictness remains blind.

Score and badge interpretation

The checker calculates a readiness score and a badge that appears above the results. Grades map to the percentage of points obtained: Excellent (≥ 90%), Good (75–89%), Fair (55–74%) and Poor (< 55%).

Component	Displayed max	How points are allocated
MX	12	No MX ⇒ 0. A single MX ⇒ 8/12 with the `mail.readiness.score.mx.single` note. Two or more MX ⇒ 12/12 unless the status is `error`, which drops to 0 with `mail.readiness.score.mx.error_status`.
SPF	24	Missing ⇒ 0 with `mail.readiness.score.spf.missing`. Invalid syntax ⇒ 12/24. Lookup-heavy or weak `?all`/`~all` endings ⇒ 15/24 with the relevant notes. Clean with only minor warnings ⇒ 18/24; fully valid ⇒ 24/24.
DKIM	29	No selector ⇒ 0 with `mail.readiness.score.dkim.missing`. Valid selectors are scored on key strength (≥2048 bits gives full credit). Invalid selectors add `mail.readiness.score.dkim.invalid_records` and lower the median-derived score.
DMARC	23	No or invalid record ⇒ 0 with `mail.readiness.score.dmarc.missing` or `.invalid`. `p=none` ⇒ 4/23 with `policy_none`, `quarantine` ⇒ 17/23, `reject` ⇒ 15/23 (23/23 when pct=100 with no warnings). Partial `pct` or warnings reduce the score and add `partial_pct`/`warnings` notes.
BIMI	12	No record ⇒ 0 with `mail.readiness.score.bimi.missing`. Invalid TXT or missing logo/VMC reduce the score (2/12 to 7/12) and add `invalid_record`, `logo_missing`, `logo_invalid` notes. Tiny-PS or VMC warnings cap the score at 9/12 and surface `logo_warning`, `no_vmc`, `vmc_warning` or `vmc_logo_mismatch`.

The notes surfaced next to the score explain why a component lost points; they come directly from the diagnostics documented in mail-readiness-diagnostics.md and mirror the JSON fields returned by the API.

Deepen your deliverability

Deliverability depends on a coherent trio: DNS and sending practice. Combine this audit with CaptainDNS's SPF, DKIM and DMARC validators to test each building block, then document detected causes and applied corrections. Keep track of changes: date, previous value, new value, TTL. You'll save time during future sends as well as during diagnosis.