dkim domain made easy
Until this week I’ve always been reluctant to offer to customers
the signing of email messages with their own domain.
For two reasons:
adding to the dns a TXT record with a 2048 bit long public key could be difficult
the last time I had to exchange eight email messages
and make a telephone call with the customer’s provider to get it done correctly
it requires a special setup on the smtp server side
I thought it was not worth it, because domain alignment for DMARC requires that:
when a sender authenticates their email using SPF and/or DKIM, at least one of the domains must align with the sending From domain
This means that in most cases, the SPF authentication of the sender domain is enough,
while the DKIM signing domain is the one of the service provider.
That’s the standard setup of Google Apps and Office 365 on cloud email services.
Then last week I read the article (pdf file):
M3AAWG DKIM Key Rotation Best Common Practices
It suggests the “3.1.3 Key delegation via CNAME”:
Another method is to delegate keys to the third party by using CNAMEs. […]
Example: Consider the case where "example.com" is the domain to sign, and “acme.com” is the third party. key1._domainkey.example.com CNAME key1.example.com.acme.com key2._domainkey.example.com CNAME key2.example.com.acme.com key1.example.com.acme.com TXT “v=DKIM1; p=” key2.example.com.acme.com TXT “v=DKIM1; p=ADfe34556....”
After numerous configuration tests and the internal documentation updates,
I’ve passed the new requirements to the first customer.
On the first attempt the configuration was successful!
The “how to configure dkim” webpage has been promptly updated.