Notes on using DKIM in a DMARC world

February 10, 2022

By itself, DKIM simply creates an attestation that some domain (or host) has touched an email message, in the form of a DKIM signature that names that domain (really a DNS name) in its 'd=' parameter. If you have an email server that handles (outgoing) email for a bunch of host and domain names, and you think of yourself as primarily one of them, say, '', then you can have your email server generate DKIM signatures using this primary domain regardless of which one of your assorted historical and current domains someone is using for their email today. You can even sign email that passes through you that is from other, outside domains to attest that it genuinely came through you, if you want.

(You may not want to sign other people's email for social reasons, since a DKIM signature may be seen as taking responsibility for it and you may be forwarding unwanted email, but DKIM itself considers this perfectly valid. Messages can and not infrequently do have multiple DKIM signatures for the various parties that are associated with the email or that have touched it in processing. I put together some statistics on this in late 2018 with a bit more in 2020.)

This doesn't work so well once you throw in DMARC. DMARC is specifically concerned with validating the domain in the From: header address, so it wants to find a DKIM signature with a 'd=' that matches that domain. Well, sort of. As covered in RFC 7489 section 3.1.1, it's possible to require only that the 'organizational domain' matches, not that there is an exact match. This is called 'relaxed DKIM identifier alignment' (as opposed to 'strict' mode), and I believe it's the default. If I'm understanding relaxed alignment correctly, then DMARC would accept a DKIM signature with '' for a From: subdomain of '<any>', and I think even '' itself.

(However, it wouldn't be accepted for a From: of, since the organizational domains differ.)

If you have multiple historical and current subdomains and domains that are used for outgoing email (as we do), the safest thing to do is to always DKIM sign for the specific subdomain used in the From: of the current message. You don't need to use different DKIM keys unless you want to (it will probably be simpler not to) and you can reuse the same DKIM selector name, but each (sub) domain will need a DNS record for the selector you're using. The simple approach is to make them all DNS CNAMEs to the selector record in your primary (sub)domain. This gives you advance protection against any need or desire of people to switch your DMARC over to strict DKIM identifier alignment.

(The implications of strict versus relaxed DKIM identifier alignment are something for another entry, but the more I think about it, the more I think we're going to wind up with strict alignment sooner or later.)

Because I looked it up, DMARC policies are checked in DNS on the specific subdomain in the From: and on the organizational domain (if they're different), but not on any intermediate subdomains. So if you have, for example, '', its DMARC policies will be looked up on it and on, but not on This applies equally if the From: 'domain' is really a host name. If you send out email using lots of individual host names and you have to use strict DKIM identifier alignment, you're probably not going to enjoy it (unless all of the DNS provisioning and mailer configuration is automated).

PS: We did start DKIM signing our email, using a single DKIM domain for everything because that's by far the simplest solution in Exim and DMARC wasn't on our minds until, basically, right now. Now that we're dealing with DMARC (for reasons beyond the scope of this entry), We're going to have to change our DKIM signing a bit so it looks at the From: domain and is more specific.

Written on 10 February 2022.
« ZFS performance and modern solid state disk systems
Some things on strict and relaxed DKIM alignment in DMARC »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Feb 10 21:56:45 2022
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.