Email Deliverability Checker

Server assisted New Web Utilities

Enter the domain you send from and the Mutqan server reads its mail records through public DNS-over-HTTPS resolvers — MX, SPF, DMARC, MTA-STS, TLS-RPT and BIMI in at most eight queries, then the addresses and reverse DNS of up to three MX hosts — and turns them into a pass, warning and fail checklist with the fix for each item. It checks what the domain publishes in DNS, not inbox placement, sender reputation or message content, and the result lists what it could not see.

Privacy: The name you look up is sent from the Mutqan server to the public DNS resolvers named in the results. Nothing is stored.

What DNS records does a domain need before it sends email?

An SPF record listing the servers that send for the domain (RFC 7208), a DKIM key for each sending service (RFC 6376), a DMARC record — at least p=none, with a rua= address for reports (RFC 7489) — MX records so replies and bounces have somewhere to go, and sending servers whose address has a PTR name that resolves back to it. Mailbox providers such as Gmail require these before they accept mail in volume; they are necessary for the inbox, not sufficient, because reputation and content decide placement.

Security note: A domain that sends no mail should still publish "v=spf1 -all" and a DMARC record with p=reject, so nobody can send in its name.

How to use Email Deliverability Checker

  1. Enter the domain of your From address (example.com); an address such as news@example.com or a URL is reduced to the domain.
  2. Leave "Also check the addresses and reverse DNS of up to 3 MX hosts" ticked, unless you only need the records.
  3. Press Check domain and work down the checklist: Failed items first, then Warnings.
  4. Fix the records with your DNS provider, wait for their TTL to pass, and run the check again; then check each sending service's DKIM key with the DKIM Record Checker.

Email Deliverability Checker features

  • Reads MX, SPF, DMARC, MTA-STS, TLS-RPT and BIMI for the sending domain in one run, through public DNS-over-HTTPS resolvers
  • Turns them into a checklist — Passed, Warning, Failed, Info, Unknown or Not checked here — with what each result means for a receiver
  • Looks up the address of up to three MX hosts and checks forward-confirmed reverse DNS: a PTR name that resolves back to the same address
  • Flags the SPF problems receivers punish: no record, two records, "+all", a broken record, more than 10 lookup terms, and an ending that protects nothing
  • Checks DMARC the way Gmail's bulk-sender rules read it — a record with at least p=none — and whether aggregate reports (rua) reach you
  • Lists the next steps in order and, just as plainly, what a DNS check cannot see: inbox placement, reputation, content and DKIM signing

Inputs and outputs

Inputs

  • Sending domain — the domain of your From address; an e-mail address or a URL is reduced to it. IP addresses are refused.
  • Also check the addresses and reverse DNS of up to 3 MX hosts — on by default; untick it to read the records only.

Outputs

  • Summary and Checklist — counts of passed, warning, failed and unchecked items, and each check with its status and what it means.
  • What to do next — the fixes for the failed and warning items, in order.
  • Mail servers (MX), SPF and DMARC — the MX hosts with their address, PTR name and whether it is forward-confirmed; the SPF record and its lookup terms; the DMARC record, where it was found, its policy and report address.
  • What this check does not cover — inbox placement, reputation, content, DKIM signing and the reverse DNS of sending servers that are not MX hosts.

Email Deliverability Checker example

example.com, a reserved domain locked down so that it never sends mail

Input:

