We measured the Fortune 50's email cryptography. Most of what we found is 1024-bit RSA.

What cryptography does your email actually use?

More than you think, and nearly all of it is published where anyone can read it. Unlike the cryptography inside your application code, the crypto that signs and secures your mail lives in DNS and on the mail edge — externally observable, no server access required. That is what makes an email Cryptographic Bill of Materials possible to build from the outside, and it is why the audit below needed nothing but public DNS and HTTPS. Five parts of that inventory are visible in public records:

Each row is a line item in a crypto inventory, and each is resolvable without touching a single server. We resolved all five for the fifty largest companies in America to see what that inventory actually contains.

Is 1024-bit RSA safe for DKIM?

It clears DKIM's hard floor and nothing above it. RFC 8301, the January 2018 update to DKIM's cryptographic requirements, is explicit: "Signers MUST use RSA keys of at least 1024 bits for all keys. Signers SHOULD use RSA keys of at least 2048 bits." So a 1024-bit key is legal DKIM — the bare minimum the protocol accepts — while sitting below the size the same RFC tells you to use. The firmer verdict comes from outside email: NIST's transition guidance, SP 800-131A, disallowed key lengths below 112 bits of security strength for generating digital signatures after 31 December 2013, and 112 bits of strength is a 2048-bit RSA key, while a 1024-bit key provides roughly 80. By that NIST standard, 1024-bit RSA has sat below the line for signatures for more than a decade. It is not that these keys break tomorrow — it is that a signing key a well-resourced adversary can factor is a key an adversary can use to sign mail as you, and NIST classifies 1024-bit as the strength the industry was supposed to leave behind two RSA generations ago.

What does the Fortune 50's email cryptography actually look like?

Thin where it protects, and a generation behind where it signs. We took the Fortune 50 — the fifty largest US companies by revenue on the 2026 Fortune 500, the same sample behind our DMARC-under-RFC-9989 measurement — and resolved each company's email cryptography over public DNS and HTTPS in July 2026. Per house style we name no individual company; every figure is public DNS, and the sample is aggregate.

Three findings stand out in our scan:

• Brand crypto beats security crypto. BIMI — the logo mark, backed by a certificate a company pays for — appears on 14 of the 50 domains, while DNSSEC, MTA-STS and DANE, the controls that protect the mail path, appear on 6, 2 and 0. That is eight security deployments against fourteen for the logo: crypto with a marketing return gets funded, and crypto with only a security return waits.
• Where they sign, they sign old. Of the 145 DKIM keys the scan could find, 58 — 40% — are 1024-bit RSA, the strength NIST stopped allowing for new signatures in 2013, and 27 of the 50 domains publish at least one. Selectors are not enumerable from DNS, so this common-selector sample is a floor: the true 1024-bit count can only be higher.
• Not one modern key. The Ed25519 algorithm has been standardized for DKIM since RFC 8463 in September 2018, yet across all 145 keys in the sample we found zero of it — at this tier, adoption is a rounding error.

Why is the security crypto missing and the weak keys still there?

Because email tells you nothing when the crypto is weak — and the defaults were set when 1024 was normal. Three forces hold this posture in place, and none of them is negligence:

1. DKIM keys almost never rotate. A key is generated at setup, published once as a DNS TXT record, and left for years — no expiry, no renewal prompt, no bounce when it ages past its recommended strength. The most widely deployed example makes the point: Google Workspace leaves DKIM key length to a manual choice at setup, and its own DKIM setup documentation still lists 1024-bit as a selectable option alongside 2048 — then, once a key is generated, offers no expiry, no renewal prompt, and nothing that revisits a 1024-bit choice later. The weak key is not a mistake anyone made; it is the box nobody reopened.
2. Weakness and absence are both silent. This is the same failure mode as every other authentication regression: nobody emails you an error when your SPF breaks, and nobody emails you when your DKIM key is a generation behind or your zone is unsigned. A 1024-bit signature still verifies, mail still lands, and every dashboard stays green, so the one signal that would prompt a fix never fires.
3. DNSSEC, DANE and MTA-STS are opt-in work with no visible payoff. Signing a zone or publishing an MTA-STS policy takes effort, carries a small operational risk, and changes nothing a customer will ever see — unlike a BIMI logo, which shows up in the inbox. Rational budget-holders fund the visible thing.

That last force is precisely the gap a bill of materials exists to close: it makes the invisible inventory legible, so an absent DNSSEC signature or a 1024-bit key becomes a line item on a page instead of a non-event nobody is measuring. You can read what your own domain publishes for SPF, DKIM and DMARC in a few seconds — the problem was never that the data is hidden, only that nothing pushes you to look.

What is a CBOM, and why does email need one?

