Choose a DKIM key configuration that satisfies the protocol and works across the systems that send and receive your mail. A larger number in a control panel is not a complete security decision. Record the algorithm, key type and receiver evidence, and keep cryptographic strength separate from delivery and alignment.
Use the updated RSA requirements
RFC 8301 updates the older DKIM specification. For RSA, signing keys must be at least 1024 bits, and signers should use at least 2048 bits. Verifiers must support validation with RSA keys from 1024 through 4096 bits, may support larger keys, and must not accept RSA keys below 1024 bits as valid. A verifier can still apply a local policy based on key length.
The same RFC prohibits rsa-sha1 for signing and verification. Do not use an obsolete tutorial's SHA-1 example as a current deployment recommendation. Check the actual a= value in a received DKIM-Signature and the key type reached through its selector, rather than trusting an administrator's recollection of the original setup.
The minimum and recommendation answer different questions. A 1024-bit RSA key can meet the specified floor without meeting the stronger recommended choice. If the organisation retains it because of a documented system limitation, record the exception, owner and removal condition. Do not describe that exception as the universal best configuration.
Check the service before generating keys
Determine whether the provider manages keys or accepts customer-supplied material. Amazon SES Easy DKIM documents a 2048-bit default; that product behaviour should not be generalised to all mail platforms. Some services expose only a supported set of options. A generated 4096-bit key is useless if the intended signer cannot load it or the DNS provisioning path corrupts its public record.
RFC 8463 adds Ed25519-SHA256: signers should implement it and verifiers must implement it under that specification. Its key sizes are not numerically comparable with RSA sizes as equivalent security measures. Support in the standard does not demonstrate support in every deployed signer, receiver or administration interface. Treat an algorithm migration as a compatibility change with explicit evidence, not as a cosmetic setting. RFC 8463 section 6 permits parallel RSA and Ed25519 signatures during transition; they must use separate selectors because each selector identifies a single key record. Verify that the actual signing service supports this approach before planning it.
Build a useful validation matrix
For each sending route, record the software or provider, algorithm, key size where relevant, selector, publication method and a representative receiving system. Separate three tests: the signer accepts the configuration, the public key resolves intact, and a recipient verifies a message produced by that signer.
An illustrative migration starts with a legacy 1024-bit RSA billing signer. The proposed target is 2048-bit RSA with SHA-256. Publish a new selector using the platform's supported process, verify the key, send through the billing application and inspect the receiving result. A test from an employee mailbox does not prove the billing application switched. Keep the old dependency only for the planned transition and legitimate delayed mail, unless incident response dictates otherwise.
Interpret failures precisely
If a larger record fails to publish, investigate the DNS interface and TXT representation before weakening the cryptography. If verification reports an unsupported algorithm, retain that finding against the actual receiver and software version. If DKIM passes but DMARC fails, inspect identity alignment instead of changing key size again.
Document what was tested and what remains unknown. A sample of successful receivers is useful operational evidence, not a guarantee covering the entire internet. Schedule review when the provider, cryptographic guidance or important recipient population changes. The decision is defensible when its requirements, implementation limits and observed results are all visible.
Related reading
RSA and Ed25519 DKIM signatures: deployment questions and interoperability · DKIM public-key syntax: identify truncated or malformed DNS values.
Record the decision before rollout
- Current route: application, owner, signing domain, selector and emitted algorithm.
- Proposed choice: supported RSA-SHA256 at 2048 bits or stronger where justified, or a supported Ed25519 transition.
- Acceptance evidence: signer loads the key; DNS serves it intact; a trusted receiving system verifies a message from this application.
- Stop condition: unsupported algorithm, malformed key or missing signature. Resolve that defect before retiring the working selector.
- Exception: if retaining 1024-bit RSA, name the limitation, risk owner and date for reassessment.