Emails end up in the customer’s spam folder or get rejected, but why? DKIM is configured, SPF is set up, and DMARC is running. Everything was fine in the last check, six months ago. After all, DKIM is supposed to ensure that emails are cryptographically signed and that neither the sender nor the content can be tampered with. However, three weeks ago, during a DNS cleanup, a selector was removed that was “certainly no longer in use.” In fact, the CRM system continued to use it quietly and reliably, right up until the day it was deleted. Now DKIM is invalid, SPF is invalid for forwarding, and DMARC has completely failed. This scenario is not an isolated case, but the result of treating DKIM as a one-time task rather than an ongoing one. In this blog post, you’ll learn what’s important when using DKIM and what common mistakes you should avoid when setting up and maintaining DKIM.
1. Key Generation: The private key belongs in the sending system
The most secure approach is always for the sending system to generate the key pair internally and to release only the public key, up to and including publication in the DNS. This ensures that the private key never leaves the system.
The alternative is to generate and import the key manually. However, this significantly increases the attack surface. Every step in this process is a potential vulnerability: the computer on which the key was generated, the transmission channel (email, ticket, shared document), and the target system during import. Once a private key is compromised, it allows emails to be authentically signed on behalf of the domain until the key is rotated.
Modern Mail Transfer Agents (MTAs) and email security solutions generally support internal key generation. If you have this option, you should choose it.
Additionally, when sending emails across multiple systems within the same domain, each system should be assigned its own selector. This allows signatures to be uniquely assigned to individual systems, for example in DMARC reports or log data. Individual selectors can also be rotated or deactivated independently, ensuring that disruptions are limited to individual systems, and in the event of a compromise, only the affected selector needs to be replaced.
2. DKIM Key Rotation: Done Right and, Above All, Regularly
In many environments, DKIM keys are set up once and then used unchanged for years. This is problematic because cryptographic keys should be rotated regularly to reduce the risk of long-term misuse of compromised keys. We recommend a rotation cycle of six to twelve months. In security-critical environments or following a security incident, a shorter cycle may be advisable.
The biggest challenge with rotation is DNS caching. DNS records are cached by resolvers and intermediate systems according to their Time-to-Live (TTL) value. An existing DKIM key therefore cannot simply be replaced immediately. Otherwise, emails that were still signed with the old key could no longer be verified. Conversely, systems could continue to use outdated DNS data and thus fail to correctly verify signatures with the new key.
For this reason, rotation is typically performed with two keys or DKIM selectors available in parallel. During the transition phase, the old and new keys are published simultaneously in the DNS until it is ensured that no systems are accessing cached legacy information anymore.
DKIM Key Rotation in Four Steps
A clean DKIM key rotation therefore takes place in an overlapping manner:
- Generate a new key pair and a new selector.
- Publish the new DNS record and configure the new selector on the sending system. Both selectors will then be active at the same time. This is not a problem, as multiple DKIM signatures on a single email are explicitly permitted.
- Verify that the new selector is being used correctly and that the signature is valid.
- Once the DMARC reports confirm that the new key is functioning as intended: remove the DNS record and the key from the email system associated with the old selector.
If you don’t want to wait days for feedback from the DMARC reports, it’s best to use tools like 25Reports. 25Reports allows you to send a test email and view the results immediately: which selector was used, whether the signature is valid, and what errors occurred.
3. Key Type and Length: A Critical Trade-off
Two methods are available for DKIM: Ed25519 and RSA.
Ed25519 is the more modern cryptographic choice: smaller keys, more compact signatures, and stronger mathematical properties. The method has been standardized for DKIM since RFC 8463 (2018). However, there is one limitation: support on the recipient side remains inconsistent.
Those who require maximum compatibility must use RSA. With RSA, a simple rule of thumb applies: not less than 1024 bits, not more than 2048 bits, but for different reasons.
1024 bits is no longer considered sufficiently secure and should no longer be chosen for new deployments. 2048 bits is the practically the default, but there’s a catch: the resulting DNS records can exceed the UDP limit of 512 bytes. Resolvers then fall back to TCP, which generally works. However, some systems process such long TXT records incorrectly. 4096-bit sounds more secure and is marginally so in practice, but it causes significantly more compatibility issues.
Unfortunately, the bottom line is: There is no universally optimal key. RSA 2048-bit is the pragmatic standard; Ed25519 is the better choice in scenarios where both your own infrastructure and that of the relevant recipients reliably support it.
4. DKIM Selectors: Always Keep Track
One of the biggest practical challenges with DKIM rotation is the lack of visibility into which selectors are actually still in use.
In established email environments, the assumption that “this selector is no longer in use” is often incorrect. Old configurations, subsystems, or external sending services may continue to use a selector long after a migration. If the corresponding DNS record is removed, DKIM checks will fail for precisely these messages.
This is particularly critical because, in many scenarios, DKIM is the only remaining mechanism for a successful DMARC check. SPF, for example, often fails during forwarding or with third-party providers such as newsletter and CRM systems if there is no clean alignment.
Therefore, before removing a selector, you should verify that it is no longer in use. DMARC reports are particularly helpful for this. They show which DKIM selectors actually appear in the real email flow and whether the corresponding signatures could be successfully validated.
In addition, monitoring tools such as 25Reports can help analyze selector usage. Detected selectors and their last occurrence are displayed in a consolidated list, and alerts can be configured to notify users of new selectors or changes to existing ones. In cases of frequent spoofing, which results in selectors that appear to be new on a recurring basis, the corresponding alerts can be adjusted to control the frequency of notifications. This is advisable because false positives can occur, especially when there is a high volume of spoofing activity.
5. Alignment: The Often-Overlooked Source of Errors
DMARC does not merely require that DKIM be valid. It requires that DKIM be aligned: The domain in the DKIM signature (the ‘d=’ field in the ‘DKIM-Signature’ header) must match the ‘From:’ domain of the email or be an authorized subdomain thereof.
DMARC distinguishes between two modes:
Relaxed Alignment (Default)
Subdomains are allowed. ‘d=mail.example.de’ is aligned with ‘From: @example.de’.
Strict Alignment
Exact matches only. In this mode, “d=mail.example.de” would not be considered an exact match for “@example.de”.
Most environments use “Relaxed” because dedicated sending subdomains work without any issues. However, the actual problem usually arises not with subdomains, but with completely different domains. The classic scenario: A third-party system, CRM, marketing platform, ticketing system, signs outgoing emails with DKIM, but using its own domain. The ‘From:’ header shows ‘sender@customerexample.de’, while the signature has ‘d=crm-platform.com’. The signature is valid. Alignment still fails, and consequently, so does DMARC.
As long as p is not set to “reject”, such emails are simply given a lower rating, and in some cases may even be classified as spam. Once the switch to “p=reject” is made, these emails will fail DMARC unless SPF prevents this.
DMARC reports show the DKIM validation result and the alignment result separately for each message. A combination of ‘dkim=pass’ and ‘dkim_alignment=fail’ is not a contradiction, but exactly the problem described. Those who analyze DMARC reports can identify such configuration errors before they cause significant damage. Here, too, appropriate monitoring is advisable to be informed of emerging issues at an early stage.
Conclusion
DKIM, SPF, and DMARC are not a modular system in which each component can be evaluated independently. They form a unified system; a failure in one area can render the other mechanisms ineffective.
DKIM requires continuous operation, with all that entails: regular rotation, active monitoring, and explicit validation after changes. DMARC reports provide an accurate picture of what is happening in the actual email flow. Analyzing them reveals more about your own email infrastructure than any static configuration check can provide.
By following the five principles outlined in this blog post and utilizing appropriate DMARC monitoring, you can ensure secure and functional email traffic with minimal effort. This also improves delivery rates and the ability to respond to security incidents quickly and effectively.
To ensure your email communications are secure and run smoothly: With our practical guide and 25Reports, you’ll be fully prepared.
Download our free practical guide with step-by-step instructions on “SPF, DKIM, and DMARC” now. With our DMARC monitoring tool NoSpamProxy 25Reports, DMARC is finally easy. The service handles all DMARC monitoring for you. Automated, visualized, and GDPR-compliant. Try it free for 30 days now!
