About the Mail Deliverability
This tool runs a full mail-deliverability audit on a domain in a single request and returns one score out of 100 with an A to F grade. It looks up the MX records, parses the SPF policy (counting DNS lookups and reading the all qualifier), resolves the DMARC policy, probes a list of common DKIM selectors, and for the domain's primary mail server checks reverse DNS (forward-confirmed, FCrDNS) and whether its IP appears on any of around ten well-known blacklists. Each dimension is weighted, scored independently, and the failures come back as a ranked list of what to fix first.
It exists to answer whether a domain is set up to send and receive mail reliably without running the SPF, DMARC, DKIM, reverse-DNS and blacklist checks one at a time and mentally combining the results yourself. Use it before launching a new sending domain, when diagnosing why mail from a domain lands in spam, or as a periodic health check after any DNS change touching mail.
Every check here is a read-only DNS lookup plus a reverse-DNS and blacklist probe against the MX host's IP, run server-side against public resolvers. Nothing is sent and no email is required to get a result. DKIM specifically is probed at a fixed list of common selectors since there's no DNS record announcing which selector a domain actually uses. A domain with DKIM working fine under a custom selector can still show a DKIM fail here. For a definitive DKIM verdict against the actual signed message, and for spam-filter scoring, the companion inbox tester sends a real test email instead of inferring from DNS alone.
How to use it
- Enter the domain you send mail from, for example example.com, and submit.
- The tool runs MX, SPF, DMARC, DKIM (common selectors), reverse DNS and blacklist checks in parallel.
- Read the A to F grade and the score out of 100 first for the overall picture.
- Open the per-check breakdown to see exactly which dimension is losing points and why.
- Work through the recommendations list in order, since it's already ranked by what actually costs the most points.
- Optionally pass a custom selectors list if you know your provider's DKIM selector isn't in the common set.
Examples
- Audit a brand-new sending domain before it goes live, catching a missing DMARC record before the first campaign goes out.
- Diagnose a domain scoring a D and find the cause is a missing PTR record on its mail server, not SPF or DMARC.
- Confirm SPF, DMARC and DKIM all pass together after finishing an email-provider migration.
- Check whether a domain's mail server IP has landed on a blacklist after a shared-hosting neighbour started spamming.
- Pass selectors=s1,s2,mandrill to probe a specific provider's non-default DKIM selector instead of the built-in common list.
How the 100-point score is built
- MX: 25 points, fails if the domain has no MX records at all, meaning it cannot receive mail.
- SPF: 20 points, fails if there's no v=spf1 record, if it ends in +all, or if it exceeds 10 DNS-lookup mechanisms.
- DMARC: 20 points, fails if there's no _dmarc record or if its policy is p=none.
- DKIM: 15 points, fails if none of the probed selectors, common list or a custom list you supply, resolve a key.
- Reverse DNS: 10 points, fails if the primary MX host's IP has no PTR record, or its PTR doesn't forward-confirm (FCrDNS).
- Blacklist status: 10 points, fails if the primary MX host's IP is listed on any of the checked blacklists.
- Grade: A at 90 or above, B at 75 or above, C at 60 or above, D at 40 or above, F below 40.
The DKIM selector list and its real limit
A DKIM key lives at selector._domainkey.domain, and the selector is chosen by whoever configured the sending system. There is no DNS record anywhere that announces which one is in use. By default this check probes a fixed list of common selectors: google, default, selector1, selector2, k1, k2, s1, s2, dkim, mail, mandrill, fm1, fm2, fm3, zoho, protonmail, mailjet and smtp, up to 25 in total when you supply your own via the selectors parameter. A DKIM fail here means none of the checked selectors resolved a key, it is not proof DKIM is broken if your provider actually uses something like a date-based string or a customer-specific selector. To find your real selector, look at the s= tag in the DKIM-Signature header of any message you've actually sent, then run the standalone DKIM checker with that exact selector, or send a real message through the inbox tester, which reads whatever selector was actually used from the live signature instead of guessing.
What each failing check actually means
- MX fails: the domain publishes no MX records, so no mail server exists to receive mail sent to it at all.
- SPF fails: either no record exists, +all authorizes any sender, or the lookup count exceeds 10 and would produce a permerror.
- DMARC fails: no _dmarc record exists, or its policy is p=none, meaning nothing is actually blocked on alignment failure.
- DKIM fails: no key found at any probed selector. Check your real selector before treating this as broken.
- Reverse DNS fails: the MX host's IP has no PTR record, or the PTR hostname doesn't resolve back to that same IP (FCrDNS).
- Blacklist fails: the MX host's IP is currently listed on one or more of the roughly ten blacklists checked.
mailcheck versus the inbox tester
mailcheck reads only published DNS records and infrastructure signals. It never sends anything and gives an instant result for any domain, sender or not. The inbox tester instead has you send one real email to a throwaway address, then reads the actual Authentication-Results header the receiving side generated for that specific message, plus a live spam-filter score. Use mailcheck first to fix the DNS-level setup fast, then use the inbox tester to prove a real message from your actual sending system passes end to end, which is the only way to catch a DKIM key mismatch or a sending system that silently isn't signing at all.
Frequently asked questions
How is the mailcheck score calculated?
Six dimensions each carry a fixed weight out of 100: MX 25, SPF 20, DMARC 20, DKIM 15, reverse DNS (FCrDNS) 10, and blacklist status 10. A dimension that passes contributes its full weight, and the total maps to an A to F grade.
Why did DKIM fail here when my provider says it's configured correctly?
This check only probes a fixed list of common selectors since DNS has no way to announce which selector a domain uses. If your provider uses a custom or randomized selector, it simply isn't in that list, which doesn't mean DKIM is actually broken, only that this particular probe couldn't find it.
What counts as a good score?
90 or above (grade A) means every dimension checked out clean. Anything below 60 (grade C or worse) usually points to a specific missing record, most often DMARC or reverse DNS, rather than a broadly broken setup, since the per-check breakdown tells you exactly which one to fix.
Does mailcheck send a test email?
No. Every check is a read-only DNS lookup plus a reverse-DNS and blacklist probe against the mail server's IP. Nothing is sent and no email account is needed. To test a real message, use the inbox tester.
Which server does the reverse-DNS and blacklist check actually run against?
The domain's primary MX host, specifically its first resolvable IPv4 address. That's the machine that actually receives mail for the domain, so its reverse DNS and blacklist status are what matters for deliverability.
Can I check a specific DKIM selector instead of the common list?
Yes, pass a comma-separated selectors list, up to 25, and it replaces the default common-selector probe for that request.
Why is MX worth more points than DKIM?
Without any MX record the domain cannot receive mail at all, which is a more fundamental failure than an authentication gap. The weighting, MX 25, SPF and DMARC 20 each, DKIM 15, reverse DNS and blacklist 10 each, reflects roughly how much each dimension affects whether mail arrives and whether it's trusted once it does.
My domain only receives mail and never sends any, does this still matter?
Yes. A domain that never sends mail benefits from a strict SPF record and a DMARC reject policy specifically because they tell the world nobody should ever be sending mail as that domain, which blocks it from being used to spoof your brand.
Is a perfect 100 score a guarantee my mail reaches the inbox?
No. It confirms the technical foundation, MX, SPF, DMARC, DKIM discoverability, reverse DNS and blacklist status, is fully correct, which is necessary but not sufficient. Inbox placement also depends on sending reputation, list hygiene, content and recipient engagement, none of which a DNS-only check can see.
How often should I re-run this check?
Any time you change mail providers, add or remove a sending tool from your SPF record, or notice a sudden drop in delivery, plus a routine check after any DNS migration, since a single edited record can silently drop the score.