This article takes a look at DKIM Selectors in particular, and we'll explain:
How does DKIM work?
DKIM (DomainKeys Identified Mail) is a nifty email authentication method that helps ensure your emails are legit. It allows the email receiver to verify that an email claiming to come from a specific domain was indeed authorized by the domain owner and wasn't tampered with during transit.
This magic happens through cryptographic authentication, using a pair of keys: a private key and a public key. The private key is used to sign the email and the public key, which is published in the domain's DNS records, is used by the receiver to verify the signature. This way, DKIM helps maintain the integrity and authenticity of your emails, making sure they reach their destination without any unauthorized modifications.
The Mechanics of DKIM
Digital Signature Creation: When you send an email, the server that originates the email generates a unique digital signature. This signature is crafted based on the email's content, including its headers and body, ensuring that any changes made during transit can be detected. The signature is created using a private key that only the sender's domain knows.
Adding the Signature: This digital signature is then attached to the email as a DKIM-Signature header. This header contains essential information from the verification process, such as the DKIM version, the domain responsible for the email (d=tag) and the actual signature (b=tag).
Email Transmission and Reception: As the email makes it way to the recipient's server, it may pass through several intermediary servers, each capable of inspecting the DKIM signature if they are setup to do so. It's common for email to be relayed through multiple servers. For instance, an organization might send an email from their Microsoft 365 account, which is then relayed through a third-party security gateway before reaching the recipient. Similarly, emails that are automatically forwarded, like from a university email address to a personal Gmail account, are also relayed.
Verification Process: When the recipient's server receives the email, it extracts the DKIM-Signature header and uses the information to perform a DNS query. This query retrieves the public key published in the sender's DNS records under the specific DKIM selector. The public key is then used to verify the digital signature attached to the email.
Authentication Check: If the signature matches the email's content, it confirms the email's authenticity and ensures it hasn't been altered during transit. For the DKIM signature to fully validate the sender's legitimacy, the signing domain specified in the DKIM-Signature header (the d=tag) must match the domain in the email's "From" header. The alignment is crucial because it ensures that the entity claiming responsibility for the email through DKIM is the same as the one indicated in the "From" address. Without this match, someone could spoof the "From" header while signing the email with their own domain, which would undermine the trust mechanism that DKIM is designed to provide.
What are DKIM Selectors?
DKIM selectors are like handy guides that help the receiving email server find and validate the sender's public key. Essentially, a DKIM selector is a method used to differentiate between multiple keys published in a single domain's DNS records. This is especially useful for organizations that send emails from various servers or services, allowing each to have its own unique DKIM signature.
Finding your DKIM Selector in Outlook/msdyn_blobfile/$value)
Sample DKIM Signature Header
Imagine you've sent an email from exapmle.com and you're examining the email headers. You might come across a DKIM-Signature header that appear similar to this:
In this example, d=example.com identifies the domain responsible for the email, while s=selector2 is the selector. The selector, Selector2, points to the location in the DNS record for example.com where the public key is stored, specifically at selector2._domainkey.example.com.
Finding the Selector
To locate your DKIM selector, look at the DKIM-Signature header. The s=tag, which comes right after the domain (d=tag) and before other parameters, holds the selector value. For instance, in our example Selector2 is the selector you need.
Next Step
Once you've pinpointed your DKIM selector, you can use it to verify your DKIM records. Check your DMARC data to see how often it's used and ensure its functioning correctly. Tools like the dnschecker.org and mxtoolbox.com are handy for confirming that your public key is properly published in your DNS and accessible for email verification. They can also help you verify that the public key record you're about to publish is DNS syntactically correct.
Third-party Providers and DKIM Signing: TXT vs. CNAME Records
When setting up DKIM signing with a third -party email service provider like Microsoft Exchange Online or Salesforce.com, you might need to add either an TXT record or a CNAME record to your domain's DNS settings. This step is crucial for verifying emails sent on behalf of your domain using the provider's DKIM signature.
TXT Record for DKIM
TXT record - A TXT record is used to directly store the DKIM public key in your domain's DNS. This allows email servers receiving your emails to find and use this public key to verify the DKIM signature of emails sent from your domain.
Example: If your third-party provider gives you a TXT record for DKIM, it might look something like this:
Why Use a CNAME Record For DKIM?
Some providers use a CNAME record to reference a DKIM public key hosted on their infrastructure. This method allows the provider to rotate DKIM keys without needing changes to the client's DNS. Essentially, it delegates the lookup for the DKIM key to the provider's domain.
Example: If your provider recommends using a CNAME record, it might look like this:
In this case, querying selector2._domainkey.example.com in DNS will return a CNAME record pointing to selector2.exampleprovider.com, where the actual TXT record with the DKIM public key is hosted.
Choosing Between TXT and CNAME Records
The choice between TXT and CNAME records for DKIM depends on your provider's infrastructure and their policy for managing DKIM keys. CNAME records can offer more flexibility for key management, especially for providers that handle key rotation on behalf of their clients. However, TXT records give domain owners direct control over their DKIM keys in their DNS.
Implementing Provider's DKIM Records
Follow your provider's instructions carefully when adding DKIM records to your DNS. Ensure that the records are correctly formatted and published, and verify their propagation using DNS lookups tools. Providers often have their own tools or may require verification within their application or by their support team before enabling the use of the key.
Remember to update these records as advised by your provider, especially if they use TXT records for DKIM and periodically rotate keys.
- What DKIM Selectors are
- Where to find your own DKIM Selector
- Third-Party providers and DKIM Signing
How does DKIM work?
DKIM (DomainKeys Identified Mail) is a nifty email authentication method that helps ensure your emails are legit. It allows the email receiver to verify that an email claiming to come from a specific domain was indeed authorized by the domain owner and wasn't tampered with during transit.
This magic happens through cryptographic authentication, using a pair of keys: a private key and a public key. The private key is used to sign the email and the public key, which is published in the domain's DNS records, is used by the receiver to verify the signature. This way, DKIM helps maintain the integrity and authenticity of your emails, making sure they reach their destination without any unauthorized modifications.
The Mechanics of DKIM
Digital Signature Creation: When you send an email, the server that originates the email generates a unique digital signature. This signature is crafted based on the email's content, including its headers and body, ensuring that any changes made during transit can be detected. The signature is created using a private key that only the sender's domain knows.
Adding the Signature: This digital signature is then attached to the email as a DKIM-Signature header. This header contains essential information from the verification process, such as the DKIM version, the domain responsible for the email (d=tag) and the actual signature (b=tag).
Email Transmission and Reception: As the email makes it way to the recipient's server, it may pass through several intermediary servers, each capable of inspecting the DKIM signature if they are setup to do so. It's common for email to be relayed through multiple servers. For instance, an organization might send an email from their Microsoft 365 account, which is then relayed through a third-party security gateway before reaching the recipient. Similarly, emails that are automatically forwarded, like from a university email address to a personal Gmail account, are also relayed.
Verification Process: When the recipient's server receives the email, it extracts the DKIM-Signature header and uses the information to perform a DNS query. This query retrieves the public key published in the sender's DNS records under the specific DKIM selector. The public key is then used to verify the digital signature attached to the email.
Authentication Check: If the signature matches the email's content, it confirms the email's authenticity and ensures it hasn't been altered during transit. For the DKIM signature to fully validate the sender's legitimacy, the signing domain specified in the DKIM-Signature header (the d=tag) must match the domain in the email's "From" header. The alignment is crucial because it ensures that the entity claiming responsibility for the email through DKIM is the same as the one indicated in the "From" address. Without this match, someone could spoof the "From" header while signing the email with their own domain, which would undermine the trust mechanism that DKIM is designed to provide.
What are DKIM Selectors?
DKIM selectors are like handy guides that help the receiving email server find and validate the sender's public key. Essentially, a DKIM selector is a method used to differentiate between multiple keys published in a single domain's DNS records. This is especially useful for organizations that send emails from various servers or services, allowing each to have its own unique DKIM signature.
Finding your DKIM Selector in Outlook
- Double-click the email to open it in a new window.
- Go to the "File" menu and select "Properties."
- Under the "Internet headers" section in the Properties window, you'll find the email header. Scroll to locate the "DKIM-Signature" line.
Sample DKIM Signature Header
Imagine you've sent an email from exapmle.com and you're examining the email headers. You might come across a DKIM-Signature header that appear similar to this:
| 9 | DKIM-Signature | v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QW9p1pYx9BqnxqWbab8+s=STaa9fDPqFVQWeYrbZch6fpv; b=QHegDzacGnNfGvAiiunGRE0J80K89Qr/pv751qBXDKGR74nSA5wTCL1PRrhqmN98/vUcB+Cthi2LaeVszIFqbfG9zulmEN7YUT9JHNXmM7FWbUIOgQtfSNcYUjnx1lFdUIcivjf3X8bSN/PwNvJpd7ZYwNDs5ZlhdX0TgZYysURQ3aiCPscBWP2ABsWD/K/PBhEjga1iurQEuQvKwOBGeMdDG0CE6e3jgabsc0jPIoCasT1bLmlVfpAoJloVrj3GMcm1+yVDnOSL5V3pCUG7rqIv/hSMFpyhRFx+rc0CogBaPuqv1arPEkKpSvifKWKmcfTCO7iAF2bj3IDJ1BSh+Q== |
In this example, d=example.com identifies the domain responsible for the email, while s=selector2 is the selector. The selector, Selector2, points to the location in the DNS record for example.com where the public key is stored, specifically at selector2._domainkey.example.com.
Finding the Selector
To locate your DKIM selector, look at the DKIM-Signature header. The s=tag, which comes right after the domain (d=tag) and before other parameters, holds the selector value. For instance, in our example Selector2 is the selector you need.
Next Step
Once you've pinpointed your DKIM selector, you can use it to verify your DKIM records. Check your DMARC data to see how often it's used and ensure its functioning correctly. Tools like the dnschecker.org and mxtoolbox.com are handy for confirming that your public key is properly published in your DNS and accessible for email verification. They can also help you verify that the public key record you're about to publish is DNS syntactically correct.
Third-party Providers and DKIM Signing: TXT vs. CNAME Records
When setting up DKIM signing with a third -party email service provider like Microsoft Exchange Online or Salesforce.com, you might need to add either an TXT record or a CNAME record to your domain's DNS settings. This step is crucial for verifying emails sent on behalf of your domain using the provider's DKIM signature.
TXT Record for DKIM
TXT record - A TXT record is used to directly store the DKIM public key in your domain's DNS. This allows email servers receiving your emails to find and use this public key to verify the DKIM signature of emails sent from your domain.
Example: If your third-party provider gives you a TXT record for DKIM, it might look something like this:
Selector/Nameserver | IN TEXT | Value |
| selector2._domainkey.example.com. | IN TXT | “v=DKIM1; h=sha256; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQD…" |
Why Use a CNAME Record For DKIM?
Some providers use a CNAME record to reference a DKIM public key hosted on their infrastructure. This method allows the provider to rotate DKIM keys without needing changes to the client's DNS. Essentially, it delegates the lookup for the DKIM key to the provider's domain.
Example: If your provider recommends using a CNAME record, it might look like this:
Selector/Nameserver | DNS Type | Value |
| selector2._domainkey.example.com. | IN CNAME | selector2.exampleprovider.com. |
In this case, querying selector2._domainkey.example.com in DNS will return a CNAME record pointing to selector2.exampleprovider.com, where the actual TXT record with the DKIM public key is hosted.
Choosing Between TXT and CNAME Records
The choice between TXT and CNAME records for DKIM depends on your provider's infrastructure and their policy for managing DKIM keys. CNAME records can offer more flexibility for key management, especially for providers that handle key rotation on behalf of their clients. However, TXT records give domain owners direct control over their DKIM keys in their DNS.
Implementing Provider's DKIM Records
Follow your provider's instructions carefully when adding DKIM records to your DNS. Ensure that the records are correctly formatted and published, and verify their propagation using DNS lookups tools. Providers often have their own tools or may require verification within their application or by their support team before enabling the use of the key.
Remember to update these records as advised by your provider, especially if they use TXT records for DKIM and periodically rotate keys.