Email Deliverability Checker
Check a domain's email authentication — MX, SPF, DMARC and BIMI DNS records — and get a deliverability score with the exact issues to fix.
Input
Enter a domain (example.com) or an email address — the part after @ is used. Any http:// prefix, path or port is stripped automatically.
Output
| Property | Value |
|---|---|
| No data yet | |
| Check | Record |
|---|---|
| No data yet | |
| Check | Finding |
|---|---|
| No data yet | |
Guides
The Email Deliverability Checker inspects the DNS records that decide whether a domain's mail is trusted, authenticated, and delivered to the inbox instead of the spam folder — or rejected outright. Enter a domain (or any email address, we use the part after the @) and it looks up four things over DNS-over-HTTPS: MX records (can the domain receive mail at all), SPF (which servers may send on its behalf), DMARC (what receivers should do with unauthenticated mail), and BIMI (the optional brand-logo record). You get a 0–100% deliverability score, a Pass / Warning / Fail verdict for each check, the raw records found, and a plain-language list of every issue worth fixing.
How to use it
- Type a domain such as
example.com, or paste a full email address likeyou@example.com. - Click Check deliverability. The four DNS lookups run on our server and results appear in seconds.
- Read the Deliverability score table for the headline verdict, scan Records found for the exact TXT/MX values published, and work through Findings & recommendations to close the gaps. Both result tables copy and download as CSV.
What the checks mean
- MX — mail exchange records. Without them a domain literally cannot receive email.
- SPF — a
v=spf1TXT record listing authorised senders. We flag a missing or duplicate record, an overly permissive+all, a neutral?all, use of the deprecatedptrmechanism, and more than the RFC 7208 limit of 10 DNS lookups. - DMARC — a
v=DMARC1TXT record at_dmarc.<domain>. A policy ofp=rejectorp=quarantinewith an aggregate report address (rua=) scores best;p=noneis monitor-only and still lets spoofed mail through. - BIMI — an optional
v=BIMI1record that shows your logo in supporting clients. It needs an SVG (l=) and, for Gmail and Apple Mail, a Verified Mark Certificate (a=).
What score should I aim for?
Strong (90%+) means MX, a strict SPF policy, and enforced DMARC with reporting are all in place. Anything below 60% means core authentication is missing and receivers will treat your mail as suspicious.
Why does a domain with SPF still score low?
SPF alone isn't enough. Modern receivers weight DMARC heavily, and a p=none DMARC policy — or no DMARC at all — caps your score even when SPF is perfect. Publish an enforcing DMARC policy to move from "Needs work" to "Strong".
Does this send a test email?
No. It only reads public DNS records, so it reflects your published configuration, not the reputation of any single message.
Why might results differ from another tool?
DNS changes take time to propagate and answers are cached by TTL. If you just edited a record, wait for the old TTL to expire and check again.
Privacy
The tool runs the DNS lookups server-side and returns only the results — it does not store the domain you enter, and the queries hit public DNS-over-HTTPS resolvers (Cloudflare, with Google as a fallback). No email is sent and no mailbox is accessed.
Use it from code
From 3 credits per callREST API
curl -X POST https://api.iotools.cloud/v1/tool/email-deliverability-checker \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"domain": "google.com"
}'Swap in your own key from your account. The tool's fields are the body — no wrapper.
Ask an AI agent
Use the IOTools `email-deliverability-checker` tool (Email Deliverability Checker) on this input:
YOUR_INPUT_HEREPaste this at any agent connected to the IOTools MCP server, then add your input.