Email Deliverability Check for Your Domain

Email deliverability is whether the mail you send reaches the people you send it to. A large part of it is decided before anyone reads a word: receiving mail servers look up your domain in DNS to see whether a message really comes from you, where replies and bounces should go, and what to do with mail that fails. The big mailbox providers publish rules for this: Google and Yahoo ask every sender for SPF or DKIM, and bulk senders (Google and Microsoft draw the line at 5,000 messages a day) also need DMARC. Outlook.com rejects bulk mail that misses these rules with error 550 5.7.515.

This email domain checker reads those records for the domain you enter and runs eight checks side by side. Three of them decide the overall verdict; the other five are shown with their own result next to them.

Why only SPF, DMARC and MX decide. They are the records whose absence gets mail rejected by the big mailbox providers, lets anyone send mail in your name, or leaves replies and bounces with nowhere to go. The other checks matter, but none of them can make that verdict honestly: DKIM keys hide behind names we can only guess, blocklists often refuse to answer public lookups, and MTA-STS, TLS-RPT and BIMI are optional extras.

What it does not do. It does not send an email, connect to your mail servers or give a score out of 100: no mailbox provider publishes weights for these checks, so any number would be made up. It also cannot tell whether a message lands in the inbox or the spam folder. That needs a real message delivered to real mailboxes; we are building that test.

The panel at the top of the result is the overall verdict, taken from SPF, DMARC and MX only: a colored icon and a short label. Under it, each of the eight checks has its own label, a one-line summary and, where the part has a page of its own on this site, a link to it with the full detail. The count next to the heading of the eight checks (for example “3 fail · 4 warning · 1 pass”) covers all eight parts; only SPF, DMARC and MX change the verdict. The list of fixes is ordered: missing essential records first, then other failures, then warnings.

Pass

SPF, DMARC and MX are all set up. Read the rest of the summary: it may still name something else, either “Also worth checking” for a warning, or “another check found a problem” when, for example, the domain is on a blocklist or its MTA-STS policy is broken. Those do not change the verdict, but they are listed first among the other problems.

Warning

The essential records exist and work, but at least one of them should be improved. Typical examples: a DMARC policy of p=none, which only monitors and protects nothing; a DMARC record without an rua= address, so no reports reach you; or a mail server address without reverse DNS.

Fail

At least one essential check definitely failed. The most common causes: no SPF record, no DMARC record, no mail server that can receive email, an SPF record that needs more than 10 DNS lookups, two SPF or two DMARC records (with two SPF records every SPF check ends in an error; with two DMARC records receivers discard both), or a null MX on a domain that sends email (see below). The summary names the most important one first.

Could not check

SPF, DMARC or MX did not get a usable answer: a DNS server timed out, failed or refused. This is not a pass and not a fail. We never count a missing answer as good or bad. If another essential check definitely failed, the verdict is Fail anyway, because that failure is certain. Try again in a minute; if it stays, your domain's DNS servers may be unreachable or DNSSEC may be broken.

When part of the check could not finish

Each of the eight checks gets 15 seconds. A check that is still running then is stopped: what it had not finished is marked unknown, the answers it had already received stay in the raw evidence, and the result shows the limit in the “Safety limits” box, so a cut-short check never looks complete. Limits that fire inside a check, such as the cap on DNS lookups, are listed there too.

Rarely, part of a check's output cannot be read. That is a fault on our side, not a finding about your domain: the unreadable part is left out and the result says so. If the form says the input is not a domain, enter the part after the @ of an email address, such as example.com.

Null MX on a domain that sends email

A null MX record (MX 0 .) tells the world that a domain accepts no email at all (RFC 7505). That is right for a domain that never sends mail. But if the same domain's SPF record authorizes servers to send, its mail has a return address that cannot receive replies or bounces, and receivers may reject it: RFC 7505 says such a domain “risks having its mail rejected”, and Postfix, for example, refuses it with a 550 error when told to check sender domains. This is the one problem only a combined check can see, so it is a Fail here even though SPF and MX pass on their own pages.

