DKIM key audit
strength + rotation.
Enter your domain and the DKIM selector. We fetch the DKIM TXT record, decode the public key, identify the algorithm and key length, and flag weak configurations: 1024-bit RSA (deprecated, downgraded by Gmail), sha1 signing (insecure), missing or revoked keys.
# Awaiting input…
Key length, algorithm, rotation status, syntax.
2048-bit is the modern bar
Until ~2017, 1024-bit was standard. Today, Gmail flags 1024-bit keys as weak and downgrades the signal. Microsoft treats 1024-bit signatures as "authenticated but low confidence". Production sending needs 2048-bit minimum.
rsa-sha256 only
DKIM supports rsa-sha1 and rsa-sha256. Modern receivers either downgrade or reject sha1 signatures outright. New deployments should use rsa-sha256; existing sha1 keys should be rotated.
Quarterly is the standard
Production keys should rotate quarterly. New selector
(e.g. 2026q2), new key, 14-day overlap, retire old.
Same key in place for years isn't a security catastrophe but
signals operational neglect.
Syntax-level checks
Valid v=DKIM1, k=rsa, p=
with base64 key. We verify the record parses cleanly, the key
decodes, and the modulus length matches what the record claims.
Concatenation correctness
2048-bit keys exceed the 255-byte single-string TXT limit and are published as multiple strings. We verify the strings concatenate correctly and that no bytes are missing or duplicated.
Empty p= detection
A DKIM record with p= and nothing after means the key
is revoked. If you see this on an active selector, your sending
stack should rotate to a new selector immediately.
We rotate DKIM keys quarterly for every customer.
2048-bit RSA, rsa-sha256, quarterly rotation with 14-day overlap, alignment verified per receiver. Standard configuration on every sending domain we provision. If you're auditing mediocre DKIM on existing infrastructure, it's worth a conversation.
Three signals matter most: key length, algorithm, selector hygiene.
The audit returns a per-selector breakdown. Each selector shows the algorithm in use (almost always RSA in practice; Ed25519 exists in the spec but is rare in deployment), the key length in bits, and any flags the record carries (testing flag, granularity, service type). Three of these signals matter most for your daily deliverability; the rest are mostly informational.
Key length: 2048 is the new floor.
1024-bit RSA keys still pass at every major receiver, but they're on the deprecation list. Yahoo has been signalling publicly since 2023 that lower-trust scoring would apply to 1024-bit keys; some smaller European receivers have already begun applying it. 768-bit keys (still found in the wild on legacy systems) may be ignored entirely; the signature is treated as if absent. 4096-bit keys are theoretically stronger but DNS responses can exceed 512 bytes and require TCP fallback; 2048 is the practical sweet spot.
If the audit shows 1024-bit keys on your active selectors, schedule rotation to 2048-bit. Don't rotate same-day; use a 14-day overlap period where both old and new selectors are valid in DNS, so in-flight mail signed with the old key continues to verify until it clears the queue.
Selector freshness: how long has the same key been signing?
DKIM keys don't expire automatically; if you don't rotate them, they sign indefinitely. This becomes a problem gradually. If a private key leaks (rare but possible through misconfigured backups, repository exposure, or insider access), an attacker can sign mail as you until you rotate. Receivers also weight signature age in their internal trust scoring; selectors signing for years with no rotation are slightly more suspect than rotating selectors.
Industry best practice is quarterly rotation. The audit flags selectors that appear to have been in use for 12+ months without rotation; this is heuristic (we infer from selector naming patterns and TTL behaviour) and should be treated as a hint, not a definitive finding. Six-month rotation is acceptable for lower-volume operations.
Selector availability: which selectors are actually used?
The audit checks selectors common in the wild. A missing
selector is not necessarily a problem; it just means that
selector isn't being used to sign your mail. Failures
appear when a selector record exists but is malformed:
broken base64 in the public key, missing p=
tag, unsupported algorithm declared. These are real
failures; if a malformed selector is signing your mail,
receivers can't verify the signature and DKIM is treated
as failed.
What we see most often when auditing real domains.
1024-bit RSA key on production selector
Most common finding. Still passes at major receivers but lower-trust scoring is active at some. Fix: rotate to 2048-bit with 14-day overlap. We provide DKIM rotation as a managed service if you want this handled without engineering time.
Selector unchanged for 18+ months
Long-lived selectors increase exposure window if a key ever leaks and reduce trust scoring at some receivers. Fix: implement quarterly rotation cadence. Standard rotation pattern: generate new key, publish new selector DNS record, switch signing to new selector, retain old selector for 14 days, remove old selector DNS record.
Selector exists but public key is malformed
DNS record contains a v=DKIM1 tag but the
p= tag is empty, truncated, or contains
invalid base64. Mail signed with this selector cannot
be verified; receivers treat the signature as failed.
Fix: regenerate the keypair, republish the public key
in DNS, ensure the record fits within DNS string limits
(255 chars per string, multiple strings concatenated).
Testing flag (t=y) still set on production selector
The t=y flag tells receivers to treat the
signature as in-test; verification failures should not
penalize the message. Useful during initial DKIM
deployment; harmful if left enabled long-term because
it weakens the protection DKIM provides. Fix: remove
the t=y flag once you've confirmed
signing works correctly.
Multiple TXT records at same selector
DNS allows multiple TXT records at the same name, but DKIM expects exactly one. Most receivers will pick the first; some will fail verification entirely. Common cause: leftover record from a prior key after rotation wasn't cleaned up. Fix: identify which record is current, delete the others.
Key shared across multiple sending services
Some operations use the same DKIM keypair across multiple ESPs to simplify rotation. Not strictly wrong but reduces diagnostic value: if one service has a problem, you can't isolate it via signature analysis. Best practice: separate selectors per sending service, different keys per selector.
The rotation cadence that satisfies 2026 receiver expectations.
DKIM keys should rotate. The receiver-side expectation in 2026 is quarterly rotation for high-volume senders and at minimum annual rotation for low-volume senders. Static keys that have been published unchanged for years accumulate negative signal because they make the sender look like either an abandoned configuration or an attacker-controlled domain that the legitimate owner has lost access to.
The mechanical pattern for rotation: generate a new
keypair, publish the public key as a new selector
(selectors are arbitrary strings, but convention is
something like k2026q3 for "Q3 2026"),
configure the MTA to sign with the new selector, verify
via the audit tool on this page that the new selector
produces valid signatures, then leave the old selector
published for 7-14 days while in-flight mail continues
to verify against it, finally remove the old selector
from DNS once the transition period completes.
For high-volume senders the rotation cadence we recommend is quarterly (every 90 days) with rotation events deliberately staggered across sending domains so that rotation operations do not coincide. Concentrated rotation across multiple domains in a short window can look suspicious to receiver-side anomaly detection; staggered rotation across the calendar quarter produces a smoother signal pattern.
For low-volume senders annual rotation is the practical minimum. The structural reasoning is that quarterly rotation overhead is meaningful for operators managing dozens of sending domains and trivial for operators managing one; the receiver signal value of rotation is stronger for high-volume senders where receivers see consistent volume and can detect the rotation event. Low-volume senders gain less signal from frequent rotation but should still rotate at least annually to avoid the static-configuration negative signal.
Why 1024-bit keys are deprecated and where they still appear.
The DKIM specification (RFC 6376) originally allowed key sizes from 512 bits up to 2048 bits, with 1024-bit presented as the practical default for the early deployment era. Through 2010-2018 most DKIM deployments used 1024-bit keys; the keys were considered cryptographically adequate against the threat models of the time and the DNS TXT record size limits (255 bytes per string, with multi-string concatenation for longer records) made 1024-bit keys easier to publish than 2048-bit.
The shift to 2048-bit as the modern default happened progressively through 2017-2022. Major mailbox providers updated their guidance to recommend 2048-bit; new deployments increasingly defaulted to 2048-bit; older deployments that had set up 1024-bit and never rotated stayed on 1024-bit. By 2024 the receiver-side weighting had shifted enough that 1024-bit produced measurable deliverability penalty compared to 2048-bit.
In 2026 Gmail downgrades the DKIM signal weight for 1024-bit keys. Microsoft treats them as low-confidence. Some enterprise gateways reject them outright. The continued presence of 1024-bit keys in production is almost always a legacy artefact rather than a deliberate choice; operators who set up DKIM in 2015-2018 and never rotated still run 1024-bit keys unless they have since gone through a rotation cycle that updated the key size.
The audit tool on this page flags 1024-bit keys as deprecated and recommends migration to 2048-bit. The migration follows the standard rotation procedure: generate a new 2048-bit keypair, publish under a new selector, transition signing to the new selector, remove the old 1024-bit selector after the transition window. Operators concerned about DNS record size limits can use the standard multi-string TXT record encoding that handles 2048-bit keys correctly across all modern DNS providers; the size constraint that drove 1024-bit adoption in 2010 has not been a real constraint since 2018.
Future-looking note: cryptographic guidance is starting to discuss post-quantum migration paths for DKIM, with Ed25519 signatures and eventual post-quantum algorithms on the horizon. Ed25519 DKIM (RFC 8463) is supported by most major receivers as of 2024 but adoption is still minimal in production. Operators rotating to 2048-bit today are making the right choice for 2026-2028 conditions; the post-quantum migration question can wait for industry consensus on which post-quantum algorithm to adopt.
Frequently asked.
Does this tool see my private key?
No. The audit reads only public DNS records. Your private key never leaves your signing infrastructure and is not visible to anyone except your sending system. The audit verifies the public key's properties (length, algorithm, format) which are necessarily published in DNS.
How do I rotate DKIM keys without breaking mail in flight?
Standard pattern: generate the new keypair, publish the new selector's public key in DNS, configure your signing infrastructure to start signing with the new selector (typically a configuration change without service restart), wait 14 days, then remove the old selector's DNS record. The 14-day overlap covers in-flight mail signed with the old key but not yet delivered, plus mail in retry queues.
What's the difference between sub-domain and apex DKIM signing?
DKIM signing is per-message and includes the signing
domain in the d= tag. You can sign messages
with the apex domain (d=example.com) or a
subdomain (d=mail.example.com). For DMARC
alignment, the signing domain must align with the From:
header domain (or its organizational domain). Most
production setups sign with apex for clean alignment;
subdomain signing is used when different sending
services need separation.
Should I publish DKIM records for selectors I don't use?
No. Don't publish records for unused selectors. Each selector record is a potential surface for confusion (which selector is current?) and rotation hygiene failure (forgotten rotations on old selectors). If you have legacy selectors that aren't in use, remove them.
My ESP sets up DKIM automatically. Do I still need to audit?
Yes. ESPs configure DKIM correctly when initially provisioned, but configuration drift happens. Selectors that were 2048-bit at setup may have been replaced with 1024-bit during ESP infrastructure changes. Rotation cadence varies by ESP; some rotate quarterly, some not at all. Quarterly self-audit catches drift; the information is in DNS regardless of who sets up the signing.