📧 Email Deliverability Checker

An email deliverability checker that looks up a domain's real SPF and DMARC DNS records, and checks common DKIM selectors, via DNS-over-HTTPS.

Free No Signup Required Browser-Based

What Email Deliverability Checker Does

SPF, DKIM, and DMARC are the three DNS-published records that let a receiving mail server decide whether an email claiming to be from a domain is actually authorized by that domain. All three are standard, publicly documented internet protocols (RFC 7208, RFC 6376, and RFC 7489 respectively) — this tool reads the same public DNS records any mail server checks, using Cloudflare's DNS-over-HTTPS resolver, entirely client-side.

What this tool does not do — and cannot do without infrastructure this site does not have — is test actual inbox placement (whether a real test message lands in the inbox, spam folder, or gets blocked outright at Gmail, Outlook, etc.) or check IP/domain blocklists. Those require sending real test messages to real mailboxes and checking blocklist databases, which several dedicated SaaS tools already do. This tool is scoped honestly to the DNS-authentication slice of the problem.

How to Use Email Deliverability Checker

  1. Enter the sending domain (not a full email address)
  2. Click Check Records to query SPF, DMARC, and common DKIM selectors
  3. Review which records exist and copy the raw values to compare against your provider's setup instructions

How to Read Your Result

A missing record is not automatically a crisis

A domain with no outbound mail (a pure "do not reply" landing-page domain, for instance) may legitimately have no SPF record and still be fine — these records only matter for domains that actually send email. Context matters more than a blanket pass/fail.

DMARC policy strictness matters as much as its presence

A DMARC record can exist but be set to p=none, which only monitors and reports without actually blocking spoofed mail — many domains start there deliberately before tightening to p=quarantine or p=reject once they've confirmed their own legitimate mail streams all pass. This tool shows the raw record so that policy can be read directly.

These three records work together, not independently

SPF alone can be broken by email forwarding (a common false-fail). DKIM alone survives forwarding but says nothing about which servers may send. DMARC ties both together and tells receivers what to do when either check fails — a domain with only one or two of the three has a real, specific gap, not just a lower score.

Multiple email services often mean one shared SPF record

A business sending from Google Workspace, a marketing platform, and a CRM all needs those three services' SPF mechanisms combined into a single record — adding a new sending service without editing the existing SPF record (rather than replacing it) is one of the most common real-world misconfigurations this kind of check surfaces.

Limitations & Accuracy Notes

  • DKIM cannot be discovered without knowing the exact selector — this tool checks several common selector names, so "not found" for DKIM is inconclusive, not a confirmed failure.
  • Does not test actual inbox placement, spam scoring, or blocklist status — only whether the authentication DNS records exist and what they say.
  • DNS results can be cached; a very recently changed record may not reflect immediately depending on TTL and resolver caching.

Frequently Asked Questions

What are SPF, DKIM, and DMARC?
SPF (Sender Policy Framework) lists which mail servers are authorized to send email for a domain. DKIM (DomainKeys Identified Mail) cryptographically signs outgoing messages so receivers can verify they weren't altered in transit. DMARC (Domain-based Message Authentication) tells receiving mail servers what to do when a message fails SPF or DKIM, and is published as a TXT record at _dmarc.yourdomain.com.
Why might DKIM show as "not found" for a domain that has it?
DKIM records live at a selector-specific subdomain (like google._domainkey.yourdomain.com) and the selector name is chosen by whoever configured the sending service — it isn't discoverable from the domain alone. This tool checks several common selector names, but a domain using a custom or unusual selector will show as inconclusive rather than genuinely missing.
Does having all three records guarantee inbox delivery?
No — SPF/DKIM/DMARC prove authenticity, which is necessary but not sufficient for good deliverability. Sender reputation, content, engagement rates, and blocklist status all matter too, and none of those are checked here.
Is this tool sending any test emails?
No. It performs read-only public DNS lookups via DNS-over-HTTPS — no email is sent and no account is required.
What should a healthy SPF record look like?
It starts with v=spf1, lists the servers/services authorized to send for the domain (like include:_spf.google.com for Google Workspace), and ends with an enforcement mechanism — ~all (soft fail) or -all (hard fail) for anything not listed. A record ending in ?all (neutral) authenticates nothing meaningfully.
Can a domain have more than one SPF record?
It should not — RFC 7208 specifies that multiple SPF TXT records at the same domain make SPF evaluation fail entirely, a common misconfiguration when a second email service is added without merging its include into the existing single record.
Is my data stored?
No. Lookups query Cloudflare's public DNS-over-HTTPS resolver directly from your browser.
By OnlineToolHubs Team • September 2026