Method, sources and what is not checked

What these pages are

These pages read the DNS records that decide how a domain's mail is received and how mail in its name is judged: MX, SPF, DKIM, DMARC, MTA-STS, TLS-RPT and BIMI. There is a page each for SPF, DKIM, DMARC, MX, MTA-STS with TLS-RPT and BIMI, each with the checker focused on its record; the email doctor's mode Read in my browser reads all seven at once; and this page says how. Until labs.llc build 546 they were a site of their own, ė.email (xn--lea.email in the ASCII form the DNS uses); every address on that name now answers one permanent redirect to its page here.

What the checks do

Type a domain and the page asks the DNS for the records that mail systems consult when a message claims to come from that domain or is addressed to it. Each record is shown exactly as it is published, then taken apart and explained in plain words, with the rule it was read against linked beside every finding. No test message is sent and no mailbox is involved. Everything here is read from public DNS.

How to read a result

Every record gets a card. The tag on the card says what was found: published, missing, not valid. The first sentence says what that means for mail. Under it come the record itself, the findings, and a line that says whether the two DNS operators gave the same answer.

In the doctor's browser mode the panel In plain words puts the cards together: whether the domain can receive mail, what it asks receivers to do with mail that uses its name and fails authentication, whether its SPF record can be evaluated to the end, and whether it protects and monitors transport. There is no score out of 100 there. A number would hide which record is the problem, and the weights behind it would be ours, not the standards'. The doctor's own examination does give a grade, by a rubric it prints in full.

The doctor and these pages

The email doctor and these pages read the same records two ways, and they can differ for the same name. The doctor asks from our server, through one resolver (Google Public DNS at 8.8.8.8, Cloudflare's 1.1.1.1 if that fails), reduces what you type to the registrable domain, grades the records by a printed rubric and writes the records to publish; it also fetches the MTA-STS policy file and reads DNSSEC and CAA. These pages ask from your browser, put every question to two resolvers and compare the answers, read the exact name you type, subdomains included, give no grade, and fetch nothing but DNS answers. Both read DMARC against RFC 9989; the doctor reads the record at the registrable domain, and these pages also walk up the DNS tree when a name has no record of its own.

The method

1. Two resolvers, every time. Each question is sent from your browser to Google Public DNS and to Cloudflare over DNS-over-HTTPS, in JSON. The two sets of records are compared after normalizing what is only notation: the quotes and the splitting of TXT strings, the case and the final dot of host names. Address records are the exception: on 2026-09-28 the two resolvers returned different addresses for the same mail host (smtp.google.com, for one), as load-balanced services do, so for A and AAAA the comparison is whether the name has an address at all.
2. Disagreement is shown. When the two differ, both answers are printed side by side and the page says which one the reading follows. When one operator fails or does not answer within 8 seconds, the page names it. When both fail, the card says the record could not be read and concludes nothing.
3. Records are selected as receivers select them. A TXT answer counts as an SPF, DMARC, MTA-STS, TLS-RPT or BIMI record only if it begins with that record's version tag; everything else at the name is discarded, and the page says when it discarded something.
4. SPF is followed, with guards. Every include and redirect is fetched, to a depth of 10 levels and 40 records, and a record that points back into its own chain is reported as a loop. The lookups are counted in the order a receiver meets them, against the limit of 10.
5. DKIM keys are measured. The value of p= is decoded from base64 and the length of the RSA modulus is read from the key's own structure. It is not estimated from the length of the text.
6. DMARC discovery follows RFC 9989. The record at the domain first, then the DNS Tree Walk.
7. No score. Findings are marked in order, caution or problem, each with the rule it comes from. They are not added up.
8. Dated. The answers are live. The panel This run gives the moment the questions were put, in UTC, and the documents below the date each was read.

What is not checked

• No mail server is contacted: not the hosts in MX, not their TLS, not their certificates.
• No file is fetched from the domain: not the MTA-STS policy, not the BIMI logo, not its certificate.
• No message is sent or received, so nothing here says whether a particular message passes SPF, DKIM or DMARC.
• SPF macros are counted and not expanded.
• The public suffix list of RFC 7489 is not used; a receiver that still follows that RFC may choose a different Organizational Domain for a name under an unusual suffix.
• DNSSEC validation is left to the two resolvers; these pages do not show its state (the doctor does).
• Both resolvers answer from a cache, so a record changed a moment ago may still appear in its old form.

Privacy, as the code has it

• The domain you type is sent to dns.google and cloudflare-dns.com, and to no other host. Those requests carry no cookies and no referrer. They do carry the Origin header that a browser adds to every request a page makes to another site, so the two operators can see that a question came from a page of labs.llc.
• The domain is not added to the page address, not written to local storage or a cookie, and not sent to labs.llc's server.
• If you type an email address, the part before the @ is removed in your browser before anything is sent.
• labs.llc keeps a few settings in your browser, and none of them is a domain you checked: the edition you chose (labs_edition, in local storage and a cookie), the recent searches of the site search, and, on the doctor, the instrument it draws. Because the reading is kept nowhere, changing the edition, which reloads the page, clears it.
• labs.llc's Google Analytics tag loads with every page. It records the page address and a few house events (the first use of a control, thirty seconds on the page, how fast the page loaded), each with the page's path. On these pages and in the doctor's browser mode the address never holds the domain, so the tag is never given it.
• The doctor's graded examination is the one exception, and it says so: it sends the domain to our server, which keeps the reading for ten minutes, and writes the domain into the address as ?d= so that a reading can be shared, and that address is what the analytics tag then sees.
• No email address is collected anywhere on these pages, and they send no mail.