Email Cryptographic Posture

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.

Nothing is changed: the tool is strictly read-only, writes nothing to your DNS, and sends no mail. But be clear on what does travel. This scan runs on our server, not in your browser, so the domain you enter — and any selectors you add — are sent to HireAmino in the URL, and on to Cloudflare's DNS-over-HTTPS resolver to perform the lookups. Those are public records: the same lookups any mail server makes before delivering to you. We don't store the scan or its result, and result pages aren't indexed by search engines. No email content, credentials, private keys or files are ever uploaded — there is nothing of that kind to upload. See our Privacy page.

Deliberately not complete, and the artifact says so. Two hard limits: DKIM selector names cannot be enumerated from DNS — there is no 'list my selectors' query, so we probe a list of common and provider-specific names and you can add your own — and we never open an SMTP connection, so the STARTTLS handshake (TLS version, cipher, certificate) is out of scope. The CBOM carries a CycloneDX composition marked 'incomplete' plus the exact number of selectors checked, so a downstream tool can't mistake it for an exhaustive inventory.

Yes — from a message you already sent. Open the paste box under the form and drop in the full source of any message from the domain: its DKIM-Signature header names the selector, the signing domain, and the algorithm it was actually signed with (something the DNS key record can't tell you). That parsing happens in your browser — the message is never sent to us. Only the selector name, domain and algorithm go into the form, and then the same public DNS lookups run as always.

A DKIM record whose p= tag is empty means the key has been revoked (RFC 6376) — the name still exists but signs nothing. That's normal for a retired selector, and some domains publish it at every name deliberately, to say 'nothing here signs mail'. We count those separately and never list them as cryptographic assets: an inventory of revoked keys is not an inventory of your cryptography.

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 CBOM — 1.7 by default, with 1.6 available for consumers pinned to it.

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.

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 and they carry through to the download as well.

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.

Yes. The export is a standards-conformant CycloneDX CBOM — 1.7 by default, or 1.6 on request — 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.