Email Deliverability Checker

How it works

1. Enter your domain. Just the domain — yourcompany.com. An email address or a full URL works too; we take the domain from it.
2. We read your public DNS. The same records Gmail, Outlook and Yahoo read when they receive a message from you: MX, SPF, DKIM and DMARC, plus the major blocklists.
3. You get a grade and a reason. Each check is pass, warning or fail, with what it found and what it means in plain language.
4. Copy the fix. Anything broken comes with the DNS record to add, ready to paste into your registrar or DNS host.

What each check actually means

MX — can your domain receive mail at all?

MX records point at the servers that accept mail for your domain. If they are missing, nothing can reach you. We also use them to work out who runs your email, which is what lets the DKIM check look in the right place.

SPF — which servers are allowed to send as you

A single TXT record listing every service permitted to send email using your domain. Two things go wrong with it. The first is simply not having one. The second is subtler and far more common: SPF permits at most 10 DNS-querying mechanisms across the entire record, including everything each include: pulls in behind the scenes. Every new tool you connect adds to that count, and the day it passes ten your SPF stops working entirely. This checker follows the whole chain and counts it the way a receiving server does.

The ending matters too. -all tells receivers to reject anything not on the list. ~all is a softer "treat as suspicious". +all allows anyone to send as you and should never be there.

DKIM — the signature that proves it was really you

Your mail server signs each message with a private key; the matching public key sits in your DNS. Receivers check the signature to confirm the message came from you and was not modified along the way. Unlike SPF, DKIM survives forwarding, which is why mail sent through a mailing list can still pass.

DKIM records live at selector._domainkey.yourdomain.com, and the selector name is chosen by your provider. There is no way to list them, so a checker has to guess. Most check a handful of generic names and report "not found" for anything else. This one reads your MX records first, identifies the provider, and checks that provider’s selectors as well.

DMARC — what happens when the other two fail

DMARC sets the policy. p=none only collects reports and blocks nothing. p=quarantine sends failures to spam. p=reject refuses them outright. It also carries a rua= address, where receivers send daily reports showing exactly who is sending mail using your domain — including anyone spoofing it.

Most domains that have DMARC at all are sitting on p=none, often for years. That is a reasonable place to start and a poor place to stay: it gives you visibility but no protection.

Blocklists

We check your mail servers against Spamhaus, SpamCop and Barracuda. A listing usually follows a compromised mailbox or an open relay, and it will stop mail arriving no matter how good your records are.

The records, and what good looks like

Changes to DNS are not instant. Most appear within minutes, but allow up to 48 hours before concluding something has not worked, and re-run the check rather than guessing.

If your mail is going to spam, work through this in order

1. Run the check above. Fix anything marked fail before looking at anything else. A missing SPF or DMARC record outweighs every other factor.
2. Confirm the From domain matches what you authenticated. Sending as [email protected] while only mail.company.com is authorised is a common and invisible mismatch.
3. Check you only have one SPF record. Two records is not twice as safe; it is invalid, and SPF fails outright. Merge them into one.
4. Look at your sending history. A domain that has never sent email and suddenly sends a few hundred messages looks exactly like a spammer. Build volume gradually.
5. Then look at content. Link-heavy messages, attachments, and single-image emails with almost no text all attract filtering — but only once authentication is already correct. Fixing subject lines while SPF is broken wastes everyone’s time.

Common situations

Limitations, honestly

• This reads DNS. It cannot see your sending reputation, your complaint rate, or how a specific mailbox provider treats you — all of which matter once authentication is correct.
• DKIM detection is best-effort. We check your provider’s selectors and the common ones, but a custom selector may not be found. "Not found" means "not found at the usual names", not "does not exist".
• Blocklist results can be rate limited. When that happens we say the result is unavailable rather than reporting a clean pass we cannot stand behind.
• A perfect score means your records are right. It does not guarantee the inbox — content and sending history still count.
• 10 checks a day per visitor, which is plenty for fixing a domain and re-testing.

Email deliverability questions

Related tools