How the checks work
No black box. Here is exactly what happens when you enter a domain.
What we query
Every check reads public DNS. Nothing is sent to your mail server, no message is delivered, and no port is probed. For a full report we resolve:
- MX records, and an A/AAAA lookup for each mail exchanger to confirm it resolves
- TXT at the domain, for SPF, and every record reached through an include or redirect
- TXT at
_dmarc, plus the organisational domain for subdomains - TXT at
selector._domainkeyfor DKIM - TXT at
_mta-sts, and the policy file over HTTPS - TXT at
_smtp._tlsanddefault._bimi
The MTA-STS policy file is the only request that leaves DNS, because the specification puts it at a fixed HTTPS URL. We do not follow redirects when fetching it — the specification forbids that too.
Why there is no AI in the diagnosis
Parsing an SPF record and counting its DNS lookups is a deterministic problem with one correct answer. A language model would introduce a chance of being confidently wrong about something that can simply be computed, so the diagnostic engine contains none. Every finding you see comes from code that reads a record and applies the relevant specification, and that code is covered by tests against fixtures of malformed and edge-case records.
Where a model may be used at all is downstream of the diagnosis — rewriting a finished set of findings into a friendlier summary. It can never introduce a finding, change a severity, or invent a record.
Observed versus inferred
The distinction matters enough that the interface labels it. A finding is observed when it comes from a record we read: your SPF record has two entries, your DKIM key is 1024 bits. These are stated plainly, because they are facts about published DNS.
A finding is inferred when we reasoned from indirect evidence. Identifying that you use Google Workspace from your MX hostnames is an inference — a security gateway can sit in front of any backend, and SPF includes often outlive the service that needed them. Anything inferred is labelled as such, and we say what we matched on so you can judge it yourself.
DKIM discovery deserves a specific note. DNS offers no way to list the selectors a domain uses, so any checker can only probe names it already knows about. When we report that no key was found, the honest claim is “not found at the selectors we checked”, and that is what we say.
How severity is decided
Severity reflects what a problem breaks, not how unusual it is. Two SPF records is critical because it makes SPF return a permanent error for all of your mail. A 1024-bit DKIM key is low because it works today and is a maintenance item. The score at the top of a report is a summary of the findings beneath it — it is not a prediction, and we never present it as one.
What monitoring adds
The same engine, on a schedule, with the result compared against the previous snapshot. You are emailed when a finding appears, gets worse, or resolves — not when nothing has changed. Most authentication breakage is caused by someone else editing their own records, so the value is in noticing without having to remember to look.