SPF/DMARC/DKIM Checker
Inspect a selector’s published DKIM key, syntax and warnings alongside the domain’s SPF and DMARC policy.
Email SecurityDKIM Key Rotation Without Breaking Mail
A DKIM key is easy to publish and easy to forget. Reliable rotation is an overlap protocol: introduce a new selector, prove that real mail uses it, retain the old public key while messages remain in flight, then remove evidence that no longer serves anyone.
The selector is your change boundary
A DKIM signature names a signing domain in d= and a selector in s=; receivers fetch the key at selector._domainkey.domain. Rotation works because a second selector can coexist with the first. Replacing the key underneath an unchanged selector destroys that property: cached DNS, queued messages and slowly draining systems can all encounter the wrong public key. Treat selectors as immutable key identifiers, not friendly aliases whose contents are edited in place.
Use names that operators can distinguish without revealing secrets: a date or generation such as mta2026q3 is better than an eternal default. Provider-assigned selectors are fine when recorded in inventory. Avoid encoding employee names or ticket numbers that will mean nothing after a reorganization. The inventory needs selector, d= domain, signer, algorithm, key size, creation date, activation date, owner and retirement state. If you cannot answer which system holds the private half, the DNS record is already orphaned.
Choose algorithms for the receiving world
For RSA, 2048 bits is the practical baseline for new keys. RSA-1024 persists in old appliances and constrained DNS setups, but should be treated as migration debt; shorter keys are not acceptable. Larger RSA keys add DNS payload and fragmentation pressure without solving an operational problem most mail programs have. Remember that a DKIM public key is base64 inside a TXT record, often split into quoted character strings by the DNS UI. Splitting strings inside one record is valid; publishing several independent DKIM records at the same owner is not.
Ed25519 DKIM offers compact keys and signatures, but support is not universal across signers, validators and hosted providers. The practical deployment is dual signing: keep a broadly interoperable RSA signature while adding Ed25519 where your stack supports it, then measure receiver results. Do not describe Ed25519 as a drop-in replacement until your actual recipient population proves it. The SPF/DMARC/DKIM Checker can inspect a known selector’s published key shape; it cannot certify that every receiver implements the algorithm.
Rotate in four observable phases
First generate the new private key inside the signer or its key-management boundary; never pass it through a DNS ticket. Publish only the new public key under a fresh selector, with a TTL appropriate for the change window. Query authoritative and recursive DNS and validate the complete TXT value. At this point nothing signs with the key, so publication can settle without affecting mail.
Second enable the new selector on one controlled stream and confirm signatures on delivered messages. Third move all intended traffic while leaving the old selector published. Watch at least the maximum DNS cache lifetime plus the longest credible queue and retry interval; delayed mail was signed when it entered the queue, not when it finally arrived. Fourth stop considering the old key active, but delete its public record only after evidence shows no old signatures. Emergency compromise rotation compresses the schedule, yet still benefits from a new selector because it makes the cutover explicit.
Multi-provider signing needs separate ownership
Two providers may sign the same organizational domain, but they should not share private keys or selectors. Give each platform its own selector namespace and let it keep the private key within its service boundary. Some providers sign with their domain by default and offer customer-domain signing later; DMARC only benefits when the validated d= aligns with the visible From domain. Record that distinction before calling a green “DKIM pass” a successful deployment.
Messages may carry multiple DKIM signatures. That is useful during migration, for dual algorithms, or where a platform adds its signature after your gateway has signed. One aligned signature surviving is enough for the DKIM side of DMARC, but indiscriminate multi-signing adds noise and more keys to own. Check a sample from every path: direct mail, marketing, support, transactional systems and forwards. The Email Message Header Analyzer organizes the recorded DKIM and Authentication-Results fields locally, while leaving cryptographic verification to the receiver that produced them.
Know whether the new key is actually in use
DNS presence proves only that a key can be fetched. Send through each production route and inspect DKIM-Signature for the intended d=, s=, a= and canonicalization settings. Read the receiving system’s Authentication-Results, not a header added by the sender. A pass from the new selector, an aligned DMARC pass and absence of body-hash failures are the useful signals. A single test mailbox is a smoke test, not population coverage.
Use DMARC aggregate reports to compare selector-independent DKIM outcomes by source and provider, and provider telemetry where it exposes selector usage. Watch failures after template changes: footers, link rewriting and gateway modifications can break body or header hashes without any key problem. During an ARC-bearing forward, the current DKIM result and the preserved upstream result are different evidence; the ARC Chain Validator helps inspect chain structure, but does not fetch DKIM keys or perform cryptographic validation.
Retire keys, not history
Once no system signs with the old selector and the retention window has passed, remove its DNS record. An empty p= explicitly revokes a key and can be useful as a short, deliberate signal, but leaving revoked records forever is not cleanup. Stale keys increase ambiguity during incidents, preserve forgotten dependencies and make an attacker’s use of an abandoned private key harder to distinguish from legitimate legacy mail. Deletion should be a tracked phase of rotation, not an optional housekeeping ticket.
Keep the non-secret audit trail elsewhere: public-key fingerprint, selector, service owner, activation and retirement times, approval and reason. Destroy or render the retired private key unusable according to the platform’s key-management controls, and confirm backups or replicas do not silently reactivate it. Then schedule the next rotation before memory fades. A modest, repeatable cadence that finishes all phases is better than an aggressive calendar that continually publishes new keys and never removes old ones.