How to quickly identify DKIM key length (1024 or 2048)?
Published 11 Jun 2025
Updated 10 Oct 2026
13 min read
Summarize with
Updated on 10 Oct 2026: We clarified RSA key-length checks, DNS TXT splitting, and verification after DKIM key rotation.
For an RSA DKIM record, the quickest reliable check is to read the RSA modulus size. Extract the p= value from DNS, wrap it as a PEM public key, run OpenSSL, and read the first line. Typical output is Public-Key: followed by (1024 bit) or (2048 bit). The bit count is the length of the RSA key itself.
For a fast browser check, Suped's DKIM checker parses the record without requiring a command. For a terminal check, OpenSSL is the most direct route because it reports the bit length from the decoded public key.
- Reliable check: Decode the RSA DKIM public key and read the modulus length.
- Good shortcut: A 1024-bit RSA DKIM key often has a p= value near 216 base64 characters, and a 2048-bit key often sits near 392.
- Main caveat: DNS quoting, whitespace, and record formatting make visual length a hint, not proof.
How RSA DKIM key length is measured
A DKIM DNS record stores the public key in the p= tag. For RSA DKIM keys, the key length is the size of the RSA modulus. A real key-size check therefore has to decode the public key and inspect the modulus. Anything based only on the number of visible characters is a guess.
The practical rule
If OpenSSL says Public-Key: (2048 bit), it is a 2048-bit RSA DKIM key. If it says Public-Key: (1024 bit), it is a 1024-bit RSA DKIM key. That is the positive identification.
The selector name does not prove the key size. A selector called selector2048 can still point to a 1024-bit key if someone copied the wrong record. The DNS record has the answer, so treat names, comments, and internal notes as hints only.
First check the key type. A missing k= tag defaults to RSA, and k=rsa confirms RSA. A record with k=ed25519 has a 256-bit Ed25519 public key, so the 1024-bit versus 2048-bit RSA labels do not apply. Its shorter p= value is expected: a 32-byte public key encodes to 44 base64 characters. RSA and Ed25519 bit counts are not directly comparable measures of security.
|
|
|
|
|---|---|---|---|
OpenSSL | Terminal checks | High | Needs clean key |
Browser checks | High | One record | |
Base64 count | First pass | Medium | Only a hint |
Selector name | None | Low | Can mislead |
Quick ways to identify RSA DKIM key length
How to check an RSA key with OpenSSL
Start with the selector and signing domain. You get them from the message's DKIM-Signature header. The selector is the s= value and the signing domain is the d= value. The DNS lookup name is the selector, then ._domainkey., then the signing domain.
Use a recently sent message to identify the selector currently used by your sender. If it has multiple DKIM-Signature headers, check each signature separately. The a=rsa-sha256 tag names the signing algorithm, not the RSA key size. The b= value is the signature and bh= is the body hash; measure the DNS p= public key instead.
Look up the DKIM TXT recordBASH
dig +short TXT selector1._domainkey.example.com
On Windows, nslookup -type=TXT selector1._domainkey.example.com retrieves the same DNS record. The OpenSSL commands require OpenSSL to be installed.
If the selector name is a CNAME, follow it to the TXT record. A CNAME target is a hostname, not key material. Copy only the public-key material after p=. Stop at the next semicolon, then remove DNS quotes, spaces, and line wrapping. Use the complete value, replacing the abbreviated example below. Only the public key is needed for this check; keep the private signing key on the sending system. Wrap the cleaned value in a PEM public-key block.
Wrap the DNS p value and inspect itBASH
KEY='MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...' { echo '-----BEGIN PUBLIC KEY-----' echo "$KEY" | fold -w 64 echo '-----END PUBLIC KEY-----' } > dkim-public.pem openssl rsa -inform PEM -pubin -in dkim-public.pem -text -noout | head -1
Expected output
Public-Key: (2048 bit)
That output gives the key length directly. Some OpenSSL versions print "RSA Public-Key" instead; read the bit count in parentheses. The algorithm-independent pkey command also reads the RSA public key:
OpenSSL pkey alternativeBASH
openssl pkey -pubin -in dkim-public.pem -text -noout | head -1
Apple Terminal displaying OpenSSL's 2048-bit RSA DKIM public-key result.
If OpenSSL rejects the key
- Check extraction: Make sure the value starts after p= and does not include other DKIM tags.
- Check wrapping: Use -----BEGIN PUBLIC KEY----- and -----END PUBLIC KEY----- PEM boundaries, matching the example above.
- Check TXT layout: Join quoted strings from one TXT record without spaces. Multiple separate TXT records at one selector make the result undefined and need to be fixed.
- Check revocation: An empty p= value means the selector is revoked, not that it has a zero-length key.
Fetch and check an RSA DKIM key
Run this Bash snippet after replacing the selector hostname. It keeps only quoted TXT answers, requires exactly one record, checks that the key type is RSA, and extracts one nonempty p= value. It decodes the DER public key and asks OpenSSL for the modulus size without creating a PEM file. This is a key-length check, not a complete DKIM record or message-signature validator.
Fetch and inspect an RSA DKIM keyBASH
( set -o pipefail QUERY='selector1._domainkey.example.com' TXT=$(dig +short TXT "$QUERY" | sed -n '/^"/p') || exit 1 if [ -z "$TXT" ] || [ "$(printf '%s\n' "$TXT" | wc -l)" -ne 1 ]; then printf '%s\n' 'Expected one TXT record; check DNS first.' >&2 exit 1 fi RECORD=$(printf '%s' "$TXT" | tr -d '"[:space:]') KEY_TYPE=$(printf '%s' "$RECORD" | tr ';' '\n' | sed -n 's/^k=//p') if [ -n "$KEY_TYPE" ] && [ "$KEY_TYPE" != 'rsa' ]; then printf '%s\n' 'This check requires an RSA key.' >&2 exit 1 fi KEY=$(printf '%s' "$RECORD" | tr ';' '\n' | sed -n 's/^p=//p') KEY_COUNT=$(printf '%s\n' "$RECORD" | tr ';' '\n' | sed -n '/^p=/p' | wc -l) if [ -z "$KEY" ] || [ "$KEY_COUNT" -ne 1 ]; then printf '%s\n' 'Expected one nonempty p= tag; check for revocation or malformed DNS.' >&2 exit 1 fi printf '%s' "$KEY" | openssl base64 -d -A | openssl rsa -pubin -inform DER -text -noout | sed -n '1p' )
If the command cannot read the key
- Multiple TXT records: Fix the selector so it returns one DKIM key record before measuring it.
- Empty public key: An empty p= value is a revoked key and cannot be measured.
- Ed25519 key: Use an algorithm-aware DKIM parser because the RSA modulus test does not apply.
- Missing utilities: Use the manual PEM method if the record is already available; otherwise use Suped's checker when dig, sed, or tr is unavailable.
How to estimate DKIM key length by sight
A visual estimate is still useful when triaging lots of records. A 1024-bit RSA DKIM key usually looks much shorter than a 2048-bit key. After removing quotes and spaces, the public-key part of a 1024-bit DKIM record often lands around 216 base64 characters. A 2048-bit key often lands around 392.
RSA DKIM key-length thresholds
Use the modulus size for the decision, then use visible length only as a quick hint.
1024-bit
Warning
Legacy RSA key size. Plan replacement when possible.
2048-bit
Good
Practical RSA default for most DKIM deployments.
4096-bit
Verify
Less common. Confirm DNS publication and response size.
Use character counts only as a hint. Public-key encoding and the RSA exponent also affect the base64 length, even after quotes and whitespace are removed. TXT splitting and control-panel wrapping add further visual differences; decoding the key gives the actual modulus size.
Good quick signals
- Record length: A much longer p= value points toward 2048-bit RSA.
- Count only the key: Exclude DKIM tags and DNS quotes when estimating the base64 length.
- Tool parse: A parser that reads the modulus gives a direct answer.
Signals not to trust
- Selector names: Names can say 2048 even when DNS points to a 1024-bit key.
- Control panels: Labels and UI text can lag behind a real DNS change.
- Line count: TXT wrapping changes how many lines a key appears to occupy.
Why a 2048-bit DKIM key needs TXT splitting
Each DNS TXT character-string holds at most 255 bytes. A typical 2048-bit RSA public key has about 392 base64 characters before DKIM tags, so it needs multiple strings within one TXT record. The 255-byte limit applies to each string, not to the complete TXT record.
Illustrative DNS zone-file syntax, not a usable public keyDNS
selector1._domainkey.example.com. IN TXT ( "v=DKIM1; k=rsa; p=FIRST_PART_OF_THE_PUBLIC_KEY" "REMAINING_PART_OF_THE_PUBLIC_KEY" )
Replace the placeholders with consecutive parts of the complete key, keeping each quoted string within 255 bytes. RFC 6376 requires the strings in one TXT record to be joined without added whitespace. Do not create separate TXT records for the key parts.
Many DNS control panels split a long value automatically. If yours accepts the complete value, paste it once and let the provider handle splitting; add manual quotes only when its instructions require them. After saving, query public DNS and confirm that the reconstructed p= value matches the original key. A string-length error calls for correct TXT splitting rather than truncating the key or reducing it to 1024 bits.
Check DKIM key length in Suped
For a browser check, enter the signing domain and selector in Suped's DKIM checker, then read the parsed public-key length and DNS validation status. Suped's checker also checks record syntax; it follows provider CNAMEs to the published TXT key.
DKIM checker sample results showing selector, DKIM DNS record, validation checks, parameters, and share link
A 2048-bit key does not prove that a message passes DKIM. The record can be malformed or truncated, and a sender can sign with the wrong selector or a private key that does not match DNS. Validate the full record, then send a test message and inspect the receiving server's Authentication-Results header for dkim=pass on the expected signing domain and selector.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
If you are reviewing a full sending domain rather than one selector, use a broader domain health check so DKIM is checked alongside SPF and DMARC. Key length matters, but DKIM issues often sit alongside SPF or DMARC configuration errors. A good review checks the whole authentication chain.
What to do when you find a 1024-bit key
A 1024-bit RSA key can still validate. RFC 8301 requires at least 1024 bits for RSA DKIM signing and recommends at least 2048 bits. Receivers reject RSA signatures with keys below 1024 bits, and receiver policies can also reject a 1024-bit key. A larger RSA key strengthens the digital signature; DKIM does not encrypt message content or guarantee inbox placement. Treat a 1024-bit result as planned migration work: create a new selector, publish the new public key, start signing with the new private key, confirm passing authentication, then retire the old selector after mail signed with it has aged out.
DKIM key rotation flowchart: check key size, create a selector, publish DNS, sign email, retire the old key.
Do not overwrite a working selector unless the mail system forces that workflow. A new selector gives you a clean rollback path. It also lets DNS propagate before production mail depends on the new key. For more detail on sizing tradeoffs, compare 1024 vs 2048 and plan key changes with a normal rotation cadence.
- Create first: Generate or enable a new 2048-bit selector before touching the old one.
- Publish DNS: Add the new TXT record and confirm the complete key resolves from public DNS before switching signing. Account for the DNS TTL, including cached negative answers for a previously missing selector.
- Switch signing: Update the mail system to sign with the new selector.
- Verify results: Send real mail and confirm dkim=pass for the new selector, plus dmarc=pass. A DMARC pass through SPF alone does not prove the new DKIM key works.
- Retire later: Keep the old public key published until messages signed with it have cleared your mail system's queue and retry windows, then remove it. There is no universal 48-hour retirement period.
Monitor authentication after a DKIM key change
OpenSSL or a DNS checker measures the published RSA key length. DMARC reports show which sending sources pass or fail authentication and whether those results change after a key rotation. Reports do not contain the RSA modulus size, so use a DNS key check to establish it.
Suped is our DMARC reporting and email authentication platform. In this workflow, it connects DKIM diagnostics with DMARC monitoring and issue alerts, then tracks authentication results across domains after a selector rotation.
A sensible operating model
- One-off proof: Use OpenSSL or a checker to read the key length directly.
- Domain review: Check DKIM, SPF, and DMARC together before changing production mail.
- Ongoing control: Monitor reports and alerts so future key, DNS, or source changes do not go unnoticed.
A valid 2048-bit DNS key still leaves message-level checks: the sender must use the matching private key, signed content must survive delivery, and receivers must resolve the correct public key. A passing DKIM signature counts toward DMARC only when its d= domain matches the visible From domain under DMARC domain-matching rules. A domain mismatch affects DMARC, not the cryptographic DKIM result.
Views from the trenches
Best practices
Strip DNS quotes and spaces before testing, because TXT chunking changes visible length.
Use the public key modulus, not selector naming, when a positive size answer matters.
Keep the selector query in a small script so repeat checks take seconds per domain.
Common pitfalls
Counting characters works only as a hint because PEM wrapping and DNS chunks add noise.
Treating a 2048-looking key as valid without checking DKIM syntax misses broken records.
Rotating the key before confirming both selectors are live creates avoidable signing gaps.
Expert tips
OpenSSL prints the key size directly when the DNS p value is wrapped as a public key.
Save the extracted key in a temporary file and delete it after the verification run.
Pair one-off checks with monitoring so downgraded or broken DKIM records get noticed.
Expert view
Expert from Email Geeks says a small script is the fastest route when the same key-size check needs to run across many domains.
2024-11-06 - Email Geeks
Marketer view
Marketer from Email Geeks says browser-based lookup is fine for a one-off check, but repeat work needs a repeatable method.
2024-11-06 - Email Geeks
Frequently asked questions
You can estimate it, but the reliable answer comes from reading the decoded RSA modulus. Remove DNS quotes and whitespace first. Typical base64 p= lengths are about 216 characters for 1024-bit RSA and 392 for 2048-bit RSA; encoding details can change those counts.
A 1024-bit RSA key meets the minimum in RFC 8301, but the standard recommends at least 2048 bits and receivers can apply stricter policies. Plan the upgrade with a new selector and retain the old public key until queued messages have cleared.
No. A selector name is only a lookup label. It can include 1024, 2048, a date, a provider name, or a random string. The DNS p value decides the actual key size.
Look for a first line such as Public-Key: (2048 bit) or Public-Key: (1024 bit). Some versions print RSA Public-Key instead. The number in parentheses is the decoded RSA modulus size.
For RSA DKIM, 2048-bit is the practical default for most domains. Publish long keys as multiple strings within one TXT record, then verify both the complete DNS value and a real message signed with that selector.
No. Ed25519 DKIM records use k=ed25519 and a 32-byte (256-bit) public key, encoded as 44 base64 characters. RSA modulus measurements do not apply, and raw bit counts are not comparable across these algorithms.
