Email Deliverability

Fast presence check on the three records every mailbox provider looks at: MX, SPF (TXT prefixed v=spf1) and DMARC (TXT at _dmarc.{domain}). DKIM is selector-specific and not checked here — use the DNS records tool against your selector hostname. Bulk mode handles up to 100 domains at once.

Free to use, no signup. On the next page you confirm before we run the check.

What this check returns

Domain: The domain name that was queried.
MX: Mail servers that accept email for the domain, with priority.
SPF: SPF record — authorises which servers may send mail for the domain.
DMARC: DMARC policy — tells receivers how to handle failing mail.
Verdict: Plain-language summary of the check result.

Bulk email deliverability check (MX / SPF / DMARC)

A fast sanity check on the three things mailbox providers look at first when an email arrives: is there an MX record, is there an SPF policy, is there a DMARC policy. Submit up to 100 domains in one bulk check and the results land in a single comparison table.

Scope note: this tool does not check DKIM, because DKIM keys live under per-tenant selectors ({selector}._domainkey.{domain}) that can't be reliably discovered from outside. For DKIM use the DNS records lookup against the specific selector hostname.

What this tool actually does

Validate the domain syntax.
Pull MX records.
Pull TXT records on the apex; pick the one starting with v=spf1.
Pull TXT records on _dmarc.{domain}; pick the one starting with v=DMARC1.
Render a plain-language verdict: basic checks pass if all three are present, otherwise the list of what's missing.

We check presence and prefix only. We don't validate the inner syntax of the SPF/DMARC string, count DNS lookups, assess the policy strength, or attempt to send a probe message. That's deliberate — this is a quick screen, not a replacement for an MBOX-style full audit.

What this tool returns

Domain: The hostname you submitted, normalised to lowercase.
MX: Mail exchangers in priority host form (lower priority wins). Empty cells say — — that's the most common cause of inbound delivery failure right there.
SPF: Full SPF record string when present (e.g. v=spf1 ip4:… include:_spf.google.com ~all), — when no v=spf1 TXT record was found.
DMARC: Full DMARC policy string when present (e.g. v=DMARC1; p=quarantine; rua=mailto:…), — when none was found at _dmarc.{domain}.
Verdict: basic checks pass when MX, SPF and DMARC are all present, otherwise a comma-list of what's missing (no MX records, missing SPF, missing DMARC).

SPF in one screenful

SPF (Sender Policy Framework) is a TXT record on your apex listing the IPs and hosts allowed to send mail using your domain in the envelope sender. A receiver looks up your SPF, checks whether the sending IP is in there, and applies your policy.

Mechanisms: ip4:, ip6:, a:, mx:, include:.
Qualifiers: + pass, - fail, ~ soft-fail, ? neutral.
Cap: SPF resolution must stay within 10 DNS lookups end-to-end (RFC 7208 §4.6.4). Big include: chains routinely blow past this.
One domain may publish only one SPF record. Two competing SPF TXTs is a misconfiguration and undefined behaviour.
End with -all (hard fail) or ~all (soft fail). Don't ship +all — that authorises the entire internet.

We pull and display the SPF string but don't traverse the include: chain or count lookups. Use a dedicated SPF lint tool for that.

DKIM in one screenful (not checked here)

DKIM adds a cryptographic signature to outbound mail. The sender signs the message with a private key; the receiver fetches the matching public key from DNS at {selector}._domainkey.{domain} and verifies the signature.

The catch is the selector — it's chosen by the sender and rotated regularly. Common ones include google (Google Workspace), selector1 / selector2 (Microsoft 365), k1 (Mailchimp), and dozens of vendor-specific names. There's no way to enumerate them from outside the tenant — you either know the selector or you don't.

To verify DKIM: take the selector your mail provider gave you and look up {selector}._domainkey.{domain} in the DNS records lookup. The TXT cell will carry the public key when DKIM is set up.

DMARC in one screenful

DMARC ties SPF and DKIM together and tells receivers what to do with mail that fails either:

p=none — monitor only. No enforcement. Use this on day one to collect aggregate reports.
p=quarantine — failing mail goes to spam. Common middle-ground.
p=reject — failing mail is rejected at the SMTP layer. Highest protection, requires confidence that every legitimate sender is authenticated.
sp= — separate policy for subdomains.
pct= — percentage of failing mail the policy applies to (rolling enforcement).
rua= — where to send aggregate XML reports. Critical for visibility.
ruf= — where to send per-failure forensic reports (not all receivers send these).

DMARC requires identifier alignment — the domain in From: must match the SPF-authenticated or DKIM-authenticated domain. Strict (aspf=s, adkim=s) requires exact match; relaxed (default) allows subdomains.

A typical rollout (not done by this tool)

This tool doesn't walk you through the rollout — it answers "where do you stand right now?". For context, the usual path is:

SPF. Inventory every legitimate sending source, publish one SPF record covering them, end with ~all or -all.
DKIM. Generate keys (at least 2048-bit), configure outbound signing, publish the public key at the selector.
DMARC at p=none with rua= to a mailbox you actually read. Collect reports.
Fix what reports surface. Unknown senders, mis-aligned third-parties, forwarders.
Tighten. Move to p=quarantine with pct=10, increase gradually, eventually p=reject.
Maintain. Rotate DKIM keys periodically, re-check after every infrastructure change.

Bulk mode

Drop up to 100 domains in the textarea, one per line. Each row gets three DNS queries (MX, apex TXT, _dmarc. TXT) and the result is rendered into a comparison table. Useful for portfolio audits, agency-managed client lists, M&A due-diligence, post-migration verification. The table is exportable to CSV / JSON / YAML / XML.

What this tool does NOT do

No DKIM check. Selectors aren't discoverable from outside the tenant.
No SPF syntax validation. We display the string; we don't parse it.
No SPF lookup-count. A record may already be over the RFC 7208 10-lookup limit and we won't flag it.
No DMARC syntax validation. Same — we display, we don't parse.
No reverse DNS check on MX hosts. The runner intentionally keeps to fast queries.
No probe email. We don't send anything to your MX.
No multi-record disambiguation. If a domain accidentally publishes two v=spf1 records, we pick the first that matches the prefix and don't warn.
No BIMI / MTA-STS / TLS-RPT. Those are separate concerns for a separate tool.

Common results explained

All three populated, "basic checks pass": Good baseline. Doesn't mean everything is configured well — the strings themselves need a human read.
No MX: Domain can't receive email at all. Either intentional (it's a sender-only domain) or a misconfiguration.
Missing SPF: Most receivers will downgrade trust. Add an SPF record covering every legitimate sender.
Missing DMARC: No identifier alignment policy. Gmail/Yahoo bulk-sender rules now effectively require DMARC for bulk mail; start with p=none.
MX present, SPF/DMARC missing: Common on receive-only or low-volume domains. Still publish SPF and DMARC even if you never send — it prevents spoofers from using your apex.

Related tools

Pair this with the DNS records lookup (verify DKIM at your selector, read raw TXT), blacklist check (is the sending IP currently on a DNSBL?), DNS detection (which provider runs the DNS), and WHOIS & RDAP lookup (registrar & abuse contact when reporting).

Get started

Paste one or more domains in the form above. Single submissions render as a detail card with each field; bulk submissions as a side-by-side table you can scroll horizontally and export.