A domain's mail setup is really two separate systems that happen to get diagnosed together: can mail reach this domain (MX), and can mail claiming to come from this domain be trusted (SPF, DKIM, DMARC) — plus a third question that has nothing to do with configuration at all: is this domain's own mail server currently flagged as a spam source (DNS blacklists). Mail Health Check runs all five together, against one domain, in one pass.
Delivery vs. Authentication
MX records only control inbound mail — where messages sent to this domain actually get delivered. They say nothing about whether a message claiming to be sent from this domain can be trusted. That's a separate, three-part system: SPF lists which servers are authorized to send on the domain's behalf, DKIM cryptographically signs outgoing mail so it can't be altered in transit without detection, and DMARC tells receiving servers what to actually do with mail that fails those checks. A domain can have a perfectly healthy MX record and still be trivially easy to spoof if none of the other three are configured — the two halves are independent, and both worth checking.
Why SPF, DKIM, and DMARC Need Each Other
SPF and DKIM each answer a narrow question on their own — "was this sent from an authorized server" and "was this message altered in transit" — but neither one, alone, tells a receiving server what to do when a message fails. DMARC is the policy layer on top of both: it grades whether a message aligns with SPF and/or DKIM, and publishes what should happen to mail that doesn't — monitor it, quarantine it, or reject it outright. A DMARC record with no SPF or DKIM behind it has nothing to actually grade; SPF and DKIM with no DMARC record leave every failure unpunished. All three, together, are what "mail authentication" usually means.
The DKIM Check Is Best-Effort
Unlike MX, SPF, and DMARC — each published at a fixed, well-known DNS name — a DKIM key is published per selector, and there is no DNS record anywhere that lists which selectors a domain actually uses. The real selector only appears in a signed email's own DKIM-Signature header (its s= tag). Mail Health Check checks a handful of the most common selectors used by major providers and conventions — catching the majority of real-world setups — but a miss here means "not found under a common selector," not "DKIM isn't configured." If you already know the exact selector, check it directly with the DKIM Checker for a definitive answer.
Blacklist Status Is a Different Kind of Problem
MX, SPF, DKIM, and DMARC are all about configuration — get them right once, and they stay right until something changes. Blacklist status is not: a domain's mail servers can be correctly configured on every other check and still land on a DNS-based blocklist because of a compromised account, a misbehaving script, or a shared IP another tenant abused. This check queries the domain's resolved mail server IPs directly against major blocklists (Spamhaus, SpamCop, Barracuda, and others) so a sudden deliverability problem with no configuration change behind it doesn't go unexplained.
When to Use Mail Health Check
- Getting a first-pass read on a domain's entire mail setup — delivery and authentication both — without running five separate tools.
- Diagnosing mail that's arriving but landing in spam, which is usually an authentication gap (SPF/DKIM/DMARC), not a delivery one.
- Diagnosing mail that isn't arriving at all, which is usually MX or blacklist status, not authentication.
- A quick health check after migrating mail providers, before assuming the new setup is complete.
Frequently Asked Questions
My mail is arriving but landing in spam — what should I check first?
Usually SPF, DKIM, and DMARC, not MX — if mail is arriving at all, delivery already works. Spam-folder placement is almost always an authentication signal: a missing SPF record, an unsigned DKIM, or a DMARC policy set to "none" all make a message look less trustworthy to the receiving server's spam filter.
My mail isn't arriving at all — what should I check first?
MX records and blacklist status. A missing or unresolvable MX record means there's nowhere for inbound mail to go; a blacklisted mail server IP means outbound mail may be getting silently rejected by other providers. Neither is an authentication problem.
The DKIM check says "not found" — does that mean DKIM isn't set up?
Not necessarily. This check only tries a handful of common selectors, and a domain's real selector could be something this check doesn't guess. Check the raw headers of an actual email from this domain (the DKIM-Signature header's s= tag) for the real selector, then verify it directly with the DKIM Checker.
Is a DMARC policy of "none" a failure?
Not a failure, but not full protection either — "none" means failing mail is reported on but still delivered normally. It's the usual first step when rolling out DMARC (so a domain owner can see what would be blocked before actually blocking it), but a domain that stays on "none" indefinitely isn't actually stopping spoofed mail, only monitoring it.
Run a full mail diagnostic on any domain with the Mail Health Check tool.