How to use the email security checker
- Enter the domain that appears after the @ in your email addresses and press Check records.
- If you know the DKIM selector (the s= value in a DKIM-Signature header of a real message), add it so the exact key is checked; common selectors are tried anyway.
- Read the fix-first list, then each section: the record as published, followed by findings with why it matters and the recommended change.
- Copy a record or the whole report to hand to your DNS or mail administrator, and re-check after the change has propagated.
Features
- MX records sorted by priority, including null MX detection for domains that do not receive mail
- SPF parsed with the all qualifier, mechanisms and includes resolved one level deep so the 10-lookup limit is counted against real records
- DMARC policy, subdomain policy, percentage, alignment and aggregate report addresses
- DKIM lookups for your selector and up to 12 common selectors in parallel, with key type and approximate RSA size
- MTA-STS TXT record plus the HTTPS policy file, checked for mode, max_age and coverage of every MX host
- TLS-RPT, DNSSEC validation status from a validating resolver, CAA issuance restrictions and BIMI (informational)
- Copy-ready examples for missing SPF, DMARC, MTA-STS, TLS-RPT and CAA records, and a plain-text report
What each record does
SPF lists the servers allowed to send mail for the domain and ends with a qualifier: -all rejects everyone else, ~all marks them suspicious, ?all says nothing, and +all disables the check. Receivers give up after ten DNS lookups, which is why includes are expanded here. DKIM signs each message with a private key; the public key sits at selector._domainkey.domain, and only the sender knows the selector. DMARC ties the two together: it tells receivers what to do when neither SPF nor DKIM aligns with the From address (none, quarantine or reject) and where to send reports.
MTA-STS lets you require verified TLS for mail delivered to your MX hosts, and TLS-RPT is where senders report when that fails. DNSSEC signs the zone so resolvers can detect forged answers. CAA names the certificate authorities allowed to issue for the domain. BIMI displays a logo next to authenticated mail and only works with DMARC at quarantine or reject.
About DKIM selectors
There is no way to enumerate DKIM keys from the outside: the selector is chosen by whoever sends the mail (Google uses google, Microsoft 365 uses selector1 and selector2, many providers use their own names). The tool tries the selector you provide and a list of common ones, so a miss means only that none of those names has a key, not that DKIM is absent. Open a message sent from the domain, view its headers and copy the s= value from the DKIM-Signature line to check the real key.
Limitations and responsible use
Only public DNS queries and one HTTPS request for the MTA-STS policy file are made; no mail is sent and no mail server is connected to. Records are read from the resolver our server uses, so a change you made minutes ago may not be visible yet. Only check domains you own or are authorised to assess, and remember that a domain with perfect records can still be misused through a compromised account.
- SPF includes are expanded one level deep; deeper nesting still counts for receivers but is not followed here.
- At most 12 DKIM selectors and 10 SPF includes are resolved per check to keep the query load reasonable.
- DNSSEC status comes from a validating public resolver; 'unknown' means that lookup failed, not that the zone is unsigned.