Changelog
User-visible changes: new and improved checks, scoring changes, features and documentation updates across the domain scanner, the two live email tests (sender and receiver) and Record Studio. The domain scan runs 108 individual checks across six modules – every one explained on the checks & scoring page; the live sender and receiver tests add deep, message-level checks (SPF/DKIM/DMARC/ARC, S/MIME, STARTTLS/DANE/MTA-STS and more), and a single email can now cover both directions. Dates are deployment dates.
– Record Studio verifies HTTP(S) records over IPv4 and IPv6
- 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. If the host is reachable over IPv6 only, the generator warns that IPv4-only clients or senders cannot fetch it; if it resolves only to private/internal addresses, it warns that no one on the public internet can reach it; and if IPv4 and IPv6 serve different content, it flags the divergence.
– TLSA generator reads the certificate over IPv4 and IPv6
- Record Studio: the TLSA/DANE generator now fetches your live certificate over both address families. “Load current record & certificate” connects over IPv4 and IPv6 and shows which address it read the certificate from. If IPv4 and IPv6 serve different certificates, it warns that the generated record would match only one family – so you can align the certificates or publish a TLSA set covering both. Previously the certificate was read over a single, non-deterministic family without saying which.
– IPv6 in zone-transfer and name-server-distribution checks
- 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 check previously tested only one address per name server; it now tests every published family, so an exposure that exists only on the IPv6 listener is no longer missed.
- Name-server distribution (RFC 2182) now counts both families. The autonomous-system lookup covers each name server’s IPv4 and IPv6 address, so a server whose IPv4 is single-AS anycast but whose IPv6 sits in a different AS is credited for that diversity; the network fallback now grades IPv4 /24 and IPv6 /48 per family, and IPv6-only name-server sets are graded too. The drill-down shows the IPv6 addresses and their networks alongside IPv4.
– Full IPv6 coverage for address-based checks
- 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. It now samples both families per host, and notes when only a sample of many published addresses was checked. The receiver test’s FCrDNS check gets the same fix.
- 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. Both families are now validated and shown; the worse result determines the verdict.
- Reverse-DNS drill-down of the domain’s addresses includes IPv6. The DNS section’s PTR table previously listed IPv4 only; it now shows both families, and IPv6-only domains get a PTR table too. Name-server address hygiene likewise checks both families of every name server instead of a v4-first sample.
- Probes say which address they tested. The STARTTLS table and the receiver test now name the IP (and family) each connection actually used, and the receiver test notes that the other family of a dual-stack host is not separately tested. If the preferred family of a mail server is unreachable, the receiver test now retries once over the other family before declaring it unreachable.
- HTTP/3 (QUIC) probe retries over the other IP family. A dual-stack host whose first-resolved family gives no UDP answer is now probed once more over the other family, and the result names the families tested.
- 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. A published address family that does not answer on port 25 while the other works is flagged as a warning.
- Full address lists instead of samples. The reverse-DNS tables (domain addresses, mail servers, name servers) now cover up to four addresses per IP family and host – enough to list every address of typical setups in full; a sampling note appears only beyond that.
– More precise MTA-STS diagnostics
- 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).
- Matching recommendations. For unreachable policy files the recommendation now addresses the fetch problem (publish a reachable address, serve the policy over HTTPS) instead of suggesting
mode: enforce. - Receiver test. The receiver test’s MTA-STS check also names private/internal policy-host addresses as the fetch-failure cause.
– 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. The dark theme and the automatic/manual theme switch remain.
- 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. Scores, grades and all checks are unchanged.
- 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.
– Structured reports for the sender and receiver tests
- 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. Scores, grades and the individual checks are unchanged.
- “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.
- Embedded reports too. The bonus outbound analysis on the receiver test and the optional receiving-side section on the sender test use the same grouping — and each carries its own “What to fix first” list, exactly like the standalone tests.
- Collapsible groups. Each topic group is a collapsible card just like the sections of the domain scan: a header with the group’s question and its pass/warning/failure counts, the individual findings behind one click. The “What to fix first” list opens the right group automatically.
- 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.
– Service headings on the results page & pointer to the live mail tests
- Visible service groups. The six result sections are now grouped under three flat headings – Website, Email and DNS – matching the service blocks introduced in the overview. The sections themselves are unchanged: each keeps its own grade, refresh button and details.
- Live-test pointer. The email group now ends with a short pointer to the two live tests: the checks in the report are passive, while the sender test and receiver test examine a real message and a real delivery.
– Clearer report: triage list, service groups and plain-language subtitles
- “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. Each row jumps straight to the finding inside its section, so you no longer have to open six sections to see what actually needs fixing.
- 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.
- Consistent wording & cross-references. A Null MX (RFC 7505) is now described with identical wording in all three sections that mention it; DANE findings that fail for lack of DNSSEC point to the DNSSEC section; the certificate-trust and CAA findings reference each other; and the two distinct redirect checks (port 80 vs. final page) now explain how they differ.
– Test the receiving side straight from the sender test — no second email
- 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. The outbound probe still only ever runs when you explicitly ask for it and only against your own just-proven domain, so the sender test keeps its promise: it never sends unless you click. Together with the reverse enhancement shipped alongside it, a single email can now give you your complete mail-security picture in both directions.
– The receiver test now also analyses the message you 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. It appears automatically below the receive result; no second email needed. Even a proof that doesn't qualify to unlock the receiving-side test still yields the full outbound analysis, turning a rejection into useful diagnostics. Purely additive: the test still only ever sends to your own mail servers, and only after you've proven control.
– S/MIME signature & SMIMEA verification (sender test)
- 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. A broken signature — usually caused by a gateway or mailing-list footer modifying the message after signing — is flagged, because recipients see that as worse than no signature at all. Unsigned mail stays neutral and never affects the grade: S/MIME is an optional layer on top of DKIM. The certificate verifier is a zero-dependency CMS/PKCS#7 parser hardened against malformed input.
- 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. A record that no longer matches your certificate (typically after a certificate change) is flagged. To our knowledge no other tool cross-checks a published SMIMEA record against a live signature.
– Fix: a SHA-1 root is no longer flagged in the MX chain (receiver test)
- The receiver test's certificate-chain check no longer warns about a SHA-1 signature on a self-signed root CA (e.g. DigiCert Global Root CA). A trust anchor is validated by its identity, not its signature, so a SHA-1 self-signature on the root is not a weakness — only the leaf and intermediate certificates are checked, matching the main scan. This removes a false warning that could slightly lower the grade of otherwise-healthy mail servers.
– Public-CA trust of the MX certificate (receiver test)
- 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). Opportunistic senders don't verify this, but a sender enforcing MTA-STS or DANE-PKIX requires a publicly-trusted certificate — for them, an untrusted chain means real mail loss.
– Delivery-path trace (sender test) & reverse-DNS check (receiver test)
- 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.
- Receiver test — forward-confirmed reverse DNS (FCrDNS). We now check that each of your mail servers' IP addresses has a reverse DNS (PTR) record that resolves forward back to the same IP. This does not affect receiving mail, but reverse DNS that doesn't forward-confirm degrades the deliverability of mail your server sends — bounces, auto-replies and NDRs — which strict receivers reject.
– ARC chain verification (sender test)
- 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. ARC lets a forwarder vouch that your message passed SPF/DKIM/DMARC before it altered the message, so the final receiver can still trust the original result. Our verifier is validated against the full ValiMail ARC test suite (the cross-implementation reference corpus).
– MIME structure checks (sender test)
- 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. The parser is structure-only (it never decodes your content) and hardened against malformed input.
– MTA-STS enforcement simulation, TLS-RPT (receiver) and one-click unsubscribe (sender)
- 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). We also check your TLS-RPT record — the channel that reports these transport-security failures.
- 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 status of auth records and bounce-address deliverability (sender test)
- 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.
- Bounce-address deliverability. We now check whether your envelope return-path domain can receive delivery-failure reports: a Null MX or a domain with no MX/A means bounces have nowhere to go (and some receivers reject mail whose return-path cannot receive).
– SPF record hygiene checks (sender test)
- 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).
– DMARC external-report authorization and DKIM configuration hints (sender test)
- DMARC external-report authorization. When your DMARC reports go to a different domain (e.g. a monitoring provider), that domain must publish an authorization record or receivers silently send it nothing. The sender test now checks this (RFC 7489 §7.1) and flags an external report destination that is not authorized — a common, invisible reason DMARC reporting fails.
- DKIM configuration hints. We now flag fragile DKIM choices: simple header canonicalization (any relay whitespace change breaks the signature) and a signature-expiry window under five days (a delayed or retried delivery can fail DKIM).
– Weak DKIM-key screening and a DMARC reporting check (sender test)
- 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.
- DMARC aggregate-reporting check. We now flag a DMARC record with no rua= address: without it you receive no aggregate reports and are blind to who sends as your domain and to authentication failures — the data you need to safely tighten the policy.
– Certificate-chain drilldown (receiver) and HELO-SPF + reverse-DNS checks (sender)
- 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.
- Sender test — HELO-identity SPF and reverse-DNS quality. We now evaluate SPF for the HELO/EHLO name separately (RFC 7208 §2.3, as some receivers do), and flag a generic or dynamic-looking reverse-DNS name for the sending IP — a pattern Gmail and Yahoo penalise.
– DANE verification for the receiver test, plus more sender message-hygiene checks
- 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. A correct DANE deployment is confirmed; a mismatched or non-DNSSEC-signed one — which makes DANE-aware senders (large parts of the German ecosystem) refuse delivery — is flagged as a mail-loss risk, and we check rollover readiness (a second TLSA record for safe key rotation).
- Sender test — more message hygiene. New checks for over-long lines (the 998-octet limit that breaks DKIM downstream), undeclared 8-bit content, duplicate singleton headers, a missing Subject, and the REQUIRETLS (RFC 8689) transport-security signal.
– Sender & receiver tests: much deeper TLS, certificate and authentication analysis
- Receiver test — a full per-mail-server TLS & certificate matrix. For every mail server we probe, the report now shows the negotiated TLS version and cipher (with forward-secrecy classification), the certificate’s validity, name match and trust, a screen for weak/compromised RSA keys (ROCA/Fermat), a STARTTLS command-injection check, and the full SMTP conversation — depth that previously only lived in the main scan.
- Sender test — deeper DKIM, SPF and DMARC insight. The report now shows which display headers your DKIM signature actually covers (and whether they are oversigned), flags dual RSA+Ed25519 signing, warns on SPF void lookups before they become a hard PermError, adds a MIME-Version check and a HELO/EHLO identity check, and shows the full SMTP conversation plus 8BITMIME/SIZE details.
- 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. A reduced pct also correctly marks the domain as ineligible for BIMI.
– Receiver test: more accurate grading and clearer messages
- More accurate grades. A domain whose MX host does not resolve now fails clearly (rather than reporting that the test could not run), and when some mail servers were reachable but others could not be tested this time, the module no longer applies a worst-case grade to servers it never actually reached. A test that could not run at all now shows no grade instead of a misleading one.
- Honest open-relay result. If the open-relay probe cannot reach the recipient stage, it now reports “could not be determined” instead of implying relaying was refused.
- Clearer feedback. An oversized proof email is reported as too large (instead of appearing never to arrive), and every probe message carries a working opt-out (reply or
abuse@).
– New: email receiver test (does mail reach your MX?)
- 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. We only ever deliver to the exact address that contacted us, never to an address you type in, and every probe carries a one-click opt-out.
- The receive test complements the existing email sender test (which checks the mail you send) and the domain security check (which reads your DNS records).
– Record Studio: safer keys, more correct records, honest “load” warnings
- 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. It also flags a truncated or corrupted key, keys weaker than 1024 bits, and keys above the 4096-bit range receivers are required to support. - Generated records are valid even for awkward input. Logo, report and contact URLs in the BIMI, TLS-RPT and security.txt generators are normalised to valid URIs (spaces encoded, internationalised hosts converted to Punycode); report e-mail addresses with a
%are correctly encoded; and long DMARC, BIMI, TLS-RPT and MTA-STS records are split into 255-byte strings just like SPF and DKIM. security.txt now acceptsopenpgp4fpr:anddns:Encryption URIs, requires a leading “+” on phone contacts, and reminds you to keep your signing key valid until the file’s Expires date. - “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:), DMARCpct=/fo=/psd=, CAA account/validation parameters, unknown CAA tags such asissuevmc, a critical-flag on a custom CA, a BIMIlps=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 -allis correctly flagged; anhttp://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. - Various smaller fixes: stricter validation of MTA-STS hosts and
max_age, CAA issuer domains and wildcard rules, DKIM selector length and e-mail addresses, plus wording and accessibility polish.
– Mail send-test: more accurate verdicts and clearer errors
- 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”. Several SPF and DMARC edge cases now evaluate the way a real receiver would: the deprecatedptrmechanism, internationalised (IDN) domains, and a domain that publishes more than one DMARC record. - Clearer handling when something goes wrong. If the analysis can’t be completed, or you are briefly rate-limited while waiting, the send-test now shows a plain “please try again” message instead of a misleading result, and a failed test address no longer blocks an immediate retry.
– CAA: Signed HTTP Exchanges (cansignhttpexchanges)
- The CAA check now explains the
cansignhttpexchangesparameter, and the generator can produce it. When a CAAissuerecord carriescansignhttpexchanges=yes(e.g.0 issue "pki.goog; cansignhttpexchanges=yes"), the domain check now explains that it authorizes the CA to issue Signed HTTP Exchange (SXG) certificates — a Google/WICG mechanism you can remove if you don't serve Signed Exchanges. The CAA generator gained an advanced option to emit it (for Google Trust Services /pki.goog) and now round-trips it losslessly; loading a record with any other unsupported issue parameter warns you before it would be dropped on re-export.
– Record generators: the validity summary now stays put
- Loading a record no longer makes the validation summary vanish on the first click. After the CAA fix, the same one-view behaviour now applies to the SPF, DMARC, BIMI, MTA-STS, TLS-RPT and security.txt generators: the loaded record's colour-coded validity summary stays on top while you adjust the form below, instead of being replaced by a plainer view on the first edit. The BIMI logo preview also no longer lingers after you switch to a different domain.
– CAA generator: one consistent output
- Loading a domain's CAA records no longer switches layouts unexpectedly. Previously the CAA generator showed a validation summary after loading, then abruptly rebuilt into a different per-record layout on the first interaction (and the new sort control only appeared there). Now there is a single view: the validity summary on top, the sort toggle, and all records in one copy-all box — consistent whether you load an existing record or build one from scratch.
– CAA generator: sortable output
- The generated CAA records now come out in a clear, sortable order. In the CAA generator the record list is grouped by type by default (issue, issuewild, issuemail, then contact/iodef) and, within each group, ordered by flag and then domain — instead of following the checkbox order. A small Sort by toggle above the output lets you re-order by type, flag or domain. (DNS ignores record order, so this is purely for readability.)
– security.txt generator: phone contacts fixed
- A
tel:contact with spaces now works. In the security.txt generator, a phone contact such astel:+49 30 5550100was previously split apart on its spaces and rejected. It is now kept intact and normalized to a valid RFC 3966tel:URI, and the field makes clear that atel:number is an accepted contact alongside an email address or HTTPS URL.
– CAA generator: correct contact-phone format
- Contact phone now uses the required international format. The CAA generator now writes
contactphoneas an RFC 3966 “Global Number” — with a mandatory leading+and country code, and no spaces — which is the format a certificate authority needs in order to use it (CA/Browser Forum Baseline Requirements). A number without a country code is now flagged instead of being silently accepted. It also makes surecontactemailis always written as a plain address — a straymailto:prefix is now stripped (unlikeiodef, which is a URL and correctly keeps exactly one).
– Smoother on phones: no sideways scrolling, bigger tap targets
- 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.
- Bigger, easier tap targets. The theme switch, the per-check refresh buttons, and the Record Studio controls — generate and copy buttons, the CAA and sending-service check lists with their checkboxes and dropdowns — are now comfortably sized for touch on small screens.
- Responsive BIMI logo preview. The logo preview in the BIMI generator now scales down and reflows cleanly on narrow screens instead of overflowing.
– Weak-key screening and a full-chain signature check
- 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. If a key matches, its private key can be derived from the public key, so the certificate is reported as a failure with the advice to replace the key — the same weak keys the CA/Browser Forum requires CAs to reject (§6.1.1.3). Healthy keys are unaffected.
- SHA-1 across the whole chain, not just the leaf. The signature-algorithm check now also inspects the served intermediate CA certificates. A SHA-1/MD5-signed intermediate is flagged — browsers reject SHA-1 in the chain, and the CA/Browser Forum sunsets remaining SHA-1 use by 15 September 2026 (§7.1.3.2.1). Self-signed roots are correctly ignored (their signature is not validated).
– CAA contact properties, and sharper certificate lifetime & hostname checks
- CAA contact properties in the generator and the check. The CAA generator can now publish a domain contact —
contactemailandcontactphone— 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 domain check now explains these properties, and when CAA records are present it notes that from 15 March 2026 CAs must DNSSEC-validate CAA lookups (a DNSSEC-signed zone makes your CAA records tamper-proof). - 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. A certificate that is only over the tighter upcoming CA/Browser Forum limit for its issuance date (SC-081 schedule: 200 days from 2026, 100 from 2027, 47 from 2029) stays a warning, with wording that makes clear browsers do not reject it yet.
- 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. - Clearer OCSP Must-Staple wording. Updated to reflect that mainstream browsers no longer hard-enforce Must-Staple and that OCSP is being retired (CA/Browser Forum SC-063), so an unstapled Must-Staple certificate is now more of a renewal/misconfiguration risk than a security gain.
– CAA: RFC 8657 account and validation-method binding
- 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). The parameters are appended to yourissue/issuewildrules, and loading an existing record ticks them back onto the form. The generator warns when anaccounturiis combined with more than one issuing CA (only one CA can satisfy it) and rejects a malformed URI. - The domain check now reads these parameters. The CAA check reports when issuance is additionally pinned to an ACME account or validation method, and flags a property that carries more than one
accounturias unsatisfiable (RFC 8657 §3). From 15 March 2027, all publicly trusted CAs must honour these parameters (CA/Browser Forum Baseline Requirements §4.2.2.1.2).
– SPF generator: Atlassian and SAP Cloud added
- Atlassian and SAP Cloud added to the SPF generator. The "other sending services" list in the SPF generator now includes Atlassian (
_spf.atlassian.net) and SAP Cloud for Customer / S/4HANA Cloud / Business ByDesign (_spf.cmail.ondemand.com). Tick either service that also sends mail for your domain and itsinclude:is added to the record; loading your current SPF ticks the ones you already publish. Both includes were verified against live DNS to resolve to av=spf1record.
– SPF generator: CodeTwo Email Signatures
- CodeTwo Email Signatures 365 added to the SPF generator. The "other sending services" list in the SPF generator now includes CodeTwo. Because CodeTwo runs one sending environment per Azure data-center region, the entry has a region dropdown — pick the region of your Microsoft 365 tenant and only that region's
include:is added, so you don't over-authorize with the wrong data center. Loading an existing record also recognizes the region automatically.
– New scanner IPv6 address
- The scanner's IPv6 address changed from
2a0a:4cc0:c2:23fb:9839:e2ff:fe98:1fd1to the simpler2a0a:4cc0:c2:23fb::1; the IPv4 address (159.195.68.98) is unchanged. If you allow-list or block the scanner by IP, update your rules — the scanner page always lists the current addresses. Reverse DNS stays forward-confirmeddomainsecuritycheck.de.
– Record Studio: Enter loads the record
- In every generator, pressing Enter in the domain field (or the selector, host or email field that parameterizes the lookup) now triggers "Load current record" directly — no need to reach for the button.
– Deep BIMI validation in the domain check and the sender test
- 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). A BIMI record only rates as fully valid when all of it verifies; the report's BIMI details show each result.
- The domain check also flags an ambiguous set of multiple BIMI records, which receivers ignore.
– VMC certificates are now cryptographically verified
- 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 self-signed or otherwise unrecognized certificate that merely carries the BIMI marking is now correctly rejected, and the preview names the CA the certificate chains to.
- And the logo is bound to that certificate. The SVG served at your
l=URL must hash to the exact image the CA embedded in the VMC (RFC 3709 logotype extension) — so a logo swapped out after issuance is caught too. Together with the chain check, the preview now performs every check a mailbox provider does before it will display a BIMI logo.
– BIMI without a mark certificate (VMC) is now a warning
- 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).
– Record Studio: preview your BIMI logo
- 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.
- If the hosted logo or certificate doesn't fully verify (for example the URL 404s or the certificate has expired), a checklist shows exactly what is wrong. The logo is rendered from a sandboxed
data:image (scripts inside the SVG can never run), and the lookup is SSRF-guarded and rate-limited like our other outbound checks.
– New: Email sender test (MailFrom)
- 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. The test only receives — it never sends any email.
- 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. - It also reports the transport your server used (STARTTLS on/off, TLS version and cipher), forward-confirmed reverse DNS (FCrDNS), the IPv4/IPv6 delivery path, and message hygiene (Message-ID, a valid Date, duplicate or multi-valued From headers, SMTP-smuggling line endings).
- It also checks BIMI eligibility for the message: it resolves the BIMI record (honouring a
BIMI-Selectorheader and the organizational-domain fallback), gates it on this message's DMARC result and an enforced policy, and fetches the SVG logo to confirm it is a clean SVG Tiny PS file — the checks Gmail, Apple Mail and Yahoo apply before showing your brand logo. - 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. No signup.
– Accuracy pass across DNSSEC, DANE, mail and header checks
- 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.
- E-mail authentication. Ed25519 DKIM keys are now recognized instead of “length unknown”; SPF lookup counting and the default-policy (
all) reading are more correct; a DMARC record with an invalidsp/npvalue is now graded the way receivers actually treat it (RFC 9989 §4.10.1); and MTA-STS / TLS-RPT no longer claim “no MX” when the MX lookup merely failed. - HTTP security headers. Fixed several edge cases: multiple
Strict-Transport-Securityheaders, a few strict-CSP criteria, an unknownReferrer-Policyvalue, and false “mixed content” from commented-out or non-fetching resources. - Record Studio “load current record”. Fixes to the SMIMEA flow (trailing spaces, clearer network-error messages, no spurious “paste the issuer” warning when reloading a full-certificate record), an SPF warning for host-specific
a:/mx:mechanisms, DMARC report addresses carrying a legacy size suffix, and MTA-STS records whose policy file is unreachable. - Full German translations. Several strings that still appeared in English on the German pages — record-check details, server error messages and the theme toggle — are now translated.
– Simpler tool names in Record Studio
- Each tool in Record Studio now goes by its record type alone: the SPF, DKIM, DMARC, BIMI, TLSA, SMIMEA, MTA-STS, TLS-RPT, CAA, security.txt and Null MX pages dropped the “…record generator” suffix from their headings and titles. It reads cleaner and less repetitively; the pages, features and URLs are otherwise unchanged.
– “Record generators” is now “Record Studio”
- 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. Its pages moved from
/generators…to/record-studio…, while every individual tool — the CAA, TLSA, SMIMEA … record generator — keeps its own name.
– CAA generator: Certigna removed (no longer issues public TLS)
- Following today’s CA-list expansion, an audit against the Chrome, Mozilla and Microsoft root stores found that Certigna (Dhimyotis) stopped issuing publicly-trusted TLS certificates on 14 June 2026 — its remaining Chrome root is constrained and Apple never recognized it, so it can no longer deliver a browser-trusted certificate. It has been removed from the built-in CA list (now 45 CAs), which only lists CAs that can actually issue a browser-trusted certificate. If you use Certigna for S/MIME, you can still authorize it via the “Other issuemail CAs” field.
– CAA generator: many more certificate authorities, now searchable
- 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. A search box filters the list by name or domain, and the list now scrolls within a fixed height with a sticky header. Distrusted or exited CAs (e.g. Entrust, AC Camerfirma, e-Tugra, Chunghwa Telecom, NETLOCK, Symantec) are intentionally left out; you can still authorize any other CA via the “Other … CAs” fields.
– CAA generator grid is now a table with row separators
- The per-CA authorization grid is now a proper table with light row separators and a row-hover highlight, so it is easier to see which checkboxes belong to which certificate authority.
– CAA generator: per-CA critical-flag selector
- Each CA in the grid now has a flag selector (0 or 128) that sets the CAA record flag. It defaults to 0; a warning is shown if you combine flag 128 with
issuemail, because a CA that does not understandissuemailwould then have to refuse all issuance — including TLS (RFC 9495 §6).
– CAA generator rebuilt as a per-CA issue / issuewild / issuemail grid
- The CAA record generator is now a grid: each certificate authority has separate
issue,issuewildandissuemailcheckboxes, so you can click together exactly which issuance types each CA may perform. “Other CA domains” was replaced by three per-type fields (issue / issuewild / issuemail).
– Docs: CAA for S/MIME (issuemail)
- The checks & scoring docs now have a dedicated section on
issuemail(RFC 9495): how it restricts S/MIME certificate issuers, why it is independent ofissue/issuewild, and the flag-128 (critical) interoperability caveat.
– CAA generator: restrict S/MIME certificate issuers (issuemail)
- The CAA generator can now emit
issuemailrecords (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 ";"). Theissue/issuewildrules do not cover S/MIME. Loading a current record recognisesissuemailtoo, and the report’s CAA verdict now shows the S/MIME issuers.
– Generator lists sorted & polished
- The certificate-authority list (CAA generator) and the sending-service list (SPF generator) are now sorted alphabetically, Inxmail was added to the sending-service list, and the parenthesised value annotations were tightened.
– Scan identifies newsletter / marketing ESPs on sending subdomains
- 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). Dedicated newsletter / sending subdomains (e.g.
news.example.com) point their MX straight at the ESP, so scanning one now names the sender and, if its documented SPF include is missing, suggests it. Every include was verified against live DNS.
– SPF generator: add sending-service includes with a click
- 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). Tick the services that also send mail for your domain and their
include:is added to the record; loading your current SPF ticks the ones you already publish. Every include was verified against live DNS to resolve to a v=spf1 record.
– SPF generator: 20 more mail providers recognised
- The SPF generator’s “suggest include from your mail provider” button now recognises 20 more hosted-mail and web-hosting providers — including Spacemail, StartMail, MXroute, Mailo, Disroot, Soverin, Zone.eu, Loopia, Simply.com, OpenSRS/Hover, Atmail Cloud, Kerio Cloud, Register.it, Locaweb, UOL Host, Onet, Interia, Wirtualna Polska and Sina Enterprise Mail. Every SPF include was re-verified against live DNS to still resolve to a v=spf1 record.
– CAA generator: more certificate authorities
- The CAA record generator’s authority list is longer: added Buypass, GoDaddy/Starfield, SSL.com, Certum, Actalis, HARICA and IdenTrust, noted that ZeroSSL issues under Sectigo, and expanded Amazon to its full set of AWS trust domains. Every identifier was verified against the CCADB CAA Identifiers Report and each CA’s own documentation — a wrong identifier can block issuance, so ticking a box now emits all of that CA’s valid identifiers.
– Validity check & details when you load a record — now for every generator
- 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. It goes beyond the record’s own text: SPF resolves your includes to count the real 10-DNS-lookup limit and spots broken targets; DKIM reads the published key type and length and flags revoked or weak keys; DMARC grades the policy strength; BIMI checks that DMARC is actually enforced; MTA-STS fetches and validates the HTTPS policy file (mode, MX match, max_age); security.txt is validated against RFC 9116 including the Expires date; CAA and TLS-RPT are checked too. Each shows the parsed details (key length, policy, allowed CAs, expiry, …) beneath the record.
– TLSA generator: certificate details shown under each matching record
- When a domain publishes several TLSA records, the details of the certificate each record points at are now shown directly beneath that record, instead of as one combined list — so it is always clear which certificate belongs to which record (for example when two records pin two different chain certificates).
– TLSA & SMIMEA generators: certificate details when you load a record
- Loading a record now also shows the certificate behind it, not just the raw DNS value. For TLSA you get the full certificate chain your server serves — subject, issuer, validity and days to expiry, key type and size, signature algorithm, SANs and SHA-256 fingerprint, each labelled leaf / intermediate / root. For SMIMEA, when the whole certificate is published (a
3 0 0record), the embedded certificate is decoded and shown the same way. It makes it easy to confirm at a glance which certificate a record actually points at.
– TLSA & SMIMEA generators: colour-coded validity when you load a record
- When you load a domain’s current TLSA or SMIMEA record, each record is now marked green, amber or red for validity. For TLSA it checks whether the record actually matches the certificate your server serves, whether the pinned position fits the usage, and whether the zone is DNSSEC-signed (which DANE requires). For SMIMEA it checks the format and — when the whole certificate is published (a
3 0 0record) — whether that certificate is currently valid and issued for the address, again with a DNSSEC indicator. So you can see at a glance whether a published record is correct.
– SMIMEA generator: 3 0 0 default, and “Load current record” now fills the form
- The SMIMEA generator now defaults to
3 0 0(DANE-EE, full certificate, no hash), which publishes your whole certificate in DNS — the right choice for S/MIME discovery, where a sender fetches your certificate to encrypt to you (a hash only lets a client verify one it already holds). And “Load current record” now fills the form from what is published — usage, selector, matching, and, for a full-certificate record, the certificate itself — instead of only showing the result below.
– New: SMIMEA record generator (DANE for S/MIME)
- 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. Paste your certificate, pick usage/selector/matching, and it computes the record locally in your browser, including the generic RFC 3597 (TYPE53) form for DNS panels without native SMIMEA support. “Load current record” reads any record already published for the address. The caveats are spelled out: DNSSEC is required, the RFC is Experimental (limited client support), and publishing exposes a hash of the address (sign the zone with NSEC3).
– Each record generator now has its own page
- 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). Every generator has its own address – for example
/record-studio/tlsa.html– which makes them easier to find, share and bookmark. Existing links keep working: the hub redirects old bookmarks to the right page.
– SPF/DMARC/TLS-RPT generators: warn on multiple published records
- 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). When you load the current record in the generator and several are published, it now warns you about the invalid duplication (and loads the first) instead of silently taking one.
– TLSA generator: choose among multiple published records
- When you load a domain's current TLSA records and it publishes several (e.g. during a key rollover, or a DANE-EE + DANE-TA pair), a new dropdown under the “Load current record” button lists all of them. Each entry shows which certificate of the served chain it pins, and the record matching your currently served certificate is preselected. Picking one aligns the certificate picker and the form to that record.
– DANE-TA root-pin note (prefer 2 0 0)
- A DANE-TA (usage 2) TLSA record that pins a root CA only validates while the server includes that root in its chain. A cross-signed root (e.g. Let's Encrypt's ISRG Root X2, cross-signed by ISRG Root X1) drops out of the chain once the cross-signature expires, which would break DANE. The web DANE check now still passes such a record but adds a note recommending a DANE-TA
2 0 0record (the full root certificate in DNS), which does not depend on the server sending the root. A record that already pins the root via2 0 0is recognised as robust and passes cleanly, without the note. - The TLSA record generator's root-pin warning now points to
2 0 0as the robust way to pin a root and flags the cross-signature-expiry pitfall.
– Robust root-CA detection (cross-signed roots)
- Some root CAs are, for legacy compatibility, additionally cross-signed by an older root, so they appear in a chain without being self-signed (e.g. “Amazon Root CA 3” presented signed by an older Starfield root). Root-vs-intermediate is now determined from the weekly-updated trust store (public-key match), not from naive chain position — so such cross-signed roots are correctly recognized as roots.
- TLSA record generator: the certificate picker now labels a cross-signed root as “Root CA” (previously “Intermediate CA”) and shows the root-pinning caveat for DANE-TA.
- Domain check (web DANE): a PKIX-TA (usage 0) record that pins a cross-signed root present in the served chain is now treated as a valid root pin, instead of being warned as an intermediate pin.
– DNSSEC check: consistency & accuracy pass
- 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. RSA/SHA-512 and unknown algorithms remain a warning.
- An expired signature on a signed-but-unanchored zone (no DS record at the parent) is no longer graded F – there validating resolvers do not check the signatures, so delivery is unaffected; it is now a warning.
- 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.
- DS-to-DNSKEY matching now also compares the algorithm (RFC 4034), so a 16-bit key-tag collision can no longer mask a stale DS record.
– Mail DANE check: PKIX-TA/EE records (usage 0/1) handled per RFC 7672
- 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.
- This fixes two edge cases: a non-matching PKIX record (e.g. PKIX-TA on the root) previously produced a hard failure with a grade cap, and a matching PKIX record previously reported DANE protection that SMTP clients don't actually honour.
– Web-DANE check: smarter handling of PKIX-TA (usage 0) records
- The HTTPS DANE check now distinguishes how a PKIX-TA (usage 0) record is used. Pinning an intermediate via PKIX-TA gives a mild warning with a hint: for a trust-anchor pin under DNSSEC, DANE-TA (usage 2) fits an intermediate better – or a DANE-TA
2 0 0record to pin the full root. - A PKIX-TA record that pins the root CA is no longer wrongly failed: servers don't send the root in the handshake, so it can't be matched against the served chain – but it is valid (clients validate it via their own trust store), so it is now reported as informational rather than a hard failure.
– TLSA generator: when to pin the root vs. an intermediate (PKIX-TA vs DANE-TA)
- The TLSA generator now explains a subtle DANE point: DANE-TA (usage 2) requires the pinned certificate to be in the chain your server actually sends, and servers normally send intermediates but not the root (RFC 7671 §5.2). So for DANE-TA, pin an intermediate. To pin the root, PKIX-TA (usage 0) is the usage that works, because it validates against the client's trust store — though PKIX usages are discouraged for SMTP (RFC 7672).
- If you select the root certificate in the chain picker, a short warning now points this out so you don't publish a DANE-TA record that won't validate.
– SPF generator now recommends softfail (~all)
- The SPF generator now defaults to
~all(softfail) instead of-all, matching the scanner's own recommendation. A short note explains why: with DMARC in place, forwarded mail can fail SPF and-allwould reject it before DMARC can pass it on a valid DKIM signature — so softfail is just as strict while keeping legitimate forwarded mail deliverable. Choose-allonly without DMARC or for non-sending domains. - The scanner's SPF guidance and the documentation now use
~allin their examples too, so the recommendation is consistent across the scanner, docs and generator.
– Jump from a finding straight to the matching record generator
- 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 link appears only where there is something to build or fix, right next to “Why & how to fix?”.
– Your mail provider in the scan report
- 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.
- It is shown for information only and never changes your grade. Because MX describes incoming mail, the detected provider is a strong hint for the sender only for hosted mailbox providers; inbound security gateways (Mimecast, Proofpoint, Barracuda, Cisco …) are recognised and clearly labelled as filters that sit in front of the real mailbox.
- If a hosted provider is recognised but its documented sending SPF
include:is missing from your SPF record, a gentle note suggests adding it — so mail sent through the provider passes SPF.
– Suggest the right SPF include from your mail provider
- 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). - Because MX describes incoming mail while SPF authorises outgoing mail, the suggestion covers your mailbox provider only — you are reminded to add includes for any other services that send on your behalf (newsletters, CRM, transactional email).
- Inbound security gateways (Mimecast, Proofpoint, Barracuda, Cisco and others) are recognised and clearly flagged, because your real sending provider sits behind them and cannot be read from the MX records.
- Includes already present in your published SPF record are detected and not duplicated. Every suggested include was verified to resolve to a live SPF record.
– Build a TLSA record from your live certificate
- 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 1record for you. - When the server presents a full chain, you can pick which certificate to pin — leaf for DANE-EE, an intermediate or root CA for DANE-TA — and the usage adjusts automatically.
- One click on Load current record & certificate does everything at once: it reads the TLSA record published in your DNS, fetches your live certificate, and automatically pre-selects the exact certificate the record pins — matched by recomputing the hash — so you instantly see what is live and can edit it.
- Change usage, selector or matching type and the record recomputes locally — the certificate stays in the form, so no second request is needed.
- The Usage and Matching-type menus now cover every value from RFC 6698: PKIX-TA (0) and PKIX-EE (1) alongside DANE-TA (2)/DANE-EE (3), and Full (0 — exact match, no hash) alongside SHA-256/512, each with an inline note on where PKIX usages are discouraged (SMTP, RFC 7672) and that Full produces large records (RFC 7671).
- A Protocol selector (tcp / udp / sctp) sets the transport label in the record name (_port._proto), per RFC 6698 §3 — tcp by default. udp/sctp cover DTLS/SCTP services; the live-certificate fetch stays TCP-only, so for those you paste the certificate.
- We could not find another online TLSA generator that builds the record from your live certificate.
- The connection is SSRF-guarded and limited to the standard mail/web TLS ports; only your host and port are sent to our server, and it only ever reads the public certificate — never a private key.
- Clearer guidance on the certificate usage field — shown next to the Usage selector and in the DANE/TLSA documentation: PKIX (0/1) still requires the certificate to validate against a public CA and only adds a pin, whereas DANE (2/3) replaces the public CA and makes the DNSSEC-signed record itself the trust anchor; TA (0/2) pins the issuing CA, while EE (1/3) pins the certificate. The generator now defaults to port 25, the main DANE use case.
– Load your published record into the generators
- 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.
- Works for SPF, DKIM, DMARC, BIMI, TLSA, MTA-STS, TLS-RPT, CAA and security.txt (the MTA-STS policy file and security.txt are fetched over HTTPS).
- The generators still run entirely in your browser; only the domain you want to read is sent to our server, which looks it up in public DNS – exactly like a scan. Nothing else you type, and no generated private key, is ever transmitted.
– DNS record generators
- 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.
- Generated records follow the current standards, including DMARCbis (RFC 9989).
- The BIMI generator and the BIMI check support the avatar preference tag (
avp=) from the current BIMI draft.
– Complete German version, DMARCbis & 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.
- Split the documentation into six topic pages per language – web TLS, HTTP security headers, DNS, DNSSEC, email authentication, mail TLS & DANE – with a linking overview; scan findings link straight to the matching topic page.
- Added six German pages: tool comparison, scanner details, cipher suites, trust store, legal notice and privacy policy.
- 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. The documentation now covers 106 checks. - security.txt check upgraded to full RFC 9116 validation: syntax, Contact and Canonical URIs, expiry rules and PGP signature framing.
- Incomplete certificate chains are now cross-checked against the ~1,700 publicly disclosed CCADB intermediate certificates (refreshed weekly alongside the root store): a chain that browsers can still complete is distinguished from a genuinely untrusted one and graded B instead of T.
- The overall grade now appears only once all six modules have finished; a pending indicator replaces the running partial score.
- Visitors with a German-language browser see a dismissible hint on the English homepage pointing to the German version – without cookies.
- The frequently asked questions moved from the homepage to a dedicated FAQ page, making the start page leaner.
– Discoverability & accuracy fixes
- 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.
- The check documentation is now statically pre-rendered into the pages, and robots.txt, sitemap, llms.txt, Open Graph images and structured data were added – for search engines and AI assistants alike.
- Updated all DMARC references to the new RFC 9989–9991 family (DMARCbis, obsoletes RFC 7489).
- Fixed a batch of accuracy bugs: SPF include lookups hitting DNS server failures now yield a temporary error instead of a hard fail, HSTS preload handles TLD-level preloading (.dev/.app) and pending removals, and a false pass in the CSP frame-ancestors check was corrected, among others.
- Fixed intermittently empty responses on HTTP-to-HTTPS redirects and error pages, caused by a crash in a web server module.
– Anycast providers & DKIM selectors
- 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.
– 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.
- The key-exchange signature hash is now assessed per TLS version with a drill-down of affected cipher suites; false positives on modern servers that merely tolerate SHA-224 for legacy clients were eliminated.
- 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.
- Cross-origin isolation headers (COOP/COEP) no longer affect the grade – present protection shows as “good”, absence is informational only.
- The technology disclosure check no longer mistakes product names containing digits (such as AmazonS3) for version numbers.
- HTTP/3 support is now verified with real end-to-end QUIC probes instead of relying on the Alt-Svc header alone.
- Removed the approximate SSL Labs score from the web module; the individual findings remain the authoritative assessment.
- The overview timestamp shows when the checks actually ran instead of when the page was reloaded.
- This site's PGP-signed security.txt was re-signed with a dedicated security contact, and its expiry was aligned with the signing key.
– 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.
- Mail TLS results explain why this scanner finds legacy TLS 1.0/1.1 on mail servers that some other tools miss.
- New web backends check: the IPv4 and IPv6 backends behind a domain are TLS-profiled (representative addresses in full, further ones confirmed by handshake), configuration differences between backends are flagged, and known CDNs (CloudFront, Akamai, Fastly, Cloudflare and more) are labeled.
- 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.
– 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. - DNSSEC algorithm ratings updated to RFC 9904; online signers with short signature windows no longer trigger false expiry warnings.
- 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.
- TLS 1.3 cipher suites are now probed individually rather than inferred, and the cipher score measures what is actually enabled.
- The cipher drill-down shows the official IANA/RFC suite names alongside the OpenSSL names.
- 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.
- OCSP stapling is reported as “not applicable” for certificates from CAs that have retired OCSP (Let's Encrypt, Google Trust Services, HARICA).
- The client compatibility simulation now covers current Chrome, Firefox and Safari plus Android 14, Java 17 LTS and OpenSSL 3.x.
- 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.
- Fixed 30 correctness and robustness issues found in a full-code audit.
- 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.
- Added dedicated legal notice and privacy policy pages.
- This site itself now runs HTTP/3 (QUIC), post-quantum hybrid key exchange (X25519MLKEM768) and only 256-bit cipher suites, and publishes HTTPS DNS records.
– 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.
- Overhauled the mobile layout and added a sticky mini-overview with live grades; overview bars jump directly to the corresponding module.
- Added a manual theme toggle (auto/dark/light) and a new “good” status – a light-green check mark for criteria that are met but not grade-relevant.
- Added abuse protection via Cloudflare Turnstile in front of the scan API.
- Added the scanner information page (identify & block); scanner requests identify themselves with a transparent bot user agent linking to it.
- Internationalized domain names are accepted as input, and the overall grade stays honest – it shows “incomplete” when a module fails.
- 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.
- Published a PGP-signed security.txt (RFC 9116) for this site itself.
– 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.