Changelog

User-visible changes: new and improved checks, scoring changes, features and documentation updates across the domain scanner, the live email test and Record Studio. The domain scan runs 126 individual checks across six modules – every one explained on the checks & scoring page; the live email test adds deep, message-level checks (SPF/DKIM/DMARC/ARC, S/MIME, STARTTLS/DANE/MTA-STS and more), and a single email covers both directions. Dates are deployment dates.

September 27, 2026 – SPF: broken include and redirect targets are named with their reason; DMARC: a report authorization with a repeated tag does not count

SPF targets with more than one record or a syntax error, and include or redirect loops, count as broken, and the Record Studio follows redirect= chains like the scan. An include: or redirect= target that publishes more than one SPF record or one with a syntax error, or a chain that leads back to a name already on it, makes receivers return PermError (RFC 7208 §4.5, §4.6, §4.6.4) just like a target without a record; the scan now fails the row “SPF include/redirect targets valid” for it and names each target with its reason. The Record Studio reads the whole redirect= chain and its first all term, as the scan does.
An authorization record for external DMARC reports that repeats a tag no longer counts as authorization. RFC 9990 reads the record at <domain>._report._dmarc.<destination> like a DMARC policy record, and a repeated tag voids it, so RFC-conformant receivers send no reports there. The scan, the Record Studio and the live mail test now warn about it, and say when a tag repeated only in upper/lower case makes the outcome depend on the receiver.

September 25, 2026 – DMARC: invalid pct values are graded and close the BIMI gate

Invalid pct values are now graded and no longer open the BIMI gate. A DMARC record whose pct value breaks the syntax of RFC 7489 – 0050, 0100, 150 – was read as pct=100 by the live mail test, the Record Studio and the BIMI check, although receivers still on RFC 7489 read such a value differently depending on their parser and Google requires pct=100 for BIMI. The live mail test and the Record Studio now grade it as the scan already did, and none of the three counts the logo as displayable any more.

September 24, 2026 – DMARC: a repeated tag makes a record invalid, an unanswered tree-walk step gives no grade, the Record Studio names form changes

A DMARC record that repeats a tag is treated as invalid, and a tree-walk step without an answer no longer produces a grade. RFC 6376 §3.2, which RFC 9989 applies to DMARC, voids a tag list with a repeated tag, so RFC-conformant receivers skip such a record and keep walking the tree – the scan fails it at the scanned name, and the Record Studio, the live mail test and the report viewer say so. When a lookup on the way up the tree does not answer and could change which record applies, the scan and the live mail test no longer grade the record they found and the Record Studio no longer shows it as the inherited policy: each says that the policy could not be determined and names the lookup that did not answer.
The Record Studio comparison names behaviour changes you make in the form. Changing a published DMARC record in the form – p=reject to none, a stricter alignment, t=y – was reported as “Equivalent”; the comparison now lists each change and warns when it weakens the policy.

September 23, 2026 – SPF on hostnames without MX judged by the DMARC policy that covers them; norm pills on every policy finding

A hostname without MX and without SPF is only excused while an enforced DMARC policy covers it. The applicable policy is the host’s own DMARC record, else the organizational domain’s sp (or p); quarantine or reject keeps the warning at weight 1, none, no record or a policy lowered to none by t=y makes it a failure like on any other domain, and a DMARC lookup without an answer leaves a warning that says so.
Norm pills now stand on the policy findings too – name servers, DNSSEC, SPF, DKIM, DMARC, MTA-STS, TLS-RPT, certificates, redirects and HTTP headers name the obligation level of BSI, Internet.nl and NIST, and each such finding lists the cited document among its references.

September 19, 2026 – Cryptography judged on the BSI guidelines: 3000-bit keys, cipher suites with BSI, Internet.nl and NIST columns, norm pills

RSA, DSA and DH keys below 3000 bits are now a warning. BSI TR-02102-2 has asked for 3000 bits since 2023; the website certificate, the MX certificate (with a new key column), the receiving test and the DNSSEC keys follow it, so a 2048-bit key drops from pass to warn – without a rating cap. ECDSA P-256, Ed25519 and Ed448 pass unchanged.
Cipher suites are judged on BSI TR-02102-2, with Internet.nl and NIST beside it as comparison columns. One rule on the website and on the mail server: fail when all three frameworks reject a suite, warn when BSI does not recommend it or no list carries it, pass when BSI recommends it – so static RSA suites are a warning on both paths now (they used to pass on the website and fail on the mail server), while DHE and the CBC-SHA256/384 suites pass on the mail server. The “Rating” column of the suite table gives way to BSI, Internet.nl and NIST, and the cryptographic findings carry norm pills naming each framework’s obligation level.
A mail server that offers nothing newer than TLS 1.0 or 1.1 fails, and the cipher suite order on the mail server is a warning instead of a failure. No framework admits a mail server without TLS 1.2, so that case caps the module at C wherever such a host still completes a session with our client – which offers nothing below TLS 1.2 itself, so in practice such a host is reported as “no TLS session”. TLS 1.0/1.1 offered only as a fallback next to TLS 1.2 stays a warning without a cap, which is what TR-03108 permits for opportunistic delivery, and an order violation that used to fail now warns.
Wildcard certificates are named, without a grade. BSI TR-03116-4 forbids them for federal projects, the CA/Browser Forum permits them – the report says so for the website and per MX.

September 18, 2026 – Mail server TLS judged the way Internet.nl judges it: cipher classes, cipher order, DH parameters, key-exchange hash

Mail server cipher suites are now judged on the NCSC-NL classification of May 2025, the one Internet.nl uses. Static RSA, CBC with SHA-1 and CCM8 count as insufficient and fail the check; DHE, Camellia, ARIA and ECDHE with CBC-SHA256/384 are phase out and warn. The verdict comes from one connection per class instead of from the listed suites, so a server that still accepts such a suite loses points here even where the list stops at the sample limit.
New check: the cipher suite order on the mail server. A server that still accepts phase-out suites has to prefer the good and sufficient ones; where it follows the sender’s order and picks a phase-out suite instead, the check fails and names both suites. Measured the way Internet.nl measures it, for TLS 1.2 and below.
Diffie-Hellman parameters and the hash of the key exchange are graded. A finite-field DH group below 3072 bits now fails and an elliptic curve outside the recommended set is named; a key exchange signed with SHA-1 fails, SHA-224 warns, and a pass is given only where a stronger hash was actually measured. Together with the stricter cipher classes this moves grades: a mail server that accepts static RSA or signs with SHA-1 can lose a grade step.

September 16, 2026 – Anycast name servers: more operators recognised, two-provider zones named

More zones on anycast name servers are no longer graded as clustered. Akamai Edge DNS, DNS Made Easy/Constellix, Cloudflare, Bunny DNS, Oracle Cloud (with Dyn), Rage4 and UltraDNS are now recognised even where the name servers carry the customer’s own name, and a zone that combines two anycast providers names both of them. The report adds what it cannot see: whether the machine answering behind such an address belongs to the provider or to the zone owner.

September 15, 2026 – Post-quantum OpenPGP signatures verified; anycast name servers recognised by origin AS and by published address ranges; links into one section of a report

