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. The DNS propagation checker is the exception: it sends the same question to 9 public resolvers run by other companies and compares their answers (see the privacy policy). 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”.

Two tools never send what you give them to our server: the DMARC report analyzer and the email header analyzer run entirely in your browser, on the report you open or the header you paste or open. Links from a header analysis to our other tools start ordinary checks: opening one sends only that address or domain.

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

• Pass (a green circle with a tick): we could check this, and it meets the standard.
• Warning (an amber circle with an exclamation mark): it works, but something is risky, outdated or likely to break; the finding says what.
• Fail (a red circle with a cross): 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 (a violet circle with a question mark; its labels have a dashed border, and so does the large verdict card, which also has faint stripes): 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. The MX lookup has one exception: reverse DNS that it could not check is listed as “could not check”, but like missing reverse DNS it does not change the verdict, there or in the domain health check. 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.

Four 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, and Unknown (not “Could not check”) when the file gives no clear DMARC result. The email header analyzer bases its overall verdict only on the SPF, DKIM and DMARC results it takes to be the receiving mail server's, not on its other findings, so a Fail finding (such as a DKIM signature made with rsa-sha1) can appear under an overall Pass. It shows Unknown (not “Could not check”) when those results are missing, disagree or do not settle the question, and marks observations that are not a verdict as Note. The DNS propagation checker compares the answers of 9 public resolvers: one that gave no usable answer is listed as “could not check” among the findings but left out of the comparison, so the others still decide the verdict. When more than half give no usable answer, or 2 or more report a server failure (SERVFAIL), the whole result is “could not check”.

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; all networks inside one IPv6 /56 together get 4 times that. Each domain, subdomains included, and each IP address 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; all networks inside one IPv6 /56 together get 4 times these per-domain limits too. The DNS propagation checker, which sends every check to 9 public resolvers, has stricter limits of its own: 6 checks per 60 seconds from one address, 3 fresh checks of the same domain per 60 seconds and 30 per 60 seconds for one domain from everyone together, each with a short burst allowance; all networks inside one IPv6 /56 together get 4 times the first two. The blacklist checker, which asks public blocklists run by other organizations about every address or domain it checks, has the same limits as the DNS propagation checker. 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.

The deliverability test reads a real message, delivered the real way. You press Start test and send one ordinary message, from your own mail system, to the addresses you get (usually three). Your mail system delivers it over SMTP, exactly as it delivers mail to anyone, so we see what every receiver sees: the address of the server that sent it, the name it greeted us with, whether it used encryption, and the message itself, byte for byte. We never send anything ourselves.

The first address belongs to our own mail server. We keep the message as it arrived and check it on our server: SPF, every DKIM signature and DMARC as they came out for this message, ARC, the reverse DNS of the sending server and its greeting, encryption, the sending server and the domains of the message on DNS blocklists (the From domain, the return address, the domains of passing DKIM signatures and up to 5 link domains), the required headers and one-click unsubscribe. The whole message also goes to rspamd, an open-source spam filter that runs on the same server; its features that would send the message's text, or fingerprints of it, to other services are turned off (it still downloads its own reference lists from rspamd.com, which tells rspamd.com nothing about your message), and we never open the links in your message. While we check it, nothing from your message leaves our server except in DNS lookups: of the domains it names, of the sending server's address and greeting name, and for the blocklist checks.

The Gmail address belongs to our own Google Workspace mailbox. We read that mailbox with read-only access and look for your copy every few seconds, for 30 minutes from the start of the test and at least 15 minutes after our copy arrives: whether Gmail filed it in the inbox, under which tab, in spam or elsewhere. We never move, open or answer it. A copy we did not see in that time is shown as “could not check”, not as a failure: it may arrive later, or Gmail may have refused it, which a mailbox cannot show. The row is labeled Gmail (Google Workspace) because our mailbox is a Google Workspace account, and Google says its sender requirements and their enforcement apply only to mail sent to personal Gmail accounts, not to Workspace accounts. So a personal Gmail account can file the same message differently. Our mailbox has no approved or blocked senders, allowlists, filters or custom spam rules.

The Microsoft address belongs to our own Microsoft 365 business mailbox. We read it through Microsoft Graph, with read-only access that covers this one mailbox only, for the same time: whether Microsoft put your copy in the inbox, marked Focused or Other, in Junk Email or elsewhere. We never move, open or answer it. A copy we did not see in that time is again “could not check”: Microsoft may also hold a message in quarantine, outside the mailbox, where we cannot see it. The report shows Microsoft's own Authentication-Results and its filtering report as written, without scoring them, with Microsoft's description of their fields one link away. The row is labeled Outlook (Microsoft 365) because it is a business mailbox: Outlook's requirements for large senders are about mail to its consumer addresses (outlook.com, hotmail.com and live.com), and a personal Outlook.com account can file the same message differently. Our tenant runs Microsoft's default anti-spam policy, and our mailbox has no allowed or blocked senders, allowlists, mail flow rules or inbox rules.

If one of our mailboxes has already taken as many test messages as we allow per minute, hour or day, a new test gets no address in that mailbox, and its page says so; the other addresses work as usual.

The score out of 10 is our own weighting, not a number from Gmail or any standard. We start at 10 and take points off for each problem, and the report lists every deduction with its reason. For example: no DKIM signature costs 1 point, no DMARC record 1, a sending server on a blocklist that receivers use to refuse mail 3, and the content costs from 0 to 4 points, depending on the spam filter's score for it (authentication and blocklist rules of the filter are left out, so nothing counts twice). Some problems cap the score: when neither SPF nor DKIM passed it is at most 3, and when the spam filter scores the content 15 or more it is at most 3. Where Gmail and Microsoft filed the copies is shown next to the score and does not change it. The weights are our own judgment, built on what Gmail, Yahoo and Outlook.com require of senders and on the standards; where a finding rests on a standard or a provider's page, the report links to it.

As everywhere on this site, a part we could not check (a DNS timeout, a blocklist that did not answer, the spam filter not answering) takes nothing off. The score is then marked incomplete and names the missing parts: a gap never counts as a pass or as a fail. The report and its evidence, including every DNS answer and the spam filter's raw answer, can be downloaded for 7 days; then the test is deleted (see the privacy policy). One IP address (for IPv6, one /64 network) can start 5 tests an hour and 20 a day; all networks inside one IPv6 /56 together can start 20 an hour and 80 a day.

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.