Your DKIM key is published in DNS. How many bits is it?

You set up SPF. You moved DMARC to p=reject. You added DKIM, watched the test mail go green, and never looked at it again. Here's the part nobody checks: the DKIM public key is sitting in a DNS TXT record right now, anyone can read it, and its size decides whether the whole thing is real protection or theater.

DKIM works by signing outbound mail with a private key and publishing the matching public key in DNS, so receivers can verify the signature came from you. The security rests entirely on the size of that key. RSA at 2048 bits is fine. RSA at 512 bits has been factored on rented cloud hardware in hours, for less than the price of lunch. And a factored key is a forged signature, which means an attacker signs mail as your domain that passes DKIM, passes your DMARC p=reject, and lands in the inbox looking exactly like you.

Why short keys are still out there

Nobody chooses a 512-bit key on purpose in 2026. They inherit one. A selector set up a decade ago on an old mail appliance, a default from a budget host that never got revisited, a migration that copied the DNS record across without regenerating the key. The mail still flows, the signatures still verify on most receivers, so there's no error to notice. The key just quietly does less than you think it does.

RFC 8301 is blunt about it: verifiers must not treat a signature from a key below 1024 bits as valid. So a sub-1024 key is in a bad spot either way. Strict receivers reject it outright, which means your DKIM is silently broken and you're leaning on SPF and DMARC alignment alone. Lax receivers accept it, which means it's forgeable. There's no version of "small key" that's working as intended.

What a stranger does with a key they can factor

The attack is not subtle once the key is small enough. Pull the public key from your DNS, factor the modulus to recover the private key, then sign anything you like with it. The signature is mathematically valid, so it satisfies DKIM. If that signature aligns with your From: domain, it satisfies DMARC too, including p=reject, the policy you stood up specifically to stop this.

This is the part that makes a weak key worse than a missing one. A domain with no DKIM at all forces an attacker to rely on alignment tricks that DMARC is built to catch. A domain with a factored DKIM key hands the attacker a signature that everything you set up treats as genuine. Your customers get an invoice with new bank details, from your address, past every filter, and the first you hear of it is the chargeback.

A second, quieter case shows up the same way: a key that's been revoked. DKIM lets you publish an empty p= to mark a key dead, but the record often gets left in DNS long after the selector is retired. It's not forgeable, but it's a loose end, usually the fingerprint of a mail provider you stopped using and a record nobody cleaned up.

The fix is a bigger key, published cleanly

Generate a new key at 2048 bits, publish it at a fresh selector, switch your mail flow to sign with it, and only then remove the old record. Rotating through a new selector instead of overwriting the old one means mail in flight still verifies during the cutover.

; old selector, factorable key
old._domainkey  TXT  "v=DKIM1; k=rsa; p=MIGfMA0G...512-bit..."

If your provider manages DKIM for you (Google Workspace, Microsoft 365, most ESPs), the modern default they hand out is 2048-bit, so the fix is usually "regenerate the key in the admin console and update the published record." The keys that are weak are almost always the ones a human set up by hand years ago and forgot.

Reading it from outside

The key's size is a published fact: it's in the p= value of a DNS TXT record, the same record receivers read on every message. SurfaceCheckr resolves the well-known selectors your provider uses, decodes the key, and measures its real modulus, so a weak or revoked one shows up without you logging into anything. We only read the published record and do the math; an Ed25519 key is left alone, since 256 bits is correct for that algorithm, not weak. This is the email-side twin of reading your TLS certificate's key strength: same idea, a key whose size you can check from outside, except this one decides whether your SPF and DMARC setup is actually holding the line.