Tuesday Tip: Five Tips for DKIM Configuration Success
URL Copied
DomainKeys Identified Mail (DKIM) is a most excellent authentication protocol for email messages. It's a great way to affirm that the domain referenced in the email signature indeed authorized or originated the email message in question, and it works together well with DMARC domain protection to help tell the world that certain mail is from me, and other mail pretending to be from me should be rejected. It is also a cornerstone of modern domain reputation management, with a message's DKIM-signed domain being extremely useful to mailbox providers to attach reputation metrics to, and help smoothly power the engines of spam filtering.
Here are five simple tips to get the most out of your DKIM configuration.
Use 2048-bit keys. When talking about the number of bits, higher is better. Higher takes more computational power to crack. Google was noted as using a 512-bit DKIM key in 2012 and this was exploited then to prove a point to them. And nowadays, cracking a 512-bit key can be as easy as costing $70 and 24 hours. Even back in 2012, 1024 bits or larger was recommended for your DKIM key. But nowadays, 2048-bits is best, IMHO. (The next step up from 2048-bit would be 4096-bit, and it isn't clear to me how broadly 4096-bit keys are supported today.)
Rotate your key regularly. Key rotation means replacing the existing DKIM private and public key pair with a new one periodically, and retiring the old one, removing it from DNS. How often? Industry group M3AAWG suggests every six months. Some people have been running the same DKIM key pair for years, so anything is better than nothing. What if we designated January "DKIM Key Rotation Month" and recommend that everybody update their DKIM key every January? Let's think about that one.
Do not use the L= tag. It leads to imperfect protection for message content, and it has no real world modern use. Avoid!
Configure DKIM to utilize the X= tag, if possible. This adds an expiration time to a given message's signature. The theory here is that this helps prevent DKIM replay attacks by making a given message's signature less durable, not making it durable beyond what might be reasonably necessary to properly confirm the message's signature. OpenDKIM's SignatureTTL setting is one way to configure this. Who does this today? Not everybody, but Google and others do.
Aim for alignment. DKIM alignment means that the domain referenced in your message's DKIM signature (or one of them – because messages can have more than one DKIM signature) matches the domain in your from address. If I send email as newsletter@spamresource.com, and my DKIM signature is specific to the domain spamresource.com (via the D= tag setting), that "aligns" as that's the same domain in both places. In my opinion: It is best practice for deliverability success in 2024 to always have a DKIM signature that aligns. Some form of "alignment" is necessary for DMARC success – but even discounting that, many email sending platforms automatically add their own DKIM signature (with its own domain) to all messages their platform will originate, meaning your domain reputation and associated deliverability success or failure will be linked to that platform's default domain, and not to your domain. You don't want that.
The goal, as it relates to higher bits of encryption and periodic rotation of your DKIM key pairs, is to make it harder for a bad guy to be able to decrypt that DKIM key. If they're able to do that, they're now going to be able to send as you. Bad for security (think phishing and spoofing that PASSES authentication checks -- yuck!) and bad for deliverability (watch your domain reputation tank as bad guys start sending bad things).
You might not have control over all of these settings. A lot of email sending platforms have you implement a CNAME record (or two, or three) in DNS to link you up to their infrastructure, where they then take care of the key management and signing configuration. It's in your best interest to learn how your favorite ESP or marketing automation platform handles these settings. You can start by looking at headers from messages sent. Questions like, did they use the X= tag or L= tag in their DKIM configuration, you can potentially answer yourself, just from viewing the DKIM Signature header for any messages sent.
And if a platform says they can't handle all of these best practice requirements, ask them why not, and ask them to consider doing so in the future. Some of these might be new things to them (like the X= tag), and are not necessarily reasons for customers to start run screaming for the hills. But if they're not able to follow all or most of these best practice recommendations, I'd be concerned.
(And what about DKIM oversigning? I'll cover that in a follow up.)
DomainKeys Identified Mail (DKIM) is a most excellent authentication protocol for email messages. It's a great way to affirm that the domain referenced in the email signature indeed authorized or originated the email message in question, and it works together well with DMARC domain protection to help tell the world that certain mail is from me, and other mail pretending to be from me should be rejected. It is also a cornerstone of modern domain reputation management, with a message's DKIM-signed domain being extremely useful to mailbox providers to attach reputation metrics to, and help smoothly power the engines of spam filtering.
Here are five simple tips to get the most out of your DKIM configuration.
- Use 2048-bit keys. When talking about the number of bits, higher is better. Higher takes more computational power to crack. Google was noted as using a 512-bit DKIM key in 2012 and this was exploited then to prove a point to them. And nowadays, cracking a 512-bit key can be as easy as costing $70 and 24 hours. Even back in 2012, 1024 bits or larger was recommended for your DKIM key. But nowadays, 2048-bits is best, IMHO. (The next step up from 2048-bit would be 4096-bit, and it isn't clear to me how broadly 4096-bit keys are supported today.)
- Rotate your key regularly. Key rotation means replacing the existing DKIM private and public key pair with a new one periodically, and retiring the old one, removing it from DNS. How often? Industry group M3AAWG suggests every six months. Some people have been running the same DKIM key pair for years, so anything is better than nothing. What if we designated January "DKIM Key Rotation Month" and recommend that everybody update their DKIM key every January? Let's think about that one.
- Do not use the L= tag. It leads to imperfect protection for message content, and it has no real world modern use. Avoid!
- Configure DKIM to utilize the X= tag, if possible. This adds an expiration time to a given message's signature. The theory here is that this helps prevent DKIM replay attacks by making a given message's signature less durable, not making it durable beyond what might be reasonably necessary to properly confirm the message's signature. OpenDKIM's SignatureTTL setting is one way to configure this. Who does this today? Not everybody, but Google and others do.
- Aim for alignment. DKIM alignment means that the domain referenced in your message's DKIM signature (or one of them – because messages can have more than one DKIM signature) matches the domain in your from address. If I send email as newsletter@spamresource.com, and my DKIM signature is specific to the domain spamresource.com (via the D= tag setting), that "aligns" as that's the same domain in both places. In my opinion: It is best practice for deliverability success in 2024 to always have a DKIM signature that aligns. Some form of "alignment" is necessary for DMARC success – but even discounting that, many email sending platforms automatically add their own DKIM signature (with its own domain) to all messages their platform will originate, meaning your domain reputation and associated deliverability success or failure will be linked to that platform's default domain, and not to your domain. You don't want that.
The goal, as it relates to higher bits of encryption and periodic rotation of your DKIM key pairs, is to make it harder for a bad guy to be able to decrypt that DKIM key. If they're able to do that, they're now going to be able to send as you. Bad for security (think phishing and spoofing that PASSES authentication checks -- yuck!) and bad for deliverability (watch your domain reputation tank as bad guys start sending bad things).You might not have control over all of these settings. A lot of email sending platforms have you implement a CNAME record (or two, or three) in DNS to link you up to their infrastructure, where they then take care of the key management and signing configuration. It's in your best interest to learn how your favorite ESP or marketing automation platform handles these settings. You can start by looking at headers from messages sent. Questions like, did they use the X= tag or L= tag in their DKIM configuration, you can potentially answer yourself, just from viewing the DKIM Signature header for any messages sent.
And if a platform says they can't handle all of these best practice requirements, ask them why not, and ask them to consider doing so in the future. Some of these might be new things to them (like the X= tag), and are not necessarily reasons for customers to start run screaming for the hills. But if they're not able to follow all or most of these best practice recommendations, I'd be concerned.
Comments
Post a Comment
Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.