How our checks work

When you enter a domain, our server first cleans up the input (it accepts a pasted URL or an email address and keeps the domain) and then asks DNS for the records the check needs, the way a mail server would. Some checks go further: the MTA-STS and BIMI checks download files over HTTPS from the addresses the domain's records name (the MTA-STS policy; the BIMI logo and its certificate, which can be on another company's server), and checks of mail servers can open a connection to them.

The answers are then compared with the rules of the relevant standard. Each rule in our code is written from the standard's text, and a finding based on a written rule links to that section of the standard, labeled “Rule”. BIMI is not an RFC yet, so its rule-based findings link to the current Internet-Drafts (BIMI, SVG Tiny PS and the mark certificate draft), labeled for example “Rule: BIMI draft §7.3”. Advice that depends on one provider (for example which DKIM selector a sending service uses) links to that provider's own documentation instead, labeled “Source” with the site's address, such as “Source: www.twilio.com”. Other references, such as the W3C SVG Tiny 1.2 specification or the BIMI Group's pages, are labeled the same way, for example “Source: www.w3.org”.

The DMARC report analyzer is different: it runs entirely in your browser, on the file you open, and nothing reaches our server.

Every result, and every finding inside it, has one of four verdicts. Each has its own color, its own icon shape and its own label, so it can be read without color.

• Pass (green, a lit dot in a ring): we could check this, and it meets the standard.
• Warning (amber, triangle): it works, but something is risky, outdated or likely to break; the finding says what.
• Fail (red, square): it breaks the standard in a way that affects delivery or security, for example an SPF record with an error that makes receivers ignore it.
• Could not check (violet, an empty striped capsule): we did not get a usable answer. For example, a DNS, mail or web server did not reply in time, refused the question or sent something we could not decode safely.

“Could not check” is a verdict of its own. It is never shown as a pass or as a fail, because we do not know. A timeout is not proof that a record is missing, and a missing answer is not proof that everything is fine. Try again a minute later; results of this kind are never reused from our cache. The one exception: when the result names the cause as an error in our checker (engine.internal_error), trying again will most likely give the same result, so please tell us.

For a single check, the overall verdict comes from its findings: any fail makes it a fail; otherwise any “could not check” makes it that, so a gap is never covered by a pass or a warning; otherwise any warning makes it a warning. A result lists every finding, most serious first, with a link to the explanation on the tool's page and, where one exists, a ready-to-copy fix. The short line labeled “Decided by” next to the verdict (for example “1 of 4 MX hosts not covered”) is the one fact that decided it.

Two tools work differently, and say so on their pages. The domain health check takes its overall verdict from SPF, DMARC and MX only. Its other five parts (DKIM, domain blocklists, MTA-STS, TLS-RPT and BIMI) each show their own verdict among the findings, including Fail and “could not check”, but they do not change the overall verdict: a Pass there means the three essential records are fine, not that nothing else failed. The DMARC report analyzer never shows Fail for a whole file, because failing mail in a report is often someone else's, stopped by your policy; it shows Review instead.

Under every result is a Raw evidence panel with each DNS question we asked: the name and record type, the resolver that answered, the outcome (for example NOERROR, NXDOMAIN, SERVFAIL or a timeout), the records with their TTL, whether it went over UDP or TCP, and how long it took. The same panel lists HTTPS fetches and mail-server connections, if the check made any.

Download full evidence gives you the complete result as JSON, including the raw DNS messages exactly as they came off the wire. It is always the run you are looking at, never a new check, and we keep it for 15 minutes. With it you, or anyone you send it to, can check our reading of the answers.

• Time limit. A check stops after 20 seconds. Whatever did not answer by then is “could not check”.
• Safety limits. Checks follow the standards' own limits (for example SPF's 10 DNS lookups) and add our own caps on how much they read, so a hostile or broken domain cannot make a check run forever. When a cap stops part of a check, the result says so in a separate box labeled “Safety limits that stopped part of this check”. Nothing is cut short silently.
• Short cache. The same check of the same name within 60 seconds gets the result already made, and the result says how old it is. “Could not check” results are never reused.
• Rate limits. Each IP address (for IPv6, each /64 network) can run 10 checks per 60 seconds, with a short burst allowance on top. Each domain, subdomains included, can be checked 60 times per 60 seconds by everyone together (answers from the short cache do not count). A full domain health check counts as 5 checks of the domain, because it runs eight checks at once. The SMTP test, which connects to someone else's mail server, has stricter limits: 3 tests per 60 seconds from one address and 10 per 60 seconds for one domain from everyone together. These limits protect the servers of the domains being checked. One address can also make 5 fresh checks of the same domain per 60 seconds, with a short burst allowance on top (a full domain health check uses all 5), and 1 fresh SMTP test of the same domain per 60 seconds, again with a short burst allowance. When a limit is reached, the page says how long to wait.

• They never send email. When a check talks to a mail server, it says hello (EHLO or HELO), may ask for encryption (STARTTLS) to read the certificate, and says goodbye (QUIT). It never logs in and never sends MAIL FROM, RCPT TO or DATA, so no message and no mailbox test ever reaches anyone. Our code refuses any other command before it is written.
• They never fetch from private networks. Downloads go over HTTPS only and only to public internet addresses, so a check cannot be pointed at a server inside someone's network.
• They never guess. A value we could not read is reported as unknown, and a value that is truly absent as “not found”, never filled in.

Our rules are written from these documents. A finding based on one of them links to the exact section.

Where a standard changed, we follow the current one: DMARC checks follow RFC 9989, which replaced RFC 7489 in 2026, and the report analyzer reads reports in both formats (RFC 7489 and RFC 9990). Where a standard leaves room, or where we rely on how a provider behaves rather than on a written rule, the explanation says so.