The three groups
- DNS
- Does the domain exist, who controls it, and where does its mail arrive? These answer the questions everything else depends on.
- Authentication
- SPF, DKIM and DMARC - the three records that decide whether a receiver believes a message really came from you. These carry the most weight in the score.
- Hardening
- Protections beyond the basics. Missing these is common and is not an emergency; having them puts you ahead of most domains.
Every check
| Check | Group | What it looks at |
|---|---|---|
| Domain resolves | DNS | The domain exists in public DNS and answers queries. |
| Nameservers identified | DNS | Which provider is authoritative for this zone - that is who can publish the fixes. |
| MX records | DNS | Who receives mail for this domain. |
| SPF record | Authentication | SPF lists the servers allowed to send as you. Present, and syntactically valid? |
| SPF lookup budget | Authentication | SPF is capped at 10 DNS lookups across the whole include chain. Go over and receivers stop evaluating it entirely. |
| BIMI | Hardening | Shows your verified logo next to your mail in supporting inboxes. Requires DMARC enforcement first. |
| DKIM selectors | Authentication | DKIM signs your mail cryptographically. We probe the selectors the common providers use. |
| DMARC record and policy | Authentication | DMARC tells receivers what to do with mail that fails SPF and DKIM: none, quarantine or reject. |
| DMARC reporting address | Authentication | Without rua= nobody is collecting the reports, so you never find out who is spoofing you. |
| Subdomain policy and rollout percentage | Authentication | sp= covers your subdomains; pct= controls how much of your mail the policy applies to. |
| DNSSEC | Hardening | Signs your DNS answers so an attacker cannot forge the records above. |
| MTA-STS | Hardening | Forces inbound mail to arrive over TLS instead of silently downgrading to plain text. |
| TLS-RPT | Hardening | Reports failed TLS connections to your mail servers, so downgrade attacks are visible. |
The "what it looks at" column is the check service's own description - the same sentence that appears beside the check while it runs.
What the four verdicts mean
- Pass
- Configured, and configured correctly.
- Warn
- Present but weaker or more fragile than it should be.
- Fail
- Missing, broken, or present and doing nothing.
- Not applicable
- The check does not apply to this domain. Left out of the score, never counted as a failure.
Every check page below spells out what each verdict means for that check, because "warn" on a lookup budget and "warn" on a subdomain policy call for very different responses.
What these pages do not do
They explain the checks. They are not a specification of the standards - where a detail matters more than this, the RFC is the authority and this is a summary of it.