Email Health Check

What the Email Health Check looks at

The Email Health Check reads your domain's public DNS and groups what it finds into four pillars. Each pillar answers one question.

It does not log in to anything, send test mail or read your mailboxes. Everything comes from DNS and, for MTA-STS, the public policy file.

How each check is graded

Every individual check gets one of five statuses:

• Pass. The record exists, is valid and follows current guidance.
• Warning. It works, but something is weak or risky. Examples: SPF ending in ?all, DMARC at p=none, MTA-STS in testing mode, or SPF close to its limit of 10 DNS lookups.
• Fail. The record is missing where it's needed, is invalid, or will cause errors. Examples: two SPF records, SPF over the 10-lookup limit, or a DMARC record with a syntax error.
• Not tested. We couldn't run the check from outside. The usual case is DKIM: you choose the selector name, and if we can't find it, the result is unknown, not broken.
• Not applicable. The check doesn't make sense for this domain. A domain that publishes Null MX doesn't need MTA-STS, for example.

How the score is calculated

Each pillar shows its own status, so you can see at a glance which area needs work.

The overall score is calculated only over the checks that could run. Not tested and Not applicable checks are left out, not counted as failures. Next to the score we show a coverage figure: the share of checks that actually ran. A score of 90 with 60% coverage tells you less than a score of 90 with full coverage. Read them together.

Email intent: what the domain is for

Before grading, we classify the domain by what its DNS says it does with mail. This changes which checks apply.

A domain that intentionally doesn't receive mail isn't failing because it has no MX. It should say so explicitly. The recommended setup for a parked or no-mail domain is:

example.com.          MX   0 .
example.com.          TXT  "v=spf1 -all"
_dmarc.example.com.   TXT  "v=DMARC1; p=reject;"

RFC 7505 says a domain that publishes Null MX must not publish any other MX record, and that domains used in From addresses shouldn't publish Null MX.

Common problems and fixes

No DMARC record. Start in monitoring mode and add a reporting address:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Then move toward quarantine and reject once your reports show all legitimate mail passing. Our guide on moving DMARC from none to reject has the steps.

SPF PermError. Usually too many includes or two SPF records. Merge into one record and remove unused senders. See fixing too many SPF DNS lookups.

MTA-STS missing. Publish a TXT record and a policy file served over HTTPS:

_mta-sts.example.com.  TXT  "v=STSv1; id=20261009T000000"

Policy at https://mta-sts.example.com/.well-known/mta-sts.txt:

version: STSv1
mode: testing
mx: mail.example.com
max_age: 604800

Start in testing, watch TLS-RPT reports, then switch to enforce. Change the id every time you edit the policy.

No TLS-RPT. Add a reporting address so senders can tell you about TLS failures:

_smtp._tls.example.com.  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Limitations

• The score is about DNS configuration, not spam-filtering effectiveness. It can't tell you how much spam or phishing reaches your users.
• An MX record pointing at a filtering service doesn't prove mail is filtered. A sender can still deliver straight to your mail server if it accepts direct connections.
• DKIM can only be checked for selectors we can find. Use the DKIM Checker with your own selector.
• DNS is cached. A change you just made may take time to appear, depending on its TTL.
• Results are a snapshot. Records change; re-run the check after any change.

Related guide

New to these records? Start with SPF vs DKIM vs DMARC: what each one proves.