Email domain health check
One scan covering every check, with the record we read and the standard the rule comes from attached to each result.
What a complete check covers
| Check | Question it answers |
|---|---|
| SPF | Which servers may send using this domain, and does the record still evaluate within the ten-lookup limit? |
| DMARC | What should receivers do when authentication fails, and are you receiving reports about it? |
| MX | Where does mail for this domain go, and do those hosts resolve? |
| MTA-STS | Is TLS required for inbound mail, and is the published policy actually retrievable? |
| TLS reporting | Will you find out when TLS to your mail servers fails? |
| DKIM | Which known selectors are published, and are any revoked, in testing mode, or undersized? |
The order to fix things in
- Anything marked critical. These mean a protection is not in effect at all, such as two SPF records, two DMARC records, an SPF record over the lookup limit. They are usually a single-line fix.
- DMARC reporting. Add
ruaif it is missing. You cannot safely tighten anything without the visibility it gives you. - Sender inventory. Use the reports to find every service sending as your domain.
- Policy strength. Move DMARC toward enforcement once the inventory holds no surprises.
- Transport hardening. MTA-STS and TLS reporting, in testing mode first.
Honest limits
This is a configuration check. It reads public DNS and one public well-known HTTPS path, and reports what it finds against the published standards. It does not measure inbox placement, and it cannot enumerate DKIM selectors, and no external scanner can, because DNS provides no mechanism to list them. Where a limit applies, the report says so at the point it matters rather than in a footnote.