A CBOM is a structured inventory of the crypto you actually run — and email is one of its richest, most externally-observable slices. The dominant format is CycloneDX 1.6, released in April 2024 and ratified as ECMA-424, which added a cryptographic-asset model developed by IBM Research: algorithms, keys, certificates, and the protocols that use them, catalogued as first-class components. The reason this became a board-level exercise is regulation: OMB memorandum M-23-02, issued 18 November 2022, required federal agencies to inventory their active cryptographic systems and report the quantum-vulnerable ones, which turned a crypto inventory into a compliance artifact rather than a nice-to-have. The pressure is not purely governmental — crypto-agility, the ability to know what you run and swap it quickly, is now the baseline behind PCI DSS 4.0 and every serious post-quantum migration plan. Here the gap email fills is structural, not incidental: the reference tool in this space is cbomkit, the Post-Quantum Cryptography Alliance's project under the Linux Foundation, and it is a source and binary scanner — it discovers the cryptography your code depends on. It cannot see a 1024-bit DKIM key in your DNS, a missing DNSSEC signature, an absent MTA-STS policy, or the algorithm a third-party sending vendor signs with, because none of that lives in your codebase. A CBOM assembled by observing the mail edge — the same DNS and TLS surface an authentication audit already probes — is the slice a source scanner structurally cannot reach. Observed and source-scanned CBOMs are complementary halves of one inventory, and as our Fortune 50 scan shows, email lives entirely in the half most tools miss.

Does post-quantum cryptography change what you should do about email today?

Yes — but not the way the headlines imply. For email specifically, the honest answer is inventory and modernize now, migrate later. NIST published its first three post-quantum standards on 13 August 2024: FIPS 203, 204 and 205 (ML-KEM, ML-DSA and SLH-DSA). Dustin Moody, the NIST mathematician who led the standardization project, was direct about the timeline: "We encourage system administrators to start integrating them into their systems immediately, because full integration will take time. There is no need to wait for future standards."

For email that urgency comes with a catch worth stating plainly: there is no standardized post-quantum DKIM. Post-quantum signatures are large, DKIM lives in size-constrained DNS records, and the IETF work to reconcile the two is still early. In a June 2026 IETF DKIM working-group thread on the post-quantum threat model, standards author John Levine put the core constraint plainly: "DKIM keys should be short in order to fit in UDP DNS packets, which means ideally they are only a few hundred octets" — exactly what a large post-quantum signature collides with. So "migrate DKIM to a quantum-safe algorithm" is not an action you can take in 2026. What you can do is the thing that makes any future migration possible — know what you run, and remove the weak classical crypto now. A domain still signing with 1024-bit RSA is not a distant quantum problem; it is under-strength today, by a 2013 NIST standard, and it is the first line item any crypto inventory should flag. Kill RSA-1024, move to 2048-bit or Ed25519, sign your zone, and you close a present-day gap while making yourself agility-ready for the migration that is genuinely coming — lead with the key you can fix Monday, not the quantum computer you cannot buy.

What should you do this week?

In order, cheapest first, and none of it requires waiting for post-quantum anything:

1. Inventory what your domain actually publishes. Resolve your DKIM selectors, DNSSEC, DANE, MTA-STS and BIMI, and read the algorithms and key sizes — not a pass/fail tick. Generate a CBOM for your domain does exactly this and exports it as CycloneDX so it opens in cbomkit's viewer alongside your source-scanned inventory.
2. Flag every RSA key under 2048 bits. A 1024-bit DKIM key is the highest-priority classical finding, and there is no reason to keep one.
3. Rotate the weak keys to 2048-bit RSA or Ed25519. Publish the new key alongside the old, switch signing, wait for in-transit mail to clear, then retire the old record; your provider's console does most of this.
4. Check the keys you no longer use, too. A stale, non-revoked 1024-bit selector from an old vendor is a live signing key an attacker can still exploit — revoke it with an empty p= or remove it.
5. Put the inventory somewhere it re-runs. Crypto posture drifts the way authentication posture does — a new sending vendor, a migrated platform, a contractor's DNS edit — so continuous monitoring catches the next weak key the day it appears.

If your inventory turns up a weak key you cannot explain — an old ESP's selector, a subdomain nobody remembers delegating — the root cause is usually organizational rather than technical. A platform migration rarely carries the crypto hygiene with it, and the same cutover is often where sending scales faster than the reputation behind it begins; underneath both sits the question of who actually owns whether your email lands. A key nobody owns is a key nobody rotates.

Free tools

All free, no signup:

• Cryptographic posture (CBOM) — inventory your email's crypto and export a CycloneDX 1.6 CBOM.
• Authentication audit — resolves SPF, DKIM and DMARC against the current specification.
• Header inspector — what the receiver actually concluded, not what your ESP reported.
• Blocklist check — whether your domain or IPs are on Spamhaus, Barracuda or SpamCop.
• DMARC policy simulator — preview none → quarantine → reject before you publish.
• List check — bounces, role accounts and stale segments before they meet a mailbox provider.
• Warmup readiness — whether a domain can absorb the volume you are about to send.
• Posture monitoring — catch silent drift the day it happens.
• Agent comprehension score — how a recipient AI agent reads your email before you send.

HireAmino builds free, no-signup tools for email deliverability, authentication and cryptographic posture. See them all at hireamino.com.

Key takeaways