Post-quantum OpenPGP signatures are verified (RFC 9980). The security.txt check and the live email test now verify signatures made with the post-quantum schemes of RFC 9980 – the ML-DSA+EdDSA composites (a composite counts only when both of its halves hold) and SLH-DSA – checked against the standard’s own test vectors. Where a signature uses an algorithm this scanner does not verify, the report now names the algorithm as the cause instead of a missing key.
Anycast name servers are also recognised by their origin AS, and a multi-origin prefix counts every AS it is announced from. Zones on RcodeZero (nic.at) – including its customer names sec1/sec2.rcode0.* and white-label names on the same addresses – were graded “all in one AS”; the name-server distribution now reads every origin AS of a prefix, as Zonemaster CONNECTIVITY03 does, and recognises the operator by AS where the host name says nothing. RPKI now validates every origin of such a prefix (RFC 6811 grades each route), names an invalid or undetermined origin, and validates at most five per address.
More anycast providers are recognised even when their name servers carry a customer’s own name. Zones whose name servers are named after the customer instead of the provider are no longer graded “all in one AS” when those addresses belong to a recognised anycast DNS operator. Where the same network also carries servers a customer runs himself, the warning stays: from the outside the two cannot be told apart.
Where an operator publishes which of its addresses answer DNS, name servers on them are recognised even under a customer’s own name. The point above left a gap: in a network that also carries machines customers run themselves the warning stayed, because from the outside the two look alike. Where the operator publishes that list it no longer does – for AWS Route 53 it exists, so a zone whose name servers carry the customer’s own name on those addresses is reported as anycast instead of clustered, while an address the same publication assigns to another service is not.
A report link can point at one section, one topic or one single check. The address bar follows what you open (?domain=…#dns, #dns/caa, #dns/caa/caa-smime), and a link button on every section strip, topic panel and check row copies that link. Whoever opens it sees the section, the topic with its details or the single check unfolded as soon as its module has loaded – on the English and the German page alike.

September 14, 2026 – New RFCs applied: finite-field DHE deprecated in TLS 1.2, two name servers per address family, noRevAvail certificates, glue-only name servers, sharper ECH and CDS checks, header protection and algorithm binding in signed mail, post-quantum key agreement named

The website test names the TLS 1.3 key agreement and whether the server accepts the post-quantum hybrid X25519MLKEM768 (RFC 10024). A new informational line, weight 0: the negotiated group is read from the handshake where the runtime names it, otherwise identified by a re-handshake that offers exactly one group. A declined re-handshake is reported as an answer to that one connection; an absent hybrid is never claimed.
SHA-1 key-exchange signatures on the mail server (RFC 9155). The mail server test now spends one extra STARTTLS handshake on the representative MX, offering only SHA-1 signature schemes, and notes without a grade when the server still signs its TLS 1.2 key exchange with SHA-1 – the website test has measured this since August. Only an alert the server itself sent counts as a refusal; our own timeouts read as “not determined”.
Signed mail: header protection, algorithm binding, internationalized addresses (RFC 9788, RFC 8933, RFC 9598, RFC 9980). The live email test reads the header protection of an S/MIME or PGP/MIME signature (hp=clear or cipher), warns when the protected From address differs from the outer one and no certificate or key is bound to it, names the superseded RFC 8551 scheme, and reports a clean inline PGP signature as unprotected for conformant clients (RFC 9787). An S/MIME signature that digests content and attributes with two different algorithms now fails, the CMSAlgorithmProtection attribute is read and shown, internationalized certificate addresses are compared, and the post-quantum OpenPGP algorithms are named. The mail server test warns for an MX certificate whose name matches only through the commonName, which MTA-STS does not accept (RFC 8461 §4.2).
A name server reachable only through the parent’s glue is no longer failed (RFC 9471). The name-server count now reads the glue from the parent zone’s referral at no extra query: such a server warns with its own explanation and shows “only as glue in the parent zone” in the drill-down, and a truncated referral is never used for the delegation comparison.
Sharper ECH, CDS and From checks (RFC 9849, RFC 10026, RFC 6854, RFC 7504). The “+ ECH” badge needs an ECH configuration of the registered version and a mixed HTTPS record set is named; the CDS/CDNSKEY finding warns when the signalled key is not in the zone’s own DNSKEY set and tells single-type publishers that BCP 246 wants both types. The live email test reads group syntax in From, checks for the Sender header on a multi-address From, and a 521 SMTP greeting is reported as “host does not accept mail” instead of a possible greylist.
Finite-field DHE on TLS 1.2 is now graded like static RSA (RFC 10015). The forward-secrecy findings of the website test, the mail server test and the live email test warn when a TLS 1.2 connection negotiated or offers a DHE suite: the session is still forward-secret, but RFC 10015 forbids this key exchange in TLS 1.2 outright, so the only remedy there is ECDHE. No grade cap; TLS 1.3 groups are unaffected. The DH parameter finding keeps its size ladder and names ECDHE as the TLS 1.2 remedy, and the cipher suite page marks the deprecated key exchanges instead of calling them “acceptable”.
Two name servers per address family (RFC 10001, the new BCP 91). The AAAA finding passes only from two IPv6-capable name servers and warns at one; a new twin finding checks the IPv4 side the same way and fails when no name server has an A record, because an IPv6-only delegation is unreachable for most resolvers. Both read published records and cost no extra query.
Certificates that declare no revocation information (RFC 9608). A certificate carrying the noRevAvail extension passes the revocation finding with its own explanation instead of being warned at; one that combines noRevAvail with a CRL distribution point or an OCSP responder fails, as the RFC has relying parties treat it as invalid.

September 11, 2026 – One live email test for sending and receiving; a DMARC report viewer reads your aggregate reports in the browser

The sender test and the receiver test are one page now: the live email test. Send one message to a one-time address and read the sender report; tick “also test the receiving side” before generating the address and the delivery test against your MX runs on that same message, no second email. The tick is off by default, so nothing is sent to your servers unless you ask for it.
The old addresses keep working. /send-test.html and /receive-test.html redirect to the new page, the latter with the receiving-side option pre-ticked.
New page: the DMARC report viewer. Drop or paste the aggregate reports receivers send to your rua address (.xml, .xml.gz, .zip) and see every sending source with its DMARC, DKIM and SPF results, a red/orange/green light per source and per report, the receiver’s override reasons and every RFC 9990 field explained. Reports are read in your browser only; nothing is uploaded.
Four ways in. The DMARC reference opens its annotated example in the viewer, the tests hub and the DMARC generator link to it, and the scan report offers it on the rua row once a mailto: address is published.
DMARC report viewer: optional DNS check. One button determines the organizational domain of every domain in a report by the RFC 9989 tree walk and fetches the DMARC record published today, so relaxed-alignment verdicts and a record changed since the report can be judged. Only domain names are sent, nothing is stored.

September 9, 2026 – The DNS lookup takes an email address for SMIMEA; CDNSKEY, DNAME and the old SPF type join the scan

Type an email address, get its SMIMEA or OPENPGPKEY record. Both records live under a hashed owner name (<hash>._smimecert.<domain>, <hash>._openpgpkey.<domain>) that nobody types by hand. The lookup now accepts the address itself, computes the owner name in your browser and queries only that name, so the address never leaves your device; SMIMEA is the default, OPENPGPKEY is a pick in the type list, and the result shows the queried name with a copy button. The owner name still works as direct input.
One record in three spellings is no longer a “disagreement”. Some resolvers return a certificate or key record in the generic hex form (\# 1793 …), others in the usual presentation form; the comparison now decodes the generic form before it compares, so a full-certificate SMIMEA no longer reads as a propagation problem.
The DNSSEC module reads CDNSKEY next to CDS. A zone that publishes only CDNSKEY (RFC 7344 allows either type alone) no longer shows as “not published”, and when both types are published but disagree, the row warns. The drill-down adds whether the parent publishes a DSYNC notification endpoint (RFC 9859), i.e. whether it can be told about a new CDS instead of having to poll for it.
Two new rows: a DNAME at the zone apex, and a leftover SPF record type. The DNS module notes an apex DNAME (RFC 6672) with its target – legal, but it answers every name below the apex from elsewhere. The e-mail module warns about the obsolete SPF record type (99) that RFC 7208 retired: receivers ignore it, and it drifts from the TXT policy.
DNAME and SPF in the DNS lookup. Both types can be queried across the resolver matrix; DNAME is part of the overview.

September 8, 2026 – The downgrade test now works for senders at Microsoft 365 and Google

The TLS downgrade test reaches senders behind large mail providers. Microsoft 365, Google Workspace and similar platforms send every message from a different address, so their correct refusal could not be matched to your report and the test simply timed out. A refusing host now counts once its reverse name is confirmed to belong to the provider that delivered your first message, and the report says so whenever a verdict rests on that.

September 6, 2026 – One button opens the whole scan report; the live mail tests read like the report

“Expand all” next to “Refresh all”. The head of the scan report’s overview has a new button.
Overview, “what to fix first”, then one framed area per direction. The sender and receiver tests now lay their results out the way the scan report does.
The second report of a test appears below it, open. On the sender test, the optional check of your own receiving side gets its own frame underneath the sending result, so nothing above it moves when that report arrives.
A check that verified completely no longer vanishes from the check count. The three counters above a module – passed, warnings, failed – left out a fourth verdict a check can carry: “good”, given when everything about a check verified.

September 5, 2026 – The results page is regrouped: overview, triage list, and topic chips inside every module

Overview, then triage, then the three service areas. The report now opens with an overview of three service columns – Website, Email and DNS – each listing its two modules with their grade and check counts as jump links.
Topics as chips, one click to a single card. Every module block now shows its topics as chips in its header; clicking a chip opens only that topic as a card, while the arrow button next to them opens every topic at once.
Same controls on a phone, print keeps what is open. On a phone the whole report runs single column with the same controls as on a desktop; the module header there shows the one-sentence result (“TLSv1.3, certificate from …”) instead of the module’s standing question, and the topic chips and overview rows are at least 44 px tall like every other control.

September 2, 2026 – Record Studio: nothing left over from the previous domain

Typing a different domain clears the values loaded for the previous one. Earlier today the generators stopped carrying one domain’s settings into another – but only when a lookup for the new name came back without a record.
A lookup that fails is no longer treated as a lookup that found nothing. When a DNS or HTTPS query cannot be carried out, the server says so explicitly rather than reporting an absence – and the form now keeps its contents in that case, because nothing was found to replace them.

August 29–31, 2026 – Reference clients measured instead of guessed; Mozilla’s dated distrust

Every simulated client now offers what the real one offers. The compatibility check asks whether current browsers, Android, Java and OpenSSL can still negotiate with your server.
The oldest TLS version each client accepts is now checked as well. A profile says more than which cipher suites a client offers – it also fixes the oldest TLS version that client will still speak.
A client we could not reach is no longer shown as incompatible. When one of the six probes gets no answer at all, the finding has always said so – that is our network, not your server.
The scan now knows Mozilla’s second, dated form of distrust. Until now the report asked one question about the root your certificate chains to: is it still in Mozilla’s current TLS root set? That question cannot see a cut-off date. Mozilla also distrusts roots “from a date onwards”: the root stays in the set, but Firefox refuses every certificate issued after that day.
Documentation checked against its sources. Over the previous week well over a hundred sentences in the explanations were compared with their primary sources and corrected wherever they went further than the source or spoke for browsers nobody had measured.

August 28, 2026 – CSP criteria measured against internet.nl, OpenPGP subkeys that must prove their binding, invisible characters made visible

The strict internet.nl criteria reported in the CSP finding are now compared against that checker instead of paraphrasing it. A verbatim copy of internet.nl’s own code runs beside ours over the same policies.
The Record Studio now verifies external DMARC report destinations the same way the scan does. It only ever looked at mailto: addresses, so a report address given as an https URI was skipped entirely; and it stopped at “the authorisation record exists”.
Invisible control and bidi characters in a scanned value are now shown as [U+202E] instead of silently taking effect. A TXT record, certificate name or EHLO greeting can contain a right-to-left override, which reverses the reading order of the line around it without changing a single character – a record can be made to read as something it is not.
A signature made with a subkey is now verified as being made with that operator’s subkey. A published key block can carry key packets that nothing in it ties to the main key, and until now this check simply did not look.
An <img> or <script> written inside a script or a stylesheet is no longer treated as an element of the page. Browsers do not parse it – nothing is requested for it – but this scanner did, so a JavaScript bundle containing such a fragment as a string could be reported as insecure mixed content, or as a cross-origin script without Subresource Integrity, over markup that never renders.
A zone whose name servers do not resolve no longer loses four checks silently. If none of the name servers a zone publishes has an address of its own, there is nothing to send a direct query to – and three checks (authoritative answers, agreement between servers, delegation matching the parent) plus the placeholder that is supposed to stand in for them all disappeared from the report.
A CORS header that allows nobody was reported as allowing someone. Access-Control-Allow-Origin: https://*.example.com matches no origin at all, because browsers compare the header byte for byte against the requesting origin.
The sender test now names a withdrawn address certification. Two very different situations used to read the same. When your signature verifies against a published OpenPGP key, the report says where that key came from.

August 27, 2026 – Certificate lifetimes as browsers enforce them; headers and HTML read the way browsers parse them

A certificate lifetime is now judged against the limit browsers actually enforce, which is no longer 398 days. Chrome follows the CA/Browser Forum’s stepwise reduction – 200 days for certificates issued from 15 March 2026, 100 days from March 2027, 47 days from March 2029 – and shows a full-page error above it.
“No weakness found” and “we never looked” are told apart for large RSA keys. Screening an RSA key for known-broken content (ROCA, Fermat-factorable primes) costs seconds of processing on very large keys, so this scanner stops above 8192 bits.
A website grade can no longer improve because our own probes were refused. The scanner limits how many TLS probes it opens against one host at a time. When that limit bites – on a busy site, or under load here – some checks cannot run, and their points leave the calculation.
Our own limits and our own failures are told apart. A cipher enumeration that stops because this scanner reached its own cap is a different thing from one that stops because a probe failed, and only the second is reported as a gap in coverage.
A Permissions-Policy with a space around the = is now reported as ignored, because that is what browsers do with it. camera =() or camera= () makes the header invalid as a structured field, and one malformed member is enough for a browser to discard the entire header – no feature is restricted at all.
Cookie attributes are read the way a browser reads them. Only spaces and tabs surround an attribute name – a non-breaking space does not.
A Content-Security-Policy is now split exactly where a browser splits it. The parser treated every Unicode space as a separator. A policy written with a non-breaking space – script-src, then that character, then 'none' – was reported here as the strictest possible result, “no script source is allowed, all scripts are blocked”, while Chrome ran every script on the page: it discards the whole directive instead.
The delegation check now reads the zone’s side from the zone’s own name servers. It compares the name servers your registrar publishes in the parent zone against the NS records inside your zone.
Restarting the optional TLS downgrade test no longer bounces a message sent to the previous address. The test hands out a one-time address and watches for 90 seconds. If that window closes without your provider having connected – the ordinary outcome when it has not attempted delivery yet – you can simply start it again.
Where a finding caps a module’s grade, the reason shown no longer depends on the order the checks ran in. When two findings capped the same grade, the report named one of them by position – and it did so inconsistently: for some caps the first won, for others the last.

August 26, 2026 – The send test grades forward secrecy; mail servers get the website’s questions; verdicts that depended on order

Forward secrecy of your delivery is now part of the grade. The send test measured whether the connection your server made to us provides forward secrecy, printed it in the detail line and in the table – and never let it count.
Name servers that disagree now weigh as much as one that will not answer. When your name servers return different records for the same query, part of the internet gets a different answer than the rest – a mail server, a web address.
The send test no longer deducts points for its own limits. If a message carries more OpenPGP signature packets than this check verifies, the report said so correctly and then charged for it anyway.
A DMARC record without a p tag is no longer applied as if its sp tag were the policy. A record such as v=DMARC1; sp=reject looks strict, but receivers must treat a record without a valid p tag as p=none – or ignore it entirely when there is no reporting address.
Diffie-Hellman parameters are now measured on the mail path too. A mail server that uses this key exchange with a group that is too small has the same weakness as a web server with the same setting – and until now the mail module did not look at the group size at all, while the website module in the very same report did.
Every TLS probe now offers the same protocol list as the main handshake. Eight side probes – the version test, the cipher enumeration, the cipher-order test, the signature-algorithm test and the six reference-browser simulations – announced only HTTP/1.1, while the main handshake announced HTTP/2 as well.
DNSSEC: a zone lookup that fails on our side no longer reports “DNSSEC is not enabled”. Signing keys live at the zone apex, so when a host name like www.example.com is scanned the enclosing zone has to be found first.
The website check no longer blames the site when our own network is the problem. If name resolution or the route out of this scanner fails, no connection is ever attempted – that was reported as “website unreachable over HTTPS” and cost the whole module its grade.
A failed MX lookup is no longer reported as “this domain has no MX records”. If the DNS query does not complete, the Record Studio now says so and invites a retry instead of making a statement about the domain.
Mail TLS: with some mail servers, the encryption checks were silently not running at all. When upgrading a mail connection to TLS, the scanner offered a protocol name that a minority of mail servers answer in a way that makes the handshake fail.
SPF: with two records published, the grade no longer depends on which one your resolver happens to return first. Two records make the whole policy fail before any of it is evaluated – but the syntax error, the lookup count and, worst of all, an ip4:0.0.0.0/0 hole that authorises the entire internet were read from whichever record came first, so the same pair of records produced two different reports.
The mail tests can no longer get stuck showing “waiting for your email” forever. If the report failed to display, the page treated it as a network hiccup and retried the same failing step every 2.5 seconds – success was impossible, and nothing on screen ever changed.
A finding severe enough to cap a module’s grade is now named even when the grade is already lower. A cap overrules the average, but the report only mentioned it while it actually pulled the grade down – on a module that was already rated worse, the most serious entry looked like every other one.
The overall grade now says what a missing module does to it. A module that could not be graded leaves the average completely – its weight counts in neither the numerator nor the denominator – so the number covers less than the scan intends and can come out higher than a complete run would give.

August 25, 2026 – A grade says how much it covers; Record Studio, receiver test and send test: who a failure belongs to

A redirect chain longer than five hops now yields no grade for the page instead of a flattering one. An intermediate redirect that happens to carry security headers – an everyday CDN setup – could produce a top grade for a page that was never read, and lengthening the chain on purpose was enough to make inconvenient findings stop counting.
A check we could not carry out no longer makes the grade go up. Such a check leaves the calculation entirely, so it never counts against the domain – but that alone meant the less we managed to measure, the better the result: a report in which three of six checks failed to run could show a flawless 100 %.
Where a section’s grade is held down by a rating cap, the overall grade now says so. The overall figure is an average across the six sections and does not carry their caps, so a section capped at F for an expired certificate still entered it with its uncapped percentage.
DKIM key records are recognised as records, not by a text search. The old test matched anywhere in the string.
The record generators now judge SPF the way the scan does. A record containing an invalid address or an unknown mechanism was shown as “Valid” there while the scan failed it – on the same page whose generator rejected the very same value.
The one-line module summary now has three states, not two. A cross meant “absent or broken”, so an MTA-STS policy that is published and enforcing but has one minor blemish – sometimes only against a threshold of ours, not of the standard – read as a cross directly above a line saying TLS is enforced.
A record that pins your root CA is no longer called broken. There are two trust-anchor usages and the standard gives them opposite rules: with DANE-TA (2) the certificate really must travel in the server’s handshake, while with PKIX-TA (0) it may live only in the client’s trust store and clients are required to keep building the chain past it.
Your grade no longer depends on how busy this tester was. Our own handshake deadline, our own connection budget, our own limit on how much of a server’s reply we keep – each of these used to lower the grade, and one of them capped it at C with the words “real mail loss”.
A mail server that briefly says “not right now” is no longer treated as broken. A temporary refusal of the greeting used to be reported as “mail to this server is delivered in the clear” – failure, capped grade – when in fact we never got as far as asking about encryption.
Encryption is judged on the handshake, not on the advertisement. A server that offers STARTTLS and then does not establish it used to be graded as if encryption worked.
A signature is no longer called valid when it covers only part of your message. An OpenPGP signature protects what sits inside its frame – not text placed before it, not a footer a mailing list appended after it, not a second HTML version of the message beside the signed text, and not extra body parts in a PGP/MIME or S/MIME message.
An expired OpenPGP signature is no longer valid. Signatures can carry an expiry date, and that date was never read – a signature that GnuPG rejects as expired passed here as good.
Our own limits are no longer reported as faults of your message. A message with more than 300 parts was told its MIME boundary was missing or unterminated; more than 16 KB of headers before the content type made four checks disappear from the report without a word; more signatures, attributes or certificates than we process was reported as “the signature does not verify”.

August 24, 2026 – Capacity: a lookup can no longer crowd out a running check; send-test verdicts we had not earned the right to give

The record lookups and the DNS lookup page no longer draw from the last of the shared capacity. Both deliberately work without the human-verification step, because the pages they belong to carry no widget.
A lookup that hangs no longer keeps its slot until the next restart. The checks had that guarantee already; the two lookup endpoints did not.
When our own listener cut your message short, you were charged for it. If a message ends its data phase in a way our listener accepts more leniently than the standard allows, the message can be truncated at that point – and the DKIM body hash then breaks.
A DNS lookup that failed on our side no longer becomes a statement about your DNS. If the DMARC lookup did not answer, the report claimed “no DMARC record was found” and listed, name by name, that nothing was published there.
A DMARC record with t=y is now reported with the policy receivers actually apply. That tag lowers the policy by one level: with p=reject receivers quarantine, with p=quarantine they take no action, and on p=none it changes nothing.
A DKIM key in testing mode no longer scores better than no DKIM at all. The standard requires receivers to treat mail from a signer in testing mode exactly like unsigned mail, so the signature buys nothing – yet it graded a full step better than a missing signature.
A signature that leaves part of your message body unsigned is no longer simply “valid”. The l= tag limits how much of the body the signature covers; anything past that point can be replaced on the way and still pass.
A malformed CAA value no longer reads as a certificate outage. A value that does not match the syntax counts as authorising nobody – but CAA authorisations are additive, so the other properties still apply.
MX records we cannot read are no longer counted as no MX records at all – which used to produce a statement about where the domain’s mail goes, derived from records nobody could read.
A rate-limited mail server was told it offers no STARTTLS. If an exchanger turns a scan away at the greeting – common when the same domain is scanned repeatedly – we never get to ask about encryption.
The receive test: a greylisting server no longer forces the worst grade. An exchanger that answers and defers the session is not one that receives no mail; a first-attempt deferral is normal.
An MX certificate that does not validate no longer takes the whole mail section down. As soon as any probed mail server presented a certificate the scanner refuses – self-signed, expired, issued for another name, or from an unknown CA – the mail server module aborted and the section came back as an error instead of a report.
Forward secrecy on the MX is graded for every domain again. The finding was nested inside the DANE block by accident, so it only appeared for domains publishing TLSA records – while the TLS version finding pointed at it (“see the separate finding below”) for everyone.
A capped grade names the reason that actually applies. Where a mail server announces STARTTLS but no TLS session comes about, the report used to print the fulfilled condition (“STARTTLS on all reachable MX”) as the reason for the cap.

August 23, 2026 – Our own outages no longer become your grade; no MX record no longer means “receives no mail”; the downgrade test is fenced in

A DNS failure on our side used to produce an F for a flawless domain. If our lookups came back empty – because our own resolvers were unreachable, or because a zone answered every query with a server failure – the report filled in the blanks as if the domain had nothing: no name servers, no addresses, no mail servers, no CAA.
A domain without an MX record is now tested instead of dismissed. A domain that publishes an address record but no MX still receives mail – on exactly that address, and every sending server knocks on port 25 there.
The downgrade test could be pointed at a stranger’s outgoing mail server. After analysing your message you can ask us to repeat the delivery under deliberately degraded TLS, to see whether your server still sends.
Four checks had no explanation page at all. A catch-all IP range in your SPF record, an SPF syntax error, and the two checks that fetch your MTA-STS policy and your BIMI logo over IPv4 and IPv6 separately – together the heaviest and the most easily misread findings of the section – were graded without a word explaining them.
A subdomain under a hosting suffix is no longer graded against somebody else’s domain. For a name such as you.github.io, the scan treated the hosting suffix as your organizational domain: SPF dropped from a full failure to a mild warning, the default-behaviour check disappeared, DKIM stopped being graded, and the report advised you to publish records on a domain you do not own.
A broken SPF record no longer earns credit for the parts nobody reads. One syntax error anywhere makes the whole record a PermError, and receivers then evaluate none of it.
A deliberate BIMI opt-out is no longer marked down. A record that states “this domain publishes no logo” was penalised for not enforcing DMARC – advice about something it never asked for.
MTA-STS policies are read as strictly as a sending mail server reads them. The standard spells the field names and the version/mode values in exact case; a policy writing Mode: ENFORCE is not valid for a strict sender.
CAA records are now looked up the way a certificate authority looks them up. A CAA policy applies to every name below it, and a CA walks up the name tree until it finds one.
A rate-limited greeting is no longer reported as “cleartext only”. When a large mail platform answers a repeat visitor with a temporary refusal before the conversation starts, nothing about its encryption has been measured.
A two-second DNS hiccup on our side is no longer frozen for an hour. Results are cached for an hour so we do not probe your domain repeatedly. When a module reports that the measurement failed on OUR side, that answer is now kept for a minute instead – long enough to absorb a burst, short enough that a brief outage does not follow you around.
Three checks had no explanation page at all. Whether your name servers answer authoritatively, whether they agree with one another, and whether your registrar’s delegation matches your zone – three checks that can fail and together carry five of the section’s rating points – were graded without a single word explaining them.

August 22, 2026 – Website and header verdicts match what browsers do; the scan no longer overwhelms the site; DNS panels claim only what they measured

The web check now opens at most eight connections at a time. Protocol probes, cipher enumeration, six simulated browsers, the port-80 request and the HTTP/3 probe all started at once – measured, that was up to nineteen simultaneous connections to a single host.
Forward secrecy is judged over every suite the server offers, not just the one we negotiated. Our connection almost always gets the best available suite, so the check said “TLS 1.3 – always forward secret” and moved on. Two of five sites measured while building this release additionally offer suites without forward secrecy: a client that supports only those gets a connection whose recorded traffic can be decrypted later if the server key ever leaks.
A weak frame-ancestors can no longer be rescued by X-Frame-Options. Browsers ignore X-Frame-Options entirely as soon as an enforced CSP carries frame-ancestors – a DENY included.
An X-Frame-Options value browsers do not act on is now a failure, not a warning. ALLOW-FROM, a typo, or ALLOWALL all mean “embedding allowed from anywhere” – exactly the same exposure as sending no header at all, which the report already graded as a failure.
The HSTS preload verdict no longer mixes up two hosts. The preload list was queried for the domain you entered, while the HSTS header was read from wherever the redirects ended – for the very common redirect from the bare domain to www those are two different hosts.
An HSTS header delivered over plain HTTP is no longer credited. If the request ends on http://, browsers ignore the header entirely (RFC 6797) – it was previously graded as if it worked.
The root store is counted correctly – 146 authorities, not 267. The certificate report named a number that counted the same root twice whenever it arrived from two sources with different line breaks, while the trust-store page had always counted certificates.
A root that Mozilla has removed is no longer silently accepted. Our store combines the operating system, the Node bundle and the weekly Mozilla/CCADB snapshot – but it only ever added, never removed.
A timed-out protocol probe no longer reads as “correctly disabled”. Each TLS version was tested with its own connection, and every failure – including our own timeouts – was recorded as “the server does not offer this”.
The first day after a DNSSEC signature expires was graded as “about to expire”. The remaining time was rounded to whole days, and a signature that ran out less than 24 hours ago produced negative zero – which is not less than zero in JavaScript.
A failed lookup on our side no longer reads as “the chain of trust is incomplete”. The DNSSEC check makes four DNS queries in parallel, and three of them already distinguished “we got no answer” from “the zone has a problem”.
An address lookup that fails is now reported as our failure, not as “no addresses”. When every resolver we ask is unreachable or returns an error, the result is an empty list – and that used to be indistinguishable from a name that genuinely has no addresses.
Name servers that decline to answer are named instead of counted as healthy. A server replying REFUSED or SERVFAIL never had its authority assessed – and the report was crediting it anyway, in a sentence that read “all answering name servers authoritative”.
A filter that answers with an address is now recognised as a filter. The blocklist panel knew four ways a resolver says no – NXDOMAIN, REFUSED, a null address, or no address at all. It did not know the fifth: handing back an address of the operator’s own that serves a notice page.
“A few connections per scan” understated it by an order of magnitude. A full scan opens a few dozen short-lived connections, because every cipher suite has to be probed individually; what keeps that civil is the throttle that allows only a handful at a time.
Every explanation page was read against the check it describes. All explanations of the website, HTTP-header and DNSSEC groups were compared with their checks sentence by sentence; where a page promised a verdict the scan does not give, or cited a source that says something else, the page was corrected. The English and German explanations are now compared automatically.

August 21, 2026 – New: a complete DMARC reference; the DMARC generator shows what republishing changes; scanner and Record Studio agree

New page: DMARC explained. Until now DMARC was one paragraph on the email-authentication page.
The tree walk, actually calculated. Every explanation online names it; this one runs it, query by query, on a seven-label name, and then repeats the same message with a psd=n record one level down to show how the answer changes.
A troubleshooting tree. Four symptoms — legitimate mail being rejected, no reports arriving, the record not being found, only subdomain mail failing — each branching to a cause, a check you can actually run, and the fix.
Load your published DMARC record and see what a receiver on the current standard does differently with it. The DMARC generator now shows your published record next to the one it would produce, and lists every difference in one of three groups: what actually changes behaviour, what this simple form would drop if you republish, and what is merely cosmetic.
Scoring change for pct= in the domain scan. It is now judged by how much it really changes. On a p=none record it costs nothing at all any more — there is nothing to sample and both standards produce the same outcome.
We no longer tell you to publish pct=100. The BIMI advice in the report, in the documentation and in Record Studio asked for a tag that the same report calls obsolete two rows further down.
“Full spoofing protection” is gone. p=reject is the strongest signal a domain owner can send, but RFC 9989 explicitly forbids receivers to reject on that basis alone, and forged display names on a foreign sender domain are outside what DMARC covers at all.
Saying plainly why a reduced pct costs you your BIMI logo. The rule has not changed; the explanation was wrong. A DMARC record with pct below 100 still counts as not BIMI-eligible here.
The logo and certificate check no longer waits for a perfect record. It used to run only once the BIMI record was already complete – logo, mark certificate and an enforced DMARC policy – which is precisely when you least need it.
A single request cannot tell you whether both address families work. The operating system picks one, so a host that is broken over exactly one family answers normally and the check reports success – it masks the very defect it exists to find.
DMARC discovery follows the tree instead of guessing. Looking up a subdomain, Record Studio tried the exact name and then made a single attempt at the registrable domain, skipping every label in between – so a policy published on an intermediate name was reported as “no DMARC record”, and the same blind spot decided whether BIMI counted DMARC as enforced.
ip4:0.0.0.0/0 is +all written differently, and is now graded as such. A /0 range matches every address, so a closing -all can never be reached: mechanisms are evaluated left to right and the first match wins.
A revoked DKIM key no longer counts as a key. Publishing an empty p= revokes a selector (RFC 6376 §3.6.1) – it verifies nothing.
An MTA-STS policy with no mx line is no longer a pass. RFC 8461 §3.2 requires at least one, and the comparison against your real MX hosts was skipped when the list was empty – so a mode: enforce policy that matches none of your servers was rated as correct.
A resolver failure is no longer reported as “no record”. When a lookup came back SERVFAIL – typically a DNSSEC-broken zone – Record Studio said the record did not exist.

August 20, 2026 – Three new name-server checks; the DNS lookup asks the authoritative servers; a TLS downgrade test for your outbound mail; new SMTP checks

Three new name-server checks. Lame delegation, name servers that disagree with each other, and a registry that no longer points at the right servers – questions no public resolver can answer, so the scan now talks to your name servers directly.
DNS lookup: the authoritative servers, side by side with the resolvers. The lookup now also asks the name servers the delegation actually points at and shows each one’s answer and zone serial in a panel of its own, so servers that have drifted apart become visible.
New, optional: we play a mail server whose encryption is broken. After your report is ready you can start a second, deliberately degraded delivery — either with no STARTTLS offered at all, or with a certificate that matches neither our host name nor our published DANE records.
This can change your grade. Delivering under degraded conditions is reported as a warning, not a failure: opportunistic TLS without MTA-STS or DANE is standard behaviour for most mail servers, and Postfix needs extra configuration for either.
Receiver test: four new SMTP checks. Role mailboxes (RFC 2142), what your server answers to VRFY, modern SMTP extensions graded instead of just listed, and the SMTP greeting.
The report now shows whether your server offers a TLS client certificate. During the STARTTLS handshake our listener asks for one; almost no public mail server presents one, which is perfectly normal and reported as such.
The send test now discovers your DMARC policy the way DMARCbis (RFC 9989) specifies. Instead of falling back to the Public Suffix List, it walks up the DNS tree from your From domain, honours psd=, and applies the tag that actually governs the message – sp= for a subdomain, np= for a non-existent one, p= otherwise.
The SPF result now opens into a step-by-step trace. Every term of your record in evaluation order – including the terms of records pulled in via include: or redirect=, indented one level – with what matched, what did not, and how much of the 10-lookup budget was used at each step.
New: authentication results reported by systems on the delivery path. If your mail passed through a relay or mailing list that added an Authentication-Results header, the report now shows what those systems claimed about SPF, DKIM and DMARC.

August 18–19, 2026 – New: DNS lookup across 11 public resolvers; “not applicable” is not a scan failure; mail-only domains no longer get an F for having no website

New DNS lookup: compare 11 public resolvers side by side. Query any record type and see per-resolver answers with TTL, DNSSEC validation status and response time, an automatic consistency verdict that recognises CDN rotation, and a blocklist panel showing whether filtering resolvers (Quad9, DNS4EU, AdGuard, Cloudflare Security) block the domain.
Modules with deliberately nothing to test no longer look like scan failures. When a domain has no website configured (a mail-only domain) or no mail servers (a web-only domain), the affected modules now show a neutral grey “n/a” in the overview bars and the compact sticky bar – instead of the error-style “!” that previously suggested something went wrong.
A domain without any website is no longer treated as a broken website. When neither the domain itself nor www has A/AAAA records, the Website module now reports “no website configured” and stays ungraded – just like the HTTP security headers module – instead of failing with an F. Running a domain purely for e-mail is a normal setup, not a security problem.
The Null MX generator in Record Studio now also emits the wildcard DKIM revoke record (*._domainkey → v=DKIM1; p=), completing the recommended record set for domains that use no mail.

July 28, 2026 – OpenPGP checks in the sender test; security.txt signatures verified

The sender test now verifies OpenPGP signatures the same way it already verified S/MIME. Both message forms are covered: PGP/MIME (RFC 3156) and the older inline style.
New: is your key findable at all? The test looks up the sender address in the Web Key Directory of its own domain and, failing that, on keys.openpgp.org.
Autocrypt headers are validated against the Level 1 specification – including the rules that decide whether a receiving mail client accepts the header at all: the announced address must match the sender, unknown attributes without an underscore prefix invalidate the header, and two valid headers in one message make clients discard both.
The domain scan additionally checks whether the contact address in a security.txt is discoverable via Web Key Directory.
The scanner now verifies the OpenPGP cleartext signature of a signed security.txt against the key the file itself publishes. The key block referenced in the Encryption field is fetched and assessed (usable public key, RSA key size, ROCA/Fermat factorability, no exposed private-key block), and the signature is verified against exactly that key per RFC 9580 – supporting RSA, ECDSA (NIST and Brainpool curves), EdDSA/Ed25519 and Ed448, v4 and v6 signatures.

July 20, 2026 – Full IPv6 coverage for address-based checks; more precise MTA-STS diagnostics

Mail servers are now probed over both address families. Every MX host gets one STARTTLS/TLS connection per published family (IPv4 and IPv6), each with its own protocol, certificate and DANE verdict – per-family divergence (e.g. a broken certificate served only over IPv6) is now visible instead of hidden behind a single connection.
RPKI now validates IPv4 and IPv6. Route-origin validation previously covered only the primary IPv4 address – IPv6-only domains got no RPKI result at all, and the IPv6 prefix of dual-stack domains was never checked.
Mail server reverse DNS (FCrDNS) now covers both IP families. The check previously sampled up to four addresses in IPv4-first order, so mail servers with four or more IPv4 addresses (common at large providers) never had their IPv6 addresses checked or shown.
Zone transfer (AXFR) is now probed over IPv4 and IPv6. Access control for zone transfers is set per listener, so a name server can refuse over one address family while leaving the other open.
The MTA-STS, security.txt and BIMI generators now fetch over both address families when you load the current record. Each resource (the MTA-STS policy, the security.txt file, the BIMI logo) is retrieved over IPv4 and over IPv6 separately, so a broken or divergent endpoint on one family – which the browser’s connection race would otherwise hide – is caught.
Clear reasons for unreachable policies. When the MTA-STS policy file cannot be fetched, the finding now names the actual cause: a policy host that resolves only to private/internal IP addresses (unreachable from the public internet), missing address records (A/AAAA), an HTTP status other than 200, or a forbidden redirect (RFC 8461 §3.3) – instead of the previous generic note.
New warning: policy host reachable over IPv6 only. If the policy file is served from a host without a public IPv4 address, IPv4-only senders cannot fetch it and – without a previously cached policy – deliver without MTA-STS protection; the check now points this out (dual-stack senders are unaffected).

July 18, 2026 – New visual design

Redesigned interface. The whole site – scanner, live mail tests, Record Studio and documentation – moves to a new, document-like design: white and ink surfaces with a single cobalt accent, sharp corners, hairline rules instead of shadows, and the Inter and IBM Plex Mono typefaces.
New grade presentation. The overall grade and every section grade now appear as an outlined grade square with a status stripe instead of the previous ring; the section bars became slim bars in each section’s grade colour.
New logo. A cobalt square with a check mark replaces the shield – including favicon, home-screen icon and link-preview image.
Printable report. The scan report now prints properly: navigation and forms are hidden, and all findings appear – even in collapsed sections – with their pass/warning/failure marks.

July 15, 2026 – Clearer reports: triage list, service groups, per-group grades in the mail tests

“What to fix first” triage list. The scan overview now includes a cross-section list of everything that failed or warned, worst first – failures before warnings, grade-capping findings before the rest.
Service groups in the overview. The six category bars are now grouped under the three services they protect – Website, Email and DNS – and the section cards follow the same order (Website / HTTPS-TLS, HTTP security headers, email authentication, mail server TLS & DANE, DNS, DNSSEC).
Plain-language subtitles. Every section now carries the question it answers as a one-line subtitle (“Can someone forge email in your domain’s name?”), so you know what a section is about before reading a single finding.
Grouped findings. Both live mail tests now organise their results under flat topic headings with a plain-language question each: the sender test under SPF, DKIM, domain policy & alignment, transport security, sending infrastructure, message format, S/MIME and SMTP diagnostics; the receiver test under mail servers & reachability, transport encryption, encryption policies (DANE · MTA-STS · TLS-RPT), acceptance & delivery and SMTP diagnostics.
“What to fix first”. Like the domain scan, both test reports now start with a triage list of everything that failed or warned, worst first, each row jumping straight to the finding.
Per-group grades & scan-style overview. Every topic group now carries its own grade (computed with the same formula and grade caps as the overall score), and both test reports — including the embedded bonus sections — open with the domain scan’s overview: the grade ring with the percentage next to per-group bars that jump straight to their group.

July 12–13, 2026 – New: email receiver test; the sender test looks much deeper

A new email receiver test checks how your domain receives mail. After you prove control of the domain — by sending one authenticated message from it — the test connects to your mail servers like a real sender and reports what happens on the wire: is a mail exchanger reachable, does it offer STARTTLS, is the recipient accepted at RCPT, does it accept any address (catch-all), does it accept postmaster@ (required by RFC 5321), is greylisting active, and is a foreign recipient relayed (open-relay hint)?
An optional end-to-end delivery check. When your mail server accepts the recipient, the test can deliver one real, harmless, clearly-labelled message and confirm it is accepted after the DATA stage — so you also learn whether a content or size filter would reject legitimate mail.
Sender test — optional receiving-side test. When your sent message proves you control its domain (a strictly aligned SPF or DKIM pass), the sender-test result now offers a one-click button to also test how your mail servers RECEIVE mail — STARTTLS, DANE, MTA-STS, certificate trust and more — reusing that same proof, with no second email to send.
Receiver test — bonus sender analysis. The receiver test already asks you to send one authenticated message to prove you control your domain. That very message is now also run through the full sender test, so a single email gives you both pictures at once: the transport security of your mail servers (the receiving side) and a complete outbound analysis of the message you sent — SPF, DKIM, DMARC, ARC, TLS, MIME structure, S/MIME and more.
Sender test — S/MIME signature. If your test message is S/MIME-signed, we now verify the signature the way a recipient's mail client does: we cryptographically check that the content is unaltered, that the signing certificate's address matches your From address (RFC 8550), that it chains to a publicly-trusted email root (the Mozilla/CCADB "Email" trust list), and that it uses modern algorithms and a strong key.
Sender test — SMIMEA record (RFC 8162). When you publish an SMIMEA DNS record for your address, we compare it against the certificate that actually signed the message and confirm the DNS zone is DNSSEC-signed, so recipients performing DANE-style certificate discovery obtain the correct certificate.
Receiver test — publicly-trusted certificate. We now check whether each of your mail servers' STARTTLS certificates chains to a publicly-trusted root CA, verified against the same combined root store as the main scan (with intermediate chain repair, so a server that merely omits intermediate certificates is not falsely flagged).
Sender test — delivery path. We now parse the Received-header trace of your test message and report the path it took to reach us — how many relay hops it passed through and how long it spent in transit — flagging an unusually long chain or a large delay that can point to queuing or a misconfigured outbound path.
Sender test — Authenticated Received Chain (ARC, RFC 8617). When your test message carries an ARC chain (added by a forwarder such as a mailing list), we now verify it the way a receiver would: we independently re-check every ARC-Seal and the most recent ARC-Message-Signature and report whether the chain is intact.
Sender test — message structure. We now parse the MIME structure of your test message and flag issues that hurt rendering or deliverability: an HTML-only body with no plain-text alternative, a declared multipart boundary that is missing or never closed, an unknown Content-Transfer-Encoding, and executable or script attachments that most mail gateways block.
Receiver test — MTA-STS enforcement simulation. We now fetch your MTA-STS policy and, uniquely, cross-check it against the mail servers we actually connected to and the certificates they presented: under mode: enforce, a mail server that isn’t covered by an mx: pattern, doesn’t offer STARTTLS, or serves a name-mismatched certificate is flagged as real mail loss (a policy-honouring sender would refuse it).
Sender test — one-click unsubscribe (RFC 8058). For bulk mail we now check the full Gmail/Yahoo one-click flow: a List-Unsubscribe with an HTTPS URI, a List-Unsubscribe-Post one-click marker, and an aligned DKIM signature covering both headers.
DNSSEC-signed authentication records. The sender test now shows whether your SPF, DKIM and DMARC records are DNSSEC-signed — unsigned records can be spoofed toward resolvers that do not validate DNSSEC, weakening the protection they provide.
SPF record hygiene. Beyond the pass/fail result, the sender test now lints your SPF record for common mistakes: a “+all” that authorises the whole Internet, an overly broad CIDR, mechanisms placed after “all” (which are never evaluated), and a redirect= alongside an “all” mechanism (which makes the redirect ineffective).
Weak/compromised DKIM key detection. The sender test now screens your DKIM public key for known-weak RSA material (the ROCA vulnerability and Fermat-factorable keys), where the private key can be recovered and your signatures forged — the same screen we run on mail-server certificates.
Receiver test — certificate-chain drilldown. The report now shows the full certificate chain each mail server serves (subject, key type/size, signature algorithm, role), flags a weak SHA-1/MD5 signature anywhere in the chain, and surfaces OCSP must-staple and Certificate-Transparency (SCT) presence.
Receiver test — DANE (DNSSEC-pinned TLS). We now fetch your mail servers’ TLSA records and verify them cryptographically against the exact certificate each server presents.
DMARC scoring correction. A DMARC policy with pct<100 (e.g. p=reject; pct=0) is now correctly shown as only partial enforcement — previously it was graded as if fully enforcing.

July 11, 2026 – Record Studio: safer keys and honest “load” warnings; send test: insecure DKIM signatures are no longer valid

The DKIM generator will no longer publish a private key. If a private key is pasted as plain Base64 (without the -----BEGIN … PRIVATE KEY----- lines), the DKIM generator now recognises and rejects it instead of turning it into a DNS record.
“Load current record” no longer changes your policy silently. When a published record contains something the simple form can’t show, loading it now warns you before you re-export — a negative SPF mechanism (e.g. -ip4:), DMARC pct=/fo=/psd=, CAA account/validation parameters, unknown CAA tags such as issuevmc, a critical-flag on a custom CA, a BIMI lps= tag, or extra security.txt fields — instead of quietly dropping or inverting them.
More accurate validity checks on load. SPF is now judged by its first all (as receivers do), so +all -all is correctly flagged; an http:// BIMI logo or an invalid TLS-RPT destination is no longer called “valid”; and the TLSA check understands full trust-anchor records and the generic DNS format some resolvers return, so a correct record is no longer mis-read.
Insecure DKIM signatures are no longer shown as valid. The mail send-test now treats a signature that uses SHA-1 (rsa-sha1) or a weak sub-1024-bit RSA key as failing — matching how modern receivers treat it — instead of a green “valid”.

July 8, 2026 – Weak-key screening, SHA-1 across the whole chain, CAA contact and ACME binding, smoother on phones

Screening for compromised RSA keys. The key-strength check now inspects RSA certificates for known-compromised keys: the ROCA fingerprint (CVE-2017-15361) and close-prime / Fermat-factorable moduli.
SHA-1 across the whole chain, not just the leaf. The signature-algorithm check now also inspects the served intermediate CA certificates.
Certificate lifetime: failure vs. warning. A certificate issued for more than 398 days is now reported as a failure — browsers reject it since 2020, so the site is broken in Chrome, Safari and Firefox.
Certificates without a Subject Alternative Name. A certificate that matches your hostname only via the deprecated commonName (no SAN) is now flagged as a warning — modern browsers ignore the CN and reject certificates without a SAN.
CAA contact properties in the generator and the check. The CAA generator can now publish a domain contact — contactemail and contactphone — which a certificate authority may use for domain-contact validation (CA/Browser Forum BR §3.2.2.4.13/.17); a contact can be generated on its own without an issue rule.
The CAA generator can now add the RFC 8657 parameters. A new optional "ACME binding" section lets you pin issuance to a specific ACME account (accounturi) and/or to chosen validation methods (validationmethods: dns-01, http-01, tls-alpn-01).
No more sideways scrolling on phones. Long example records (BIMI, TLSA and the like) on the individual test pages no longer stretch the page past the edge of a phone screen — each code block now scrolls inside its own box, and a site-wide guard keeps any stray wide element from shifting the layout.

July 7, 2026 – New: email sender test; deep BIMI validation with verified mark certificates; new scanner IPv6 address

Send one email, see how your outbound mail really authenticates. The new email sender test (MailFrom) generates a one-time address; send a message to it from the system you want to check and get a live report on the actual message — not just its DNS records.
It cryptographically verifies every DKIM signature (RSA and Ed25519, including the l= body-length loophole and missing oversigning), evaluates SPF against the real connecting IP, and decides DMARC alignment for that message using the real Public Suffix List — the same decision a receiver like Gmail makes.
The test address is single-use and expires (5 minutes), the message is analysed and then discarded, and the report is available in English and German.
The full BIMI bar everywhere. The deep BIMI checks introduced in Record Studio now also run in the domain check and the email sender test: the SVG logo is fetched and validated (Tiny PS profile, no active content), the mark certificate is verified — BIMI marking, validity, chain to a BIMI-authorized CA (DigiCert, GlobalSign, SSL.com) — and the served logo must match the image bound into the certificate (RFC 3709).
The mark certificate is checked against the CAs that actually issue it. When the BIMI generator previews your logo, it now verifies that the VMC's certificate chain cryptographically terminates at a pinned root of a BIMI-authorized Certificate Authority — currently DigiCert, GlobalSign and SSL.com (per the BIMI Group registry).
A BIMI logo without a VMC/CMC no longer counts as a clean pass. A record that publishes a logo (l=) over enforced DMARC but has no mark certificate (a=) is now rated as a warning across the domain check, Record Studio and the email sender test — because Gmail and Apple Mail, the majority of inboxes, only display a BIMI logo with a VMC or CMC (Yahoo-style providers still show it without).
See the actual logo, not just the record. Load a record in the BIMI generator: when it passes every check — exactly one BIMI record, enforced DMARC, an SVG Tiny PS logo with no active content, and a currently-valid mark certificate (VMC) — your live logo is fetched and shown automatically, exactly as it would appear in the inbox.
The scanner's IPv6 address changed from 2a0a:4cc0:c2:23fb:9839:e2ff:fe98:1fd1 to the simpler 2a0a:4cc0:c2:23fb::1; the IPv4 address (159.195.68.98) is unchanged.

July 5–6, 2026 – “Record generators” becomes Record Studio; CAA generator rebuilt per certificate authority; accuracy pass

The record tools have grown well beyond plain generation — they load the record you already publish, validate it with a colour-graded verdict and show the certificate behind it — so the section has been renamed Record Studio.
The CAA record generator is now a grid: each certificate authority has separate issue, issuewild and issuemail checkboxes, so you can click together exactly which issuance types each CA may perform.
The CAA generator can now emit issuemail records (RFC 9495) to control which CAs may issue S/MIME (email) certificates for your domain — a dedicated field for the allowed S/MIME CAs and an option to forbid S/MIME entirely (0 issuemail ";").
The built-in CA list grew from 13 to 46 currently publicly-trusted certificate authorities (TLS and/or S/MIME), including many regional and government CAs.
The SPF generator has a new checklist of pure-sending services — SendGrid, Mailchimp, Mandrill, Mailgun, Amazon SES, Postmark, SparkPost, Brevo, Mailjet, Salesforce Marketing Cloud / Pardot, Marketo, SMTP2GO, MailerLite, Campaign Monitor, Elastic Email and more (25 in total).
The mail-provider detection in the report now recognises 15 email sending services — Inxmail, Emarsys, Optimizely / Optivo Campaign, Mapp, artegic ELAINE, Sarbacane, Selligent, Mailingwork, SendGrid, Mailgun, SparkPost, Mailjet, Postmark, Brevo and Mailchimp Transactional (Mandrill).
DNSSEC grading is more robust. A healthy signed zone is no longer mis-graded F when a scan falls back to the secondary DNS resolver or hits a transient lookup failure, and the explanations for weak key algorithms now cite the correct standard (RSA/SHA-1 vs. MD5/DSA).
DANE / TLSA verdicts are more accurate. TLSA records with unusable parameters no longer trigger a false failure; the website DANE check now matches against the certificate chain the server actually sends (so a record pinning a not-sent root is judged correctly); and the mail-server wording for the uncommon usage 0/1 records matches RFC 7672.

July 4, 2026 – Build a TLSA record from your live certificate; new SMIMEA generator; your mail provider in the scan report

The TLSA generator can now fetch the certificate straight from your server: enter your host and port and we open a TLS connection (SMTP STARTTLS on port 25/587, direct TLS on 443/465/993/995, DNS over TLS on 853, implicit FTPS on 990), read the presented certificate chain, and build the ready 3 1 1 record for you.
A new generator builds SMIMEA records (RFC 8162) — the S/MIME counterpart of TLSA/DANE, binding an S/MIME certificate to an email address in DNSSEC-signed DNS.
The record generators page is now a hub that links to a dedicated page for each generator (SPF, DKIM, DMARC, BIMI, TLSA/DANE, MTA-STS, TLS-RPT, CAA, security.txt and Null MX).
The colour-coded validity check (green/amber/red) with parsed details, already in the TLSA and SMIMEA generators, now also runs when you load the current record in the SPF, DKIM, DMARC, BIMI, TLS-RPT, CAA, MTA-STS and security.txt generators.
The SPF generator can now detect your mail provider: enter your domain, click Suggest include from mail provider, and we read your MX records, recognise the provider behind them and add the correct include: — covering more than 70 providers and email security gateways (Google Workspace, Microsoft 365, Zoho, Proton, Fastmail, GMX, IONOS, mailbox.org and many more, including region-specific includes).
The email section of the report now names the mail provider detected from your MX records — Google Workspace, Microsoft 365, Zoho, Proton, mailbox.org and 70+ others, including region-specific variants.
Where the report flags a DNS record that needs creating or fixing — SPF, DKIM, DMARC, DANE/TLSA, MTA-STS, CAA, BIMI, TLS-RPT, security.txt or a Null MX record — the finding now links straight to the matching record generator, scrolled to the right form.
The SPF generator now defaults to ~all (softfail) instead of -all, matching the scanner's own recommendation.
Zones signed with a SHA-1 signature algorithm (RSASHA1, RSASHA1-NSEC3-SHA1) now fail the key-algorithm check – RFC 9905 forbids SHA-1 for DNSSEC signing.
Temporary DNS lookup failures are no longer misreported as “bogus” or “not signed” – the check now reports that the status could not be determined and asks you to retry, consistently across all DNSSEC findings.
For SMTP, RFC 7672 §3.1.3 says PKIX-TA (usage 0) and PKIX-EE (usage 1) records must be treated as if they did not exist. The mail DANE check now honours that: an MX whose only TLSA records are PKIX (0/1) no longer counts as a valid DANE match, nor is it failed – it is reported as “DANE not in effect” (no grade cap), and the existing DANE-configuration warning points you to usage 2/3.
A domain may publish only one SPF, one DMARC and one TLS-RPT record – more than one is invalid (SPF fails with a PermError, a duplicate DMARC record makes the policy be ignored entirely, and a duplicate TLS-RPT record invalidates the set).

July 3, 2026 – Complete German version; DNS record generators; DMARCbis and security.txt

The entire site is now fully bilingual (English/German), including the live scan report with all findings, recommendations and drill-down details.
Published the complete German documentation corpus: every check explanation plus the scoring methodology.
DMARC checking deeply aligned with DMARCbis (RFC 9989–9991): full DNS tree walk, organizational-domain selection, record salvage rules, test-mode semantics (t=y) and a new DMARC syntax finding.
security.txt check upgraded to full RFC 9116 validation: syntax, Contact and Canonical URIs, expiry rules and PGP signature framing.
New record generators page with 10 generators: SPF, DKIM, DMARC, BIMI, TLSA, MTA-STS, TLS-RPT, CAA, security.txt and a record set for non-sending domains.
Everything runs locally in the browser – DKIM key generation uses WebCrypto, nothing is transmitted.
Every generator now has a "Load current record" button: enter your domain and the record currently published in DNS is read and loaded into the form, so you can edit an existing record instead of starting from scratch.

July 2, 2026 – Tool comparison, German landing pages, DMARCbis references

Added the tool comparison page: coverage compared with SSL Labs, securityheaders.com, internet.nl, Hardenize and MxToolbox.
Added German landing pages: a German start page with the scan form plus topic pages on DANE for mail servers, SPF/DKIM/DMARC, DNSSEC and HTTP security headers.
Updated all DMARC references to the new RFC 9989–9991 family (DMARCbis, obsoletes RFC 7489).

June 14–15, 2026 – DNS deep checks & fewer false positives

Added Zonemaster-inspired DNS checks: an open zone transfer (AXFR) probe on every name server, name server IP routability and reverse-DNS validation, and name server diversity measured at the autonomous-system level.
The name server distribution check now recognizes major anycast DNS providers (Cloudflare, AWS Route 53, Google Cloud DNS and more) and no longer raises false single-point-of-failure warnings; a drill-down lists every name server's addresses and network.
The HSTS preload check additionally queries the official hstspreload.org list and flags domains that are preloaded but no longer send a compliant header.
Recalibrated DNS grading: SOA replication timers are informational, missing IPv6 weighs less, and a missing CAA record or RPKI ROA is a hint instead of a warning.
HTTP/3 support is now verified with real end-to-end QUIC probes instead of relying on the Alt-Svc header alone.
Expanded anycast DNS provider recognition to more than 35 providers – each verified against real name server data – to prevent false single-point-of-failure warnings.
DKIM detection now probes 91 curated provider selectors, up from 30.

June 13, 2026 – Mail server deep-dive & backend profiling

Extended mail server checks: forward-confirmed reverse DNS for every MX address, downgrade probes for legacy TLS 1.0/1.1, and certificate chain trust evaluation (trusted, self-signed, DANE-EE pinned).
Mail cipher suites are now enumerated per TLS version on the primary MX; up to five MX hosts are tested and compared for identical configuration.
Added two transparency pages showing the scanner's live root CA trust store and its full cipher suite catalog.
Scan results are cached for up to one hour, with per-module refresh buttons, a refresh-all action and a cooldown countdown; the privacy policy documents the in-memory cache.

June 12, 2026 – RFC audit, QUIC probe & redesign

Audited every check against the current RFCs and added seven new checks: MX target validation, SOA timers, DNSKEY key strength, CDS/CDNSKEY, missing SPF include targets, DMARC test mode and cookie prefixes (__Host-/__Secure-).
First DMARCbis alignment (RFC 9989): test-mode warning (t=y), combined subdomain policy evaluation (sp=/np=) and an updated tag reference.
Added a genuine QUIC version-negotiation probe (RFC 8999/9000) to verify HTTP/3 directly; a unified HTTP versions finding covers HTTP/1.1, HTTP/2 and HTTP/3 in one place.
The certificate lifetime check follows the CA/Browser Forum schedule, with the allowed maximum shrinking from 398 to 200, 100 and eventually 47 days.
Refined DANE handling per RFC 7672: name and expiry mismatches are ignored for verified DANE-EE pins, and partial TLSA coverage across MX hosts is reported.
Scans first verify that a domain exists and show a clear message for non-existent domains; email checks for www hostnames evaluate the parent domain, with a transparent note in the report.
Complete visual redesign with a new display typeface, ultramarine accent color and refreshed light and dark themes; related findings were consolidated into fewer, clearer rows, and module cards keep a constant height while scanning.

June 11, 2026 – Accuracy review & report UX

Full review of all scan modules with around 70 accuracy fixes: DNSSEC now distinguishes broken (bogus) zones and stale DS records from unsigned ones, multiple CSP headers are merged correctly, SPF/DKIM/DMARC parsing was hardened, DANE is validated strictly per RFC 7671, and resolver outages no longer count as findings.
New checks: HTTP/2 support, CNAME at the zone apex (RFC 2181), HTTPS-to-HTTP redirect downgrades and Null MX.
Scans of hostnames such as www are graded fairly: zone-level checks evaluate the enclosing zone, CAA records are looked up the DNS tree (RFC 8659), and domains that send no mail are not penalized for missing DKIM keys or DMARC report addresses.
Added expandable drill-down details per finding: certificate chains, cipher lists, TLSA records, DNSKEY/DS tables, explained SPF terms and DMARC tags, raw response headers.
Added abuse protection via Cloudflare Turnstile in front of the scan API.
This site itself now scores 100% on internet.nl with a strict Content-Security-Policy without unsafe-inline – and the same strict-CSP criteria were added to the scanner as a check.

June 2026 – Initial release

Launched with six modules – web TLS, mail STARTTLS & DANE, DNS, DNSSEC, email authentication and HTTP security headers – graded A+ to F with explanations and remediation tips for every finding.
SSL Labs-style rating caps: a single severe issue (expired certificate, untrusted chain, …) caps the module grade; special grades T (untrusted) and M (hostname mismatch).
Cipher suite enumeration with weak-cipher detection, server cipher-preference detection and handshake simulation for reference clients.
Certificate checks for SHA-1/MD5 signatures, Certificate Transparency (SCTs), OCSP Must-Staple and OCSP stapling; validation against a combined trust store of operating system, Node.js and Mozilla/CCADB roots, refreshed weekly.
DNSSEC signature-lifetime monitoring and NSEC/NSEC3 analysis per RFC 9276; RPKI route-origin validation of the primary IP address.
Deep HTTP header analysis: CSP quality, Referrer-Policy values, reporting, Permissions-Policy, cross-origin isolation, CORS, cookie flags and information leaks.
Every check documented: what is tested, why it matters, how it is scored and how to fix it.