DKIM 1024 vs 2048 Bit: How to Check Which Key Your Domain Is Actually Using

The DKIM standard sets a floor of 1024 bits and recommends 2048, and the only way to know which one your domain uses is to measure the key that is published. The source is RFC 8301, "Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM)", published in January 2018. Section 3.2 says three things, which we read in full for this post on 9 November 2026: signers must use RSA keys of at least 1024 bits, signers should use RSA keys of at least 2048 bits, and verifiers must not consider signatures using RSA keys of less than 1024 bits as valid.

The free DKIM key length checker takes the TXT record, decodes the public key and tells you the size in bits, with a plain verdict: under 1024, meets the minimum, or meets the recommendation. This post explains what the verdicts mean and what to do about each.

Check a DKIM record →

What the three verdicts mean

Key size	What RFC 8301 section 3.2 says	What to do
Under 1024 bits	Verifiers must not treat signatures as valid	Replace it now. Treat mail as unsigned until you do.
1024 bits	Meets the signer minimum	Works, but plan the move to 2048.
2048 bits or more	Meets the recommendation	Nothing to change for size.

The first row is the urgent one. A very short key is not "less secure but fine." A receiver that follows the standard discards the signature as invalid, so your DKIM pass is gone and any DMARC policy that relies on DKIM alignment loses that leg.

Why you cannot tell by eye

The public key sits in the p tag of the record, base64 encoded, and nothing in the record states the bit length. A longer string suggests a longer key, but "longer" is relative to how the key was exported and padded. The checker reads the actual structure of the key and measures the modulus, which is the number that defines the size.

It also catches things a glance would miss. RFC 6376, section 3.6.1, says an empty p tag means the key has been revoked, and that the t=y flag means the domain is testing DKIM. The checker reports both. It measures RSA keys only; if the k tag names another key type it says so rather than guessing.

Your sending service's dashboard is not the source of truth

Services tell you what they generated. The published record is what receivers read. They can differ for ordinary reasons:

• You generated a new key but never replaced the old record at the same selector.
• A teammate published a 1024-bit key years ago and the dashboard now offers 2048 for new setups only.
• A DNS migration copied an old zone file. The audit tool described in multiple SPF records and the zone file email audit reads every DKIM record in a pasted zone and reports the size of each.
• Several services sign for the same domain on different selectors, each with its own key.

For that last case, DKIM for every sending service lists how to keep track of which selector belongs to which service. Check each selector separately.

How to look up the record

You need the selector, which your sending service shows you or which appears in the s= tag of a DKIM-Signature header on any message you sent. The record is a TXT record at selector._domainkey.yourdomain.com. How to look up a domain's TXT records walks through it. Copy the value, quotes and all. The checker accepts it quoted or unquoted, and joins split strings the way a receiver would.

Moving from 1024 to 2048

Do it with a new selector so nothing breaks while DNS caches catch up.

1. Generate a 2048-bit key in your sending service, under a new selector name.
2. Publish it. A 2048-bit record is longer than 255 octets, so it has to be published as several strings in one record. If your DNS host rejects it, DKIM TXT record too long explains the split and the TXT splitter does it for you.
3. Check it. Paste the live record into the checker and confirm it reports 2048 bits.
4. Switch signing to the new selector in the sending service.
5. Wait for mail already in transit to be delivered, then remove the old selector's record. Our post on DKIM key rotation goes into timing.
6. Send a test and read the authentication result in the headers.

Provider-specific steps are in the Google Workspace and Microsoft 365 DKIM setup posts.

What key size does not do

A strong key makes a signature hard to forge. It does not decide whether a message is wanted, and it does not know whether the recipient address exists. We will not tell you a 2048-bit key improves inbox placement; no source we have read promises that. What the standard supports is narrower and still worth doing: a longer key keeps you above the line the standard sets for your signatures to count.

The part of deliverability that you control every campaign is the list. A domain with perfect DKIM, SPF and DMARC still gets bounces from addresses that do not exist, and receivers measure those. Authentication is a one-time job; list hygiene is a recurring one. Bounce rate thresholds by platform shows what the sending platforms say about their own limits.

The routine before a new domain or a key change

1. Measure every DKIM selector with the checker.
2. Fix anything under 2048 when your service allows it, and anything under 1024 immediately.
3. Validate your DMARC record with the DMARC record validator.
4. Verify the list at /verify and suppress invalid addresses.
5. Send valid rows first and risky rows slowly after.

Try it on your own list

Upload a sample at /verify. The first 100 checks are free with a Google sign-in, no card.

Pro, $39 a month: Unlimited email verification.* Never metered, never cut off. See pricing.

*Fair use: the first 100,000 checks a month at full speed, then slower, never cut off.