• Brand crypto beats security crypto. Our scan found BIMI on 14 of 50 Fortune 50 domains, against DNSSEC, MTA-STS and DANE on 6, 2 and 0 — eight combined, versus fourteen for the logo.
• 40% of DKIM keys are 1024-bit RSA, below NIST's minimum for new signatures since the end of 2013, and 27 of 50 domains publish at least one.
• Zero Ed25519 keys appeared across 145 — the modern algorithm, standardized in RFC 8463 in 2018, has effectively no adoption at this tier.
• Email is the CBOM slice source scanners miss. cbomkit reads your code; DKIM keys, DANE records and a vendor's signing algorithm live in DNS and TLS.
• Post-quantum is real but not yet actionable for DKIM. There is no standardized PQC-DKIM, so the move today is to inventory and kill RSA-1024.

FAQ

Is RSA-1024 safe?

For digital signatures, no — not by current standards. A 1024-bit RSA key provides about 80 bits of security strength, and NIST's SP 800-131A disallowed signature keys below 112 bits (a 2048-bit RSA key) after 31 December 2013. DKIM's own RFC 8301 permits 1024 as a hard minimum but recommends at least 2048. Treat any 1024-bit signing key as a finding to remediate, not a configuration to keep.

How do I check my DKIM key length?

Resolve your DKIM selector's TXT record — selector._domainkey.yourdomain.com — read the p= value, base64-decode it, and inspect the RSA modulus, which is 1024 or 2048 bits. Because selectors are not enumerable from DNS you need to know or guess them, and email providers document theirs. A CBOM scan does the decoding and flags anything under 2048 automatically.

What is a CBOM?

A Cryptographic Bill of Materials is a structured inventory of the cryptographic assets a system uses — algorithms, keys, certificates and protocols — in a standard format. The dominant format is CycloneDX 1.6, released in April 2024, which added crypto-asset components developed by IBM Research. CBOMs exist because regulations like OMB M-23-02 now require organizations to inventory their cryptography ahead of the post-quantum migration.

Does post-quantum cryptography affect email?

Eventually, but not yet operationally. NIST published its first post-quantum standards, FIPS 203, 204 and 205, in August 2024, and TLS migration is underway. For DKIM specifically there is no standardized post-quantum signature — the algorithms are too large for DNS-based DKIM as it stands — so the actionable email task today is classical hygiene: inventory your keys and replace anything under 2048-bit RSA.

What's the difference between a CBOM and a source-code crypto scan?

A source or binary scan — the model behind PQCA's cbomkit — finds the cryptography your software depends on by reading your code. An observed CBOM finds the cryptography you actually expose on the network — DKIM keys in DNS, DANE and MTA-STS records, TLS on the mail edge — which a code scan cannot see because it is not in the codebase. For email, the observed half is where nearly all the crypto lives, so the two are complementary.

Sources

• IETF, RFC 8301 — Cryptographic Algorithm and Key Usage Update to DKIM — January 2018. "Signers MUST use RSA keys of at least 1024 bits… Signers SHOULD use RSA keys of at least 2048 bits"; rsa-sha1 deprecated.
• IETF, RFC 8463 — A New Cryptographic Signature Method for DKIM — September 2018. Adds the Ed25519-SHA256 signing algorithm to DKIM.
• NIST, SP 800-131A Rev. 2 — Transitioning the Use of Cryptographic Algorithms and Key Lengths — key lengths below 112 bits of security strength (2048-bit RSA) disallowed for generating signatures after 31 December 2013; 1024-bit RSA ≈ 80-bit strength.
• CycloneDX, CycloneDX v1.6 Released — CBOM and Attestations — April 2024; ratified as ECMA-424. Cryptography Bill of Materials developed by IBM Research.
• OMB, M-23-02 — Migrating to Post-Quantum Cryptography — 18 November 2022. Requires agencies to inventory active cryptographic systems and report quantum-vulnerable cryptography.
• NIST, NIST Releases First 3 Finalized Post-Quantum Encryption Standards — 13 August 2024. FIPS 203 (ML-KEM), 204 (ML-DSA), 205 (SLH-DSA); Dustin Moody quotation.
• Post-Quantum Cryptography Alliance (Linux Foundation), CBOMkit — open-source reference implementation for CycloneDX CBOM generation via source/binary scanning.
• IETF ietf-dkim working group, Re: PQC Threat Model statement — John Levine, 19 June 2026. On DKIM's DNS size constraint for post-quantum signatures: "DKIM keys should be short in order to fit in UDP DNS packets."
• Google Workspace Admin Help, Turn on DKIM to prevent email spoofing — DKIM key length is a manual admin choice at generation; 1024-bit remains a selectable option alongside the recommended 2048-bit.
• Fortune, Fortune 500 (2026 ranking) — the fifty largest US companies by revenue used as the sample frame.
• HireAmino measurement — the Fortune 50 (2026); each company's email cryptography (DKIM via common selectors, DNSSEC, DANE on MX, MTA-STS, BIMI) resolved over public DNS and HTTPS in July 2026, re-verified on the morning of publication. DKIM figures are a common-selector sample, not a census. Raw records retained.