Every DKIM signature needs an expiration date

Problem reported by Douglas Foster - 2/4/2026 at 5:59 AM

Submitted

Every newly-created DKIM signature should have an expiration date. The actual value should be an administrator choice. When evaluating DKIM signatures, an implicit expiration date should be applied to messages that lack one or messages that have an expiration date in the distant future. The need for this comes from an attack category called "DKIM Replay".

The attack starts with a compromised account, because the From address needs to one with a good reputation. Assume the compromised account is "victim@example.com". The spammer uses that account to send a malicious message to an account that he owns, such as "badactor@badguys.com". The malicious content is accepted, and it now has a valid DKIM signature for example.com.

Example.com quickly discovers the problem, takes back control of the account, and thinks they have dodged a bullet because their network was unharmed. No such luck.

The attacker replicates the unmodified malicious message to thousands or millions of desired victims. The message appears authentic because it has a valid signature from Example.com. If the signature never expires, the attack can go on forever. The poor system manager at Example.com will be mystified why his domain keeps showing up on the SpamHaus domain block list.

If the signature has an expiration date, at least there is an upper bound to how long the attacks can persist.

For the same reason, a message date or DKIM signature date that is not recent should be considered suspect and sent to quarantine. There is no perfect answer to the question of "How old is too old?", so both inbound and outbound expiration rules should be configurable by the system manager. I am thinking never more than 5 days.

Feature request ticket has also been opened.

6 Replies

Reply to Thread

Sébastien Riccio Replied

2/4/2026 at 6:04 AM

For sure, DKIM key rotation est highly encouraged.

However its not that trivial, especially when you manage thousands of domains, as you must publish the new DKIM public key in the domain's DNS.

SmarterMail is already ready for DKIM key rollover, but you would probably need a script to handle this automatically through the SM API in conjunction with whatever DNS server you use's API.

And that's for the best case, I mean, when you have control on the domain DNS entries.

Sébastien Riccio System & Network Admin https://swisscenter.com

Sébastien Riccio Replied

2/4/2026 at 6:07 AM

OK I misread, you're talking about the signature expiration itself, not the keys :)

Sébastien Riccio System & Network Admin https://swisscenter.com

Richard Laliberte Replied

2/4/2026 at 8:04 AM

With Keys in mind, it would be nice is SM could do something similar to say Certify the Web, where we can plug in an API key for our DNS host, and it automatically regenerates keys say once a year, with a manual renew option?

Sébastien Riccio Replied

2/4/2026 at 8:58 AM

That could be great but there are a hundred of DNS service providers each one with their own API specs, so it would need writing and maintaining specific REST client code for each of these providers.

If some of them provide RFC 2136 compliant ways of updating DNS records that would be a more generic way to do it, but it uses the DNS protocol, not APIs.

Sébastien Riccio System & Network Admin https://swisscenter.com

J. LaDow Replied

2/4/2026 at 9:31 AM

It looks like the RFC supports expirations in the tags in the DNS entry - you only need to specify two additional tags - one is the creation timestamp the other being the lifespan of the key.

https://datatracker.ietf.org/doc/rfc6376/ (search for expire) --

Then the "validating server" needs to look for those tags.

SM should have an option for "expiring keys" as well. Posh-ACME uses a plugin system to add providers for handling DNS validations - it's what we use for our certificates because of more control. Something along those lines for adding providers would be scalable though at least from a design perspective.

Potential "spam scoring" should include setting for older keys that don't have the additional expiration tags and can have a separate spam score, etc (policy for messages with no expiration, policy for expired, etc...)

MailEnable survivor / convert --

John Quest Replied

2/4/2026 at 1:44 PM

There would absolutely be problems if DKIM keys were force expired at some time point, in that there are so many email servers and configurations that people set and walk away from.

Back to Community Threads

Please leave this box unchecked

Reply to Thread

Enter the verification text