Decide what the domain is for. If it sends email, replace 0 . with your mail provider's MX records. If it never sends email, change SPF to v=spf1 -all and keep the null MX.

Work down the list of fixes in the result: it starts with what gets mail rejected today. Every record goes to the DNS provider your domain's NS records point to, which is not always where you bought the domain. The step-by-step clicks for Cloudflare, GoDaddy and Namecheap are on the TXT record lookup page; MX and CNAME records are added in the same dialog with a different type.

1. One SPF record that lists every sender

A domain has exactly one SPF record, at @. Two records make every SPF check end in an error (RFC 7208 §4.5), so to add a sender, add its include: to the record you have. What each common provider asks for:

A domain that sends through both Google Workspace and Microsoft 365 publishes one record with both includes:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

Keep it within 10 DNS lookups: every include:, a, mx, ptr, exists: and redirect= counts, including the ones inside the includes (RFC 7208 §4.6.4).

2. Turn on DKIM signing at every sender

DKIM is switched on where your mail is sent from, not only in DNS: the provider creates the key and gives you the record to publish.

• Google Workspace: in the Admin console go to Menu > Apps > Google Workspace > Gmail, select Authenticate email, generate a key (2048-bit if your DNS provider accepts it; the default selector is google), publish the TXT record it shows at google._domainkey, then select Start authentication.
• Microsoft 365: in the Microsoft Defender portal go to Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM, open your domain and copy the two CNAME records for selector1._domainkey and selector2._domainkey. Microsoft says the values in its articles are for illustration only, so take yours from the portal. Publish them, then turn on Sign messages for this domain with DKIM signatures.
• Zoho Mail: you choose the selector name in the Zoho admin console, which then shows the TXT record to publish.
• SendGrid: domain authentication gives CNAME records for the selectors s1 and s2.
• Mailgun: the DNS records page of your sending domain in Mailgun shows the DKIM record to add.
• Amazon SES: Easy DKIM gives three CNAME records to publish for the verified domain.

At Cloudflare, keep DKIM CNAME records set to DNS only: a proxied name is answered with Cloudflare's own addresses instead of the CNAME, so receivers never reach the key.

3. Publish DMARC, then tighten it

Start with a policy that only collects reports, as a TXT record at _dmarc (use an address that can receive mail):

v=DMARC1; p=none; rua=mailto:[email protected]

This is enough for Google's and Yahoo's bulk sender rules, but it protects nothing. Read the reports for a few weeks, fix every legitimate sender whose mail fails DMARC (neither SPF nor DKIM passes for your domain), then move to p=quarantine and finally p=reject. Keep one DMARC record: with two, receivers discard both (RFC 9989 §4.10).

4. MX records that match your mail provider

• Google Workspace: a single MX record smtp.google.com with priority 1.
• Microsoft 365: one MX record whose value Microsoft gives you: it ends in mail.protection.outlook.com or, for many domains added since July 2026, in mx.microsoft; copy the exact value from the Microsoft 365 admin center (Settings > Domains).
• Zoho Mail and others: copy the MX values from your provider's admin console; they differ by data center.
• A domain that receives no email: publish a null MX, MX 0 ., instead of nothing.

Remove MX records of a provider you no longer use: mail sent to them is lost or bounced.

5. Then the optional protections

When the essentials pass, add TLS-RPT to receive reports about encrypted delivery to you, MTA-STS in testing mode and later enforce, and BIMI once DMARC is at quarantine or reject. The exact records for MTA-STS and BIMI are on the MTA-STS checker and BIMI checker pages; the TLS-RPT record is shown below under TLS-RPT.

What each part checks, and what its own label means. Where a part has a page of its own on this site, the link after it opens that page.

SPF

Passes when there is exactly one SPF record, it can be evaluated within 10 DNS lookups, and it ends with a clear rule for everyone else (-all or ~all). Fails when the record is missing, when there are two, when it needs too many lookups or has a syntax error (receivers then treat SPF as broken), or when it ends in +all, which lets any server send mail as you. A record that ends in ?all or has no all at all is a warning.

DMARC

