Your email is signed with a key attackers can forge

Every message your domain sends carries a small cryptographic signature that says, in effect, “this really came from us.” That’s DKIM — DomainKeys Identified Mail — and the signature is made with a private key that lives on your mail platform, checked against a public key you published in your DNS years ago. When you set it up, you almost certainly took the default the provider offered at the time, watched a test message pass, and never looked at it again. That was the right thing to do. It just aged badly.

Because the default, for a long time, was a 1024-bit key. That length still works — it’s long enough to produce a valid signature that sails through authentication — but it now sits below the 2048-bit strength the major mailbox providers expect. A key that short is far cheaper for a well-resourced attacker to attack directly, and the whole point of the signature is that only you can produce it. If someone can forge it, they can send mail that your own domain vouches for: convincing invoices, believable requests to change bank details, phishing that passes every check a cautious recipient’s system runs.

This is the quiet failure. Your email flows perfectly. Signatures pass. Nothing looks wrong — which is exactly why nobody looks. The record quietly slipped below standard while you were busy, and a signature nobody should fully trust is still standing in for you.

Why it stays invisible

DKIM is a set-and-forget record by design, and that’s its weakness. Once it’s published and passing, there’s no alarm that fires when the recommended strength moves on beneath it. The key doesn’t expire. The provider that generated it years ago doesn’t retroactively upgrade it. Deliverability doesn’t obviously suffer at first, so nothing prompts you to revisit it.

Meanwhile the goalposts moved. Google’s sender rules — enforced for bulk senders since 2024 — set 1024 bits as the bare minimum for DKIM and recommend 2048 outright, and Microsoft 365 supports 2048-bit keys and will rotate you up to one. However, a recommendation is not a switch-off — a 1024-bit signature generally still validates, so your mail keeps flowing and you get no error to investigate. The gap between “still works” and “still safe” is precisely where quiet failures live.

Find it yourself

You can read your own key length in about ten minutes. You need to know one thing first: your selector — a short label that points to the right key, because a domain can publish several. Common ones are google, selector1, s1, default, or k1. You’ll find the exact one in a header of any recent message you sent (look for d=yourdomain.com; s=... in the DKIM-Signature line) or in your mail provider’s DKIM settings.

Then, the no-command-line way:

1. Go to a DKIM lookup tool such as MXToolbox (mxtoolbox.com/dkim.aspx).
2. Enter your domain and your selector.
3. It returns the published key record. Some checkers state the key length — 1024 or 2048 bits — directly in the result; if yours doesn’t, the length of the p= value gives it away, as below.

If you’re comfortable at a terminal, you can ask DNS yourself:

dig TXT selector._domainkey.yourdomain.com +short

Replace selector with yours. The record includes a long p= value — the public key itself. A 1024-bit key’s p= is roughly 216 characters of base64; a 2048-bit key is noticeably longer, around 392 or more. If it’s the shorter one, you’ve found it.

The fix

Good looks like a 2048-bit DKIM key, generated fresh, signing your mail — and the old short one retired. The good news is you don’t do this at the DNS level by hand: your mail platform generates the new key pair for you and tells you the DNS record to publish.

The exact steps depend on your provider, but the shape is the same everywhere. In Google Workspace, go to Apps → Google Workspace → Gmail → Authenticate email, generate a new record choosing 2048-bit, publish the TXT record it gives you, and then switch signing over to the new key. In Microsoft 365, DKIM lives on the Email authentication settings page of the Defender portal (under Policies & rules → Threat policies), where each domain has a Rotate DKIM keys option — though at the time of writing, asking for the larger 2048-bit size means running the one-line PowerShell command Microsoft’s documentation gives for it. Admin menus do get reshuffled, so if a label has moved, search the console for “DKIM”. Give DNS an hour or two to propagate before you enable it, then send yourself a test message and confirm it passes.

To stop it silently ageing again, treat DKIM keys the way you’d treat any credential: rotate them on a schedule rather than never. Once a year is a sensible rhythm, and it doubles as the moment you re-check the key length against whatever the current standard has become. It’s a ten-minute job that keeps your domain’s signature worth trusting — which, given the signature exists so that others trust you, is the whole point.