Email Cryptographic Posture
The cryptography a receiver actually sees — DKIM, DNSSEC, DANE, MTA-STS, BIMI — as a downloadable CycloneDX CBOM.
Read-only. We resolve public DNS and fetch your MTA-STS policy over HTTPS — nothing is changed and no mail is sent. Output is a standards-conformant CycloneDX 1.6 CBOM that opens in cbomkit and other CycloneDX viewers.
Scope: the DNS/HTTPS-observable cryptography of email. The SMTP-STARTTLS handshake (TLS version, cipher, certificate) needs an off-stack probe and is not in this version — it's declared as a gap in the CBOM.
Email cryptographic posture FAQ
What is a CBOM, and why would email need one?
A Cryptography Bill of Materials is a machine-readable inventory of the cryptographic assets a system relies on — algorithms, keys, certificates and protocols. Email runs on a lot of cryptography (DKIM signing keys, DNSSEC, DANE, MTA-STS, BIMI/VMC), and regulators increasingly ask organizations to inventory their crypto ahead of the migration to post-quantum algorithms. This tool produces the email slice of that inventory as a standard CycloneDX CBOM.
Is anything uploaded, changed, or sent?
No. The tool is read-only. It resolves your public DNS over Cloudflare's DoH resolver and fetches your published MTA-STS policy over HTTPS — the same lookups any mail server makes before delivering a message. Nothing is written and no mail is sent.
What does it inventory?
Everything a receiver can observe without your source code: DKIM key algorithm and size (flagging legacy RSA-1024), DNSSEC signing algorithms, DANE/TLSA on your MX, MTA-STS, and BIMI/VMC. Each becomes a component in a downloadable CycloneDX 1.6 CBOM.
Why doesn't it check my TLS ciphers or the SMTP handshake?
Inspecting the live STARTTLS handshake (TLS version, cipher, certificate) needs an outbound connection on port 25, which an edge-run tool can't make. Rather than guess, we declare it as a not-covered gap in the CBOM metadata. It's on the roadmap as an off-stack probe.
It says no DKIM key was found — is my email unsigned?
Not necessarily. DKIM has no discovery mechanism: a signature lives at a selector name you choose, and selectors can't be enumerated from DNS. We probe the common and provider-specific ones, but if you sign with a custom selector we'll miss it — so we call it a blind spot, not a confirmed gap. Add your selector(s) in the form to complete the inventory.
Is my email cryptography broken by quantum computers?
Every asymmetric algorithm email uses today — RSA, ECDSA, Ed25519 — is theoretically breakable by a large quantum computer, so the CBOM marks them as quantum-vulnerable. But there is no standardized post-quantum algorithm for DKIM yet, so there's nothing to migrate to right now. The honest near-term work is classical hygiene — retiring RSA-1024, enabling DNSSEC and MTA-STS. The CBOM is the crypto-agility inventory you'll re-check as PQC signing arrives.
Does the download work with cbomkit and other CycloneDX tools?
Yes. The export is a standards-conformant CycloneDX 1.6 CBOM, so it opens in the PQCA cbomkit viewer and any CycloneDX-aware tool. It's complementary to source-scanning CBOM generators: they read your code, we observe your deployed email cryptography from the outside.