Passes when _dmarc.example.com (or the parent domain's record) asks receivers to quarantine or reject failing mail. p=none is a warning: receivers only report. A policy in test mode (t=y) or with pct below 100 (older receivers then apply it to only part of the mail) is also a warning, and so is a record with no report address (rua): without reports you cannot see who sends mail in your name. Most other problems the DMARC check finds, such as a report address that has not agreed to receive your reports, are warnings too. A missing record, two records, a record receivers cannot read, or a report address list in which no address is valid is a failure.

MX (incoming mail)

Passes when the domain has mail servers with public addresses, or deliberately declares with a null MX that it receives no mail. Fails when there is no MX record and no address to fall back on, when none of the listed mail servers has a usable public address, or when a null MX is mixed with ordinary MX records. No MX record but an address of its own (mail then goes to that address), or a mail server address without reverse DNS, is a warning.

DKIM

DKIM keys live at names chosen by whoever signs your mail (selector._domainkey.example.com), and DNS cannot list them. We try 43 names that common providers use. A working key there passes. Finding none is a warning, not proof that DKIM is missing: large senders often use their own names. The selector of your mail is the s= tag in the DKIM-Signature header of a message you sent; check it by looking up selector._domainkey.example.com (your selector and domain) with the TXT record lookup: a DKIM key is a TXT record at that name. Gmail, Yahoo and Microsoft do require DKIM from bulk senders, so this part does not decide the verdict only because we cannot see it reliably.

Domain blocklists

We ask public domain blocklists whether the domain is listed. A listing on a list that receivers use to block mail is shown as a failure and named first among the other problems; informational lists only warn. Many lists refuse lookups that come through large public DNS resolvers, so “could not check” is common here and says nothing about your domain.

Spamhaus is a special case. Its rules allow free lookups only when Spamhaus can tell which network they come from, for example from a DNS resolver run on the checker's own network under a name Spamhaus can trace back to it, so we ask Spamhaus only through our own resolver. When the result says “Spamhaus DBL not checked”, we did not ask Spamhaus on that run. That means “unknown”, not “not listed”; you can look the domain up yourself on Spamhaus's own website.

MTA-STS

MTA-STS tells other mail servers to deliver to you only over verified encryption. Without it, mail is delivered as before, so “not set up” is only a warning. A policy in enforce mode that is broken, for example one that does not list your real MX hosts, can stop mail from reaching you: that is shown as a failure high in the list, even though it does not change the verdict. On a domain with a null MX it does not apply. Details: MTA-STS checker.

TLS-RPT

A TLS-RPT record (v=TLSRPTv1; rua=mailto:… at _smtp._tls.example.com) asks other servers to send you reports about encrypted delivery to you, including failures. It only sends reports, so “not set up” is a warning. You can see the record with the TXT record lookup.

BIMI

BIMI lets some mailbox providers show your logo next to authenticated mail. It is opt-in, so “no record” is a warning. It requires DMARC at quarantine or reject, so a BIMI record next to a p=none policy is reported as a problem. Details: BIMI checker.

A domain you own but never use for email can still be used by others to send mail in its name. The UK government's guidance for such domains publishes four records, and this check recognizes the pattern:

example.com.              MX   0 .
example.com.              TXT  "v=spf1 -all"
_dmarc.example.com.       TXT  "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; fo=1; rua=mailto:[email protected]"
*._domainkey.example.com. TXT  "v=DKIM1; p="

With the null MX and v=spf1 -all in place, advice that only matters for a domain that sends or receives mail (turn on DKIM, add BIMI, set up MTA-STS and TLS-RPT) is left out of the list of problems, and each part says why. The DKIM and BIMI parts may still show Warning; for a domain that sends no email this needs no action, and it does not change the verdict. The reports address must be on a domain that receives email, not on the parked domain itself, so for such a domain the fix for a missing rua names no address, only this rule. If that address is outside example.com, its domain must also publish a TXT record at example.com._report._dmarc.example.org with the value v=DMARC1, or receivers will not send the reports (DMARC report services do this themselves).