example.com (the tool's Load example)

Output:

Summary: Passed 3 · Warnings 1 · Failed 1 · Not checked here 1
Checklist: MX records — Failed (Null MX, RFC 7505: the domain declares that it accepts no mail) · SPF record — Passed (ends in -all) · SPF DNS lookups — Passed · DMARC record — Passed (enforcing policy) · DMARC reports — Warning (no rua= address) · DKIM — Not checked here · MTA-STS, TLS-RPT, BIMI — Info (not published)
SPF: v=spf1 -all · DMARC: v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s at _dmarc.example.com, Policy (p) reject
What to do next: Publish MX records for the domain (or use a sending domain that receives mail) · Add a rua= address to the DMARC record · Check the DKIM key of each service that sends for you

How to read the Email Deliverability Checker results

Failed means receivers are likely to refuse or distrust mail from the domain until it is fixed: no SPF, a broken or "+all" SPF, an invalid DMARC record, MX hosts without an address, or a null MX on a domain you send from.

Warning means mail can be delivered but is treated with less trust, or you are flying blind: no DMARC record, no rua= reports, a "?all" ending, or MX addresses without matching reverse DNS.

Passed is about the published record only: a DMARC record with p=none passes because Gmail accepts it for bulk senders, even though it does not stop forgery — the Email Domain Spoofing Checker rates that side.

Not checked here and Unknown are not passes: DKIM needs a selector, and a lookup that failed says nothing either way.

All Passed is a good start, not a promise of the inbox: reputation, content and complaint rates decide placement.

When to use Email Deliverability Checker

  • Preparing a new domain or a new sending service before the first campaign.
  • Finding out why mail from a domain started going to spam after a DNS or provider change.
  • Checking a client's or a department's domain against Gmail's bulk-sender requirements before a launch.
  • Reviewing a self-hosted mail server: MX addresses, PTR names and the SPF record in one pass.

Troubleshooting

  • "The public DNS resolvers could not answer for this domain": the domain does not exist, or its DNS answers SERVFAIL (often broken DNSSEC). Fix the DNS first — receivers cannot read your records either.
  • A record you just published still shows as missing: resolvers cache answers for the record's TTL. Wait for it to pass and check again.
  • Reverse DNS is "No PTR record" for a host your provider runs: only the owner of the address block can set a PTR. Ask your hosting or network provider, or ignore it if that host never sends.
  • "Not looked up: the per-minute DNS allowance was used up": the MX lookups count against a per-minute allowance shared with the other DNS tools. Wait a minute and run the check again.

Frequently asked questions about Email Deliverability Checker

Does a clean result mean my mail will reach the inbox?

No. Inbox placement depends on the reputation of your sending addresses and domain, complaint and bounce rates, list quality, content and each mailbox provider's own filters, none of which can be read from DNS. This check covers the published prerequisites: without them mail is likely to be refused or filtered, but meeting them is not enough on its own.

Why is DKIM marked "not checked here"?

A DKIM key is published at selector._domainkey.domain, and DNS offers no way to list the selectors a domain uses. Take the s= value from the DKIM-Signature header of a message you sent (the Email Header Analyzer shows it) and check that key with the DKIM Record Checker.

What do Gmail's sender requirements ask for?

Google's sender guidelines ask every sender for SPF or DKIM, valid forward and reverse DNS for the sending domains or addresses, TLS and a reported spam rate below 0.3%. Senders of more than 5,000 messages a day to Gmail also need both SPF and DKIM, a DMARC record (a policy of none is accepted), a From domain aligned with SPF or DKIM, and one-click unsubscribe for marketing mail. This tool checks the DNS part of that list.

Why look at the reverse DNS of the MX hosts?

MX hosts receive mail, but when the same servers also send — common for self-hosted mail — receivers expect each address to have a PTR name that resolves back to it. If you send through a provider (Google Workspace, Microsoft 365 or an e-mail service), the reverse DNS of its sending servers is the provider's responsibility and is not shown here.

How many DNS queries does one check make?

At most eight for the mail records, then two to four per MX host — its IPv4 address (IPv6 when it has none), the PTR name of that address and, when the PTR name differs from the host, that name's address — for at most three hosts. The queries go from the Cloudflare edge to public DNS-over-HTTPS resolvers, and nothing is stored.

Technical notes

The overview is one request to the Mutqan server, which sends at most eight DNS-over-HTTPS queries from the Cloudflare edge: MX, the domain's TXT records (for SPF, RFC 7208), the DMARC walk from _dmarc at the domain up to its organizational domain (RFC 7489), _mta-sts (RFC 8461), _smtp._tls (RFC 8460) and default._bimi. A null MX ("0 .", RFC 7505) declares that the domain receives no mail.

SPF is read statically: the record's own DNS-lookup terms are counted against the limit of 10 of RFC 7208 §4.6.4, include: and redirect= are counted but not followed, and more than one v=spf1 record is a permanent error. The SPF Record Checker follows the whole chain.

Reverse DNS is checked the way receivers do it (forward-confirmed reverse DNS): the MX host's IPv4 address (IPv6 when it has none) is resolved, its PTR record (RFC 1035) is read, and the PTR name must resolve back to the same address. Each lookup is a separate request from your browser to the Mutqan server, two to four per host, for at most three hosts.

Google's sender guidelines ask every sender for SPF or DKIM, valid forward and reverse DNS for sending servers, TLS and a spam rate below 0.3%, and senders of more than 5,000 messages a day for both SPF and DKIM, DMARC with at least p=none, From alignment and one-click unsubscribe (RFC 8058). Only the DNS-published part of that list can be checked from outside.

Limitations and methodology

Only published DNS is checked: not inbox placement, sender reputation or block lists, message content, complaint rates, DKIM signing, TLS on outgoing connections or unsubscribe headers.

DKIM keys are not checked, because a selector cannot be discovered from DNS; SPF include: and redirect= are not followed in this overview.

Reverse DNS is checked for at most three MX hosts and for their first address only. Mail sent through a provider leaves from the provider's servers, which are not looked at here.

Lookups go to public DNS-over-HTTPS resolvers from the Cloudflare edge and show what those resolvers had cached at that moment.

Security and privacy

The domain, its MX host names and their addresses are sent from the Mutqan server to public DNS resolvers; nothing is stored and no mail is sent.

References