Frequently Asked Questions
Use DKIM to validate outbound email sent from your custom domain
Did you know you can try the features in Microsoft 365 Defender for Office 365 Plan 2 for free? Use the 90-day Defender for Office 365 trial at the Microsoft 365 Defender portal trials hub. Learn about who can sign up and trial terms here.
Applies to
This article lists the steps to use DomainKeys Identified Mail (DKIM) with Microsoft 365 to ensure that destination email systems trust messages sent outbound from your custom domain.
In this article:
Note
Microsoft 365 automatically sets up DKIM for its initial 'onmicrosoft.com' domains. That means you don't need to do anything to set up DKIM for any initial domain names (for example, litware.onmicrosoft.com). For more information about domains, see Domains FAQ.
DKIM is one of the trio of Authentication methods (SPF, DKIM and DMARC) that help prevent attackers from sending messages that look like they come from your domain.
DKIM lets you add a digital signature to outbound email messages in the message header. When you configure DKIM, you authorize your domain to associate, or sign, its name to an email message using cryptographic authentication. Email systems that get email from your domain can use this digital signature to help verify whether incoming email is legitimate.
In basic, a private key encrypts the header in a domain's outgoing email. The public key is published in the domain's DNS records, and receiving servers can use that key to decode the signature. DKIM verification helps the receiving servers confirm the mail is really coming from your domain and not someone spoofing your domain.
Tip
You can choose to do nothing about DKIM for your custom domain too. If you don't set up DKIM for your custom domain, Microsoft 365 creates a private and public key pair, enables DKIM signing, and then configures the Microsoft 365 default policy for your custom domain.
Microsoft-365's built-in DKIM configuration is sufficient coverage for most customers. However, you should manually configure DKIM for your custom domain in the following circumstances:
SPF adds information to a message envelope but DKIM encrypts a signature within the message header. When you forward a message, portions of that message's envelope can be stripped away by the forwarding server. Since the digital signature stays with the email message because it's part of the email header, DKIM works even when a message has been forwarded as shown in the following example.
In this example, if you had only published an SPF TXT record for your domain, the recipient's mail server could have marked your email as spam and generated a false positive result. The addition of DKIM in this scenario reduces false positive spam reporting. Because DKIM relies on public key cryptography to authenticate and not just IP addresses, DKIM is considered a much stronger form of authentication than SPF. We recommend using both SPF and DKIM, as well as DMARC in your deployment.
Tip
DKIM uses a private key to insert an encrypted signature into the message headers. The signing domain, or outbound domain, is inserted as the value of the d= field in the header. The verifying domain, or recipient's domain, then uses the d= field to look up the public key from DNS, and authenticate the message. If the message is verified, the DKIM check passes.
All the accepted domains of your tenant will be shown in the Microsoft 365 Defender portal under the DKIM page. If you do not see it, add your accepted domain from domains page. Once your domain is added, follow the steps as shown below to configure DKIM.
Step 1: On the DKIM page, select the domain you wish to configure.
Step 2: Slide the toggle to Enable. You will see a pop-up window stating that you need to add CNAME records.
Step 3: Copy the CNAMES shown in the pop up window
Step 4: Publish the copied CNAME records to your DNS service provider.
On your DNS provider's website, add CNAME records for DKIM that you want to enable. Make sure that the fields are set to the following values for each:
text
If you see CNAME record doesn't exist error, it might be due to:
Domains FAQ.
Since both 1024 and 2048 bitness are supported for DKIM keys, these directions will tell you how to upgrade your 1024-bit key to 2048 in Exchange Online PowerShell. The steps below are for two use-cases, please choose the one that best fits your configuration.
PowerShell
Tip
This new 2048-bit key takes effect on the RotateOnDate, and will send emails with the 1024-bit key in the interim. After four days, you can test again with the 2048-bit key (that is, once the rotation takes effect to the second selector).
If you want to rotate to the second selector, after four days and confirming that 2048-bitness is in use, manually rotate the second selector key by using the appropriate cmdlet listed above.
For detailed syntax and parameter information, see the following articles: Rotate-DkimSigningConfig, New-DkimSigningConfig, and Get-DkimSigningConfig.
Publish two CNAME records for your custom domain in DNS<li>Enable DKIM signing for your custom domain</li>
Connect to Exchange Online PowerShell.
Run the following commands in Exchange Online PowerShell to create the selector records:
PowerShell
Use the following format for the CNAME records.
Important
If you are one of our GCC High customers, we calculate customDomainIdentifier differently! Instead of looking up the MX record for your initialDomain to calculate customDomainIdentifier, instead we calculate it directly from the customized domain. For example, if your customized domain is "contoso.com" your customDomainIdentifier becomes "contoso-com", any periods are replaced with a dash. So, regardless of what MX record your initialDomain points to, you'll always use the above method to calculate the customDomainIdentifier to use in your CNAME records.
Console
Console
Note
It's important to create the second record, but only one of the selectors may be available at the time of creation. In essence, the second selector might point to an address that hasn't been created yet. We still recommended that you create the second CNAME record, because your key rotation will be seamless.
Important
If you are configuring DKIM for the first time and see the error 'No DKIM keys saved for this domain' complete the command in step 2 below (for example,
Wait a few minutes before you follow these steps to confirm that you have properly configured DKIM. This allows time for the DKIM information about the domain to be spread throughout the network.
Important
The DKIM signature is omitted under any of the following conditions:
Console
<code>; " style="box-sizing: inherit; outline-color: inherit; font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; font-size: 1em; direction: ltr; border: 0px; line-height: 1.3571; display: block; position: relative;"> Authentication-Results: dkim=none (message not signed) header.d=none; dmarc=none action=none header.from=<sender_domain>;
What you need to do to manually set up DKIM.
Default behavior for DKIM and Microsoft 365.
If you do not enable DKIM, Microsoft 365 automatically creates a 2048-bit DKIM public key for your Microsoft Online Email Routing Address (MOERA)/initial domain and the associated private key which we store internally in our datacenter. By default, Microsoft 365 uses a default signing configuration for domains that do not have a policy in place. This means that if you do not set up DKIM yourself, Microsoft 365 will use its default policy and keys it creates to enable DKIM for your domain.
Also, if you disable DKIM signing on your custom domain after enabling it, after a period of time, Microsoft 365 will automatically apply the MOERA/initial domain policy for your custom domain.
In the following example, suppose that DKIM for fabrikam.com was enabled by Microsoft 365, not by the administrator of the domain. This means that the required CNAMEs do not exist in DNS. DKIM signatures for email from this domain will look something like this:
Console<code> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=selector1-fabrikam-com; d=contoso.onmicrosoft.com; t=1429912795; h=From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=; b=<signed>; " style="box-sizing: inherit; outline-color: inherit; font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; font-size: 1em; direction: ltr; border: 0px; line-height: 1.3571; display: block; position: relative;">From: Second Example <second.example@fabrikam.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=selector1-fabrikam-com; d=contoso.onmicrosoft.com; t=1429912795; h=From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=<body hash>; b=<signed field>; </signed>
Some bulk email service providers, or software-as-a-service providers, let you set up DKIM keys for email that originates from their service. This requires coordination between yourself and the third-party in order to set up the necessary DNS records. Some third-party servers can have their own CNAME records with different selectors. No two organizations do it exactly the same way. Instead, the process depends entirely on the organization.
An example message showing a properly configured DKIM for contoso.com and bulkemailprovider.com might look like this:
Console
Organizations should explicitly state if a domain does not send email by specifying
For example, the DKIM record would look like this:
Console
Set up SPF in Microsoft 365 to help prevent spoofing. For a more in-depth understanding of how Microsoft 365 uses SPF, or for troubleshooting or non-standard deployments such as hybrid deployments, start with How Microsoft 365 uses Sender Policy Framework (SPF) to prevent spoofing.
Next, see Use DMARC to validate email. Anti-spam message headers includes the syntax and header fields used by Microsoft 365 for DKIM checks.
This test will validate that the DKIM signing configuration has been configured correctly, and that the proper DNS entries have been published.
Note
This feature requires a Microsoft 365 administrator account. This feature isn't available for Microsoft 365 Government, Microsoft 365 operated by 21Vianet, or Microsoft 365 Germany.
Run Tests: DKIM
Key rotation via PowerShell: Rotate-DkimSigningConfig
Use DMARC to validate email
Use trusted ARC Senders for legitimate mailflows
Applies to
This article lists the steps to use DomainKeys Identified Mail (DKIM) with Microsoft 365 to ensure that destination email systems trust messages sent outbound from your custom domain.
In this article:
- How DKIM works better than SPF alone to prevent malicious spoofing
- Steps to Create, enable and disable DKIM from Microsoft 365 Defender portal
- Steps to manually upgrade your 1024-bit keys to 2048-bit DKIM encryption keys
- Steps to manually set up DKIM
- Steps to configure DKIM for more than one custom domain
- Disabling the DKIM signing policy for a custom domain
- Default behavior for DKIM and Microsoft 365
- Set up DKIM so that a third-party service can send, or spoof, email on behalf of your custom domain
- Next steps: After you set up DKIM for Microsoft 365
Note
Microsoft 365 automatically sets up DKIM for its initial 'onmicrosoft.com' domains. That means you don't need to do anything to set up DKIM for any initial domain names (for example, litware.onmicrosoft.com). For more information about domains, see Domains FAQ.
DKIM is one of the trio of Authentication methods (SPF, DKIM and DMARC) that help prevent attackers from sending messages that look like they come from your domain.
DKIM lets you add a digital signature to outbound email messages in the message header. When you configure DKIM, you authorize your domain to associate, or sign, its name to an email message using cryptographic authentication. Email systems that get email from your domain can use this digital signature to help verify whether incoming email is legitimate.
In basic, a private key encrypts the header in a domain's outgoing email. The public key is published in the domain's DNS records, and receiving servers can use that key to decode the signature. DKIM verification helps the receiving servers confirm the mail is really coming from your domain and not someone spoofing your domain.
Tip
You can choose to do nothing about DKIM for your custom domain too. If you don't set up DKIM for your custom domain, Microsoft 365 creates a private and public key pair, enables DKIM signing, and then configures the Microsoft 365 default policy for your custom domain.
Microsoft-365's built-in DKIM configuration is sufficient coverage for most customers. However, you should manually configure DKIM for your custom domain in the following circumstances:
- You have more than one custom domain in Microsoft 365
- You're going to set up DMARC too (recommended)
- You want control over your private key
- You want to customize your CNAME records
- You want to set up DKIM keys for email originating out of a third-party domain, for example, if you use a third-party bulk mailer.
How DKIM works better than SPF alone to prevent malicious spoofing
SPF adds information to a message envelope but DKIM encrypts a signature within the message header. When you forward a message, portions of that message's envelope can be stripped away by the forwarding server. Since the digital signature stays with the email message because it's part of the email header, DKIM works even when a message has been forwarded as shown in the following example.
In this example, if you had only published an SPF TXT record for your domain, the recipient's mail server could have marked your email as spam and generated a false positive result. The addition of DKIM in this scenario reduces false positive spam reporting. Because DKIM relies on public key cryptography to authenticate and not just IP addresses, DKIM is considered a much stronger form of authentication than SPF. We recommend using both SPF and DKIM, as well as DMARC in your deployment.
Tip
DKIM uses a private key to insert an encrypted signature into the message headers. The signing domain, or outbound domain, is inserted as the value of the d= field in the header. The verifying domain, or recipient's domain, then uses the d= field to look up the public key from DNS, and authenticate the message. If the message is verified, the DKIM check passes.
Steps to Create, enable and disable DKIM from Microsoft 365 Defender portal
All the accepted domains of your tenant will be shown in the Microsoft 365 Defender portal under the DKIM page. If you do not see it, add your accepted domain from domains page. Once your domain is added, follow the steps as shown below to configure DKIM.
Step 1: On the DKIM page, select the domain you wish to configure.
Step 2: Slide the toggle to Enable. You will see a pop-up window stating that you need to add CNAME records.
Step 3: Copy the CNAMES shown in the pop up window
Step 4: Publish the copied CNAME records to your DNS service provider.
On your DNS provider's website, add CNAME records for DKIM that you want to enable. Make sure that the fields are set to the following values for each:
text
Host: Paste the values you copy from DKIM page. Points to address: Copy the value from DKIM page. TTL: 3600 (or your provider default) " style="box-sizing: inherit; outline-color: inherit; font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; font-size: 1em; direction: ltr; border: 0px; line-height: 1.3571; display: block; position: relative;">Record Type: CNAME (Alias) > Host: Paste the values you copy from DKIM page. Points to address: Copy the value from DKIM page. TTL: 3600 (or your provider default) Step 5: Return to DKIM page to enable DKIM.
If you see CNAME record doesn't exist error, it might be due to:
- Synchronization with DNS server, which might take few seconds to hours, if the problem persists repeat the steps again
- Check for any copy paste errors, like additional space or tabs etc.
Steps to manually upgrade your 1024-bit keys to 2048-bit DKIM encryption keys
Domains FAQ.
Since both 1024 and 2048 bitness are supported for DKIM keys, these directions will tell you how to upgrade your 1024-bit key to 2048 in Exchange Online PowerShell. The steps below are for two use-cases, please choose the one that best fits your configuration.
- When you already have DKIM configured, you rotate bitness by running the following command:
- PowerShell
" style="box-sizing: inherit; outline-color: inherit; font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; font-size: 1em; direction: ltr; border: 0px; line-height: 1.3571; display: block; position: relative;"><span>Rotate-DkimSigningConfig -KeySize 2048 -Identity <DkimSigningConfigIdParameter> </span>or - For a new implementation of DKIM, run the following command:
PowerShell-KeySize 2048 -Enabled $true " style="box-sizing: inherit; outline-color: inherit; font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; font-size: 1em; direction: ltr; border: 0px; line-height: 1.3571; display: block; position: relative;">New-DkimSigningConfig -DomainName <Domain for which config is to be created> -KeySize 2048 -Enabled $true
PowerShell
| Format-List " style="box-sizing: inherit; outline-color: inherit; font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; font-size: 1em; direction: ltr; border: 0px; line-height: 1.3571; display: block; position: relative;">Get-DkimSigningConfig -Identity <Domain for which the configuration was set> | Format-List Tip
This new 2048-bit key takes effect on the RotateOnDate, and will send emails with the 1024-bit key in the interim. After four days, you can test again with the 2048-bit key (that is, once the rotation takes effect to the second selector).
If you want to rotate to the second selector, after four days and confirming that 2048-bitness is in use, manually rotate the second selector key by using the appropriate cmdlet listed above.
For detailed syntax and parameter information, see the following articles: Rotate-DkimSigningConfig, New-DkimSigningConfig, and Get-DkimSigningConfig.
Steps to manually set up DKIM
Publish two CNAME records for your custom domain in DNS<li>Enable DKIM signing for your custom domain</li>
Publish two CNAME records for your custom domain in DNS
Connect to Exchange Online PowerShell.
Run the following commands in Exchange Online PowerShell to create the selector records:
PowerShell
-Enabled $false Get-DkimSigningConfig -Identity <domain> | Format-List Selector1CNAME, Selector2CNAME " style="box-sizing: inherit; outline-color: inherit; font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; font-size: 1em; direction: ltr; border: 0px; line-height: 1.3571; display: block; position: relative;">New-DkimSigningConfig -DomainName <domain> -Enabled $false Get-DkimSigningConfig -Identity <domain> | Format-List Selector1CNAME, Selector2CNAME </domain>If you have provisioned custom domains in addition to the initial domain in Microsoft 365, you must publish two CNAME records for each additional domain. So, if you have two domains, you must publish two additional CNAME records, and so on.Use the following format for the CNAME records.
Important
If you are one of our GCC High customers, we calculate customDomainIdentifier differently! Instead of looking up the MX record for your initialDomain to calculate customDomainIdentifier, instead we calculate it directly from the customized domain. For example, if your customized domain is "contoso.com" your customDomainIdentifier becomes "contoso-com", any periods are replaced with a dash. So, regardless of what MX record your initialDomain points to, you'll always use the above method to calculate the customDomainIdentifier to use in your CNAME records.
Console
._domainkey.<initialdomain> TTL: 3600 Host name: selector2._domainkey Points to address or value: selector2-<customdomainidentifier>._domainkey.<initialdomain> TTL: 3600 " style="box-sizing: inherit; outline-color: inherit; font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; font-size: 1em; direction: ltr; border: 0px; line-height: 1.3571; display: block; position: relative;">Host name: selector1._domainkey Points to address or value: selector1-<customDomainIdentifier>._domainkey.<initialDomain> TTL: 3600 Host name: selector2._domainkey Points to address or value: selector2-<customDomainIdentifier>._domainkey.<initialDomain> TTL: 3600 </initialdomain></customdomainidentifier></initialdomain>Where:- For Microsoft 365, the selectors will always be "selector1" or "selector2".
- customDomainIdentifier is the same as the customDomainIdentifier in the customized MX record for your custom domain that appears before mail.protection.outlook.com. For example, in the following MX record for the domain contoso.com, the customDomainIdentifier is contoso-com:contoso.com. 3600 IN MX 5 contoso-com.mail.protection.outlook.com
- initialDomain is the domain that you used when you signed up for Microsoft 365. Initial domains always end in onmicrosoft.com. For information about determining your initial domain, see Domains FAQ.
Console
Host name: selector1._domainkey Points to address or value: selector1-cohovineyard-com._domainkey.cohovineyardandwinery.onmicrosoft.com TTL: 3600 Host name: selector2._domainkey Points to address or value: selector2-cohovineyard-com._domainkey.cohovineyardandwinery.onmicrosoft.com TTL: 3600 Host name: selector1._domainkey Points to address or value: selector1-cohowinery-com._domainkey.cohovineyardandwinery.onmicrosoft.com TTL: 3600 Host name: selector2._domainkey Points to address or value: selector2-cohowinery-com._domainkey.cohovineyardandwinery.onmicrosoft.com TTL: 3600 Note
It's important to create the second record, but only one of the selectors may be available at the time of creation. In essence, the second selector might point to an address that hasn't been created yet. We still recommended that you create the second CNAME record, because your key rotation will be seamless.
Steps to enable DKIM signing for your custom domain
To enable DKIM signing for your custom domain in the Microsoft 365 Defender portal
- In the Microsoft 365 Defender portal at https://security.microsoft.com, go to Email & Collaboration > Policies & Rules > Threat policies > Email Authentication Settings in the Rules section >DKIM. To go directly to the DKIM page, use https://security.microsoft.com/dkimv2.
- On the DKIM page, select the domain by clicking on the name.
- In the details flyout that appears, change the Sign messages for this domain with DKIM signatures setting to Enabled (
)
When you're finished, click Rotate DKIM keys. - Repeat these step for each custom domain.
- If you are configuring DKIM for the first time and see the error 'No DKIM keys saved for this domain' you will have to use Windows PowerShell to enable DKIM signing as explained in the next step.
To enable DKIM signing for your custom domain by using PowerShell
Important
If you are configuring DKIM for the first time and see the error 'No DKIM keys saved for this domain' complete the command in step 2 below (for example, Set-DkimSigningConfig -Identity contoso.com -Enabled $true) to see the key.- Connect to Exchange Online PowerShell.
- Use the following syntax:PowerShell
-Enabled $true " style="box-sizing: inherit; outline-color: inherit; font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; font-size: 1em; direction: ltr; border: 0px; line-height: 1.3571; display: block; position: relative;"><span>Set-DkimSigningConfig -Identity <Domain> -Enabled $true </span><Domain> is the name of the custom domain that you want to enable DKIM signing for.
This example enables DKIM signing for the domain contoso.com:
PowerShellSet-DkimSigningConfig -Identity contoso.com -Enabled $true
To Confirm DKIM signing is configured properly for Microsoft 365
Wait a few minutes before you follow these steps to confirm that you have properly configured DKIM. This allows time for the DKIM information about the domain to be spread throughout the network.
- Send a message from an account within your Microsoft 365 DKIM-enabled domain to another email account such as outlook.com or Hotmail.com.
- Do not use an aol.com account for testing purposes. AOL may skip the DKIM check if the SPF check passes. This will nullify your test.
- Open the message and look at the header. Instructions for viewing the header for the message will vary depending on your messaging client. For instructions on viewing message headers in Outlook, see View internet message headers in Outlook.The DKIM-signed message will contain the host name and domain you defined when you published the CNAME entries. The message will look something like this example:
Console<code> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=selector1; d=contoso.com; t=1429912795; h=From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=; b=<signed>; " style="box-sizing: inherit; outline-color: inherit; font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; font-size: 1em; direction: ltr; border: 0px; line-height: 1.3571; display: block; position: relative;"> From: Example User <example@contoso.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=selector1; d=contoso.com; t=1429912795; h=From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=<body hash>; b=<signed field>; </signed> - Look for the Authentication-Results header. While each receiving service uses a slightly different format to stamp the incoming mail, the result should include something like DKIM=pass or DKIM=OK.
Important
The DKIM signature is omitted under any of the following conditions:
- The sender and recipient email addresses are in the same domain.
- The sender and recipient email addresses are in different domains that are controlled by the same organization.
Console
<code>; " style="box-sizing: inherit; outline-color: inherit; font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; font-size: 1em; direction: ltr; border: 0px; line-height: 1.3571; display: block; position: relative;"> Authentication-Results: dkim=none (message not signed) header.d=none; dmarc=none action=none header.from=<sender_domain>;
To configure DKIM for more than one custom domain
What you need to do to manually set up DKIM.
Disabling the DKIM signing policy for a custom domain
Default behavior for DKIM and Microsoft 365.
To disable the DKIM signing policy by using Windows PowerShell
- Connect to Exchange Online PowerShell.
- Run one of the following commands for each domain for which you want to disable DKIM signing.PowerShell
$p[0] | Set-DkimSigningConfig -Enabled $false " style="box-sizing: inherit; outline-color: inherit; font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; font-size: 1em; direction: ltr; border: 0px; line-height: 1.3571; display: block; position: relative;"><span>$p = Get-DkimSigningConfig -Identity <Domain> $p[0] | Set-DkimSigningConfig -Enabled $false </span>For example:
PowerShell$p = Get-DkimSigningConfig -Identity contoso.com $p[0] | Set-DkimSigningConfig -Enabled $false
Or
PowerShell].Identity -Enabled $false " style="box-sizing: inherit; outline-color: inherit; font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; font-size: 1em; direction: ltr; border: 0px; line-height: 1.3571; display: block; position: relative;">Set-DkimSigningConfig -Identity $p[<number>].Identity -Enabled $false
Where number is the index of the policy. For example:
PowerShellSet-DkimSigningConfig -Identity $p[0].Identity -Enabled $false
Default behavior for DKIM and Microsoft 365
If you do not enable DKIM, Microsoft 365 automatically creates a 2048-bit DKIM public key for your Microsoft Online Email Routing Address (MOERA)/initial domain and the associated private key which we store internally in our datacenter. By default, Microsoft 365 uses a default signing configuration for domains that do not have a policy in place. This means that if you do not set up DKIM yourself, Microsoft 365 will use its default policy and keys it creates to enable DKIM for your domain.
Also, if you disable DKIM signing on your custom domain after enabling it, after a period of time, Microsoft 365 will automatically apply the MOERA/initial domain policy for your custom domain.
In the following example, suppose that DKIM for fabrikam.com was enabled by Microsoft 365, not by the administrator of the domain. This means that the required CNAMEs do not exist in DNS. DKIM signatures for email from this domain will look something like this:
Console<code> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=selector1-fabrikam-com; d=contoso.onmicrosoft.com; t=1429912795; h=From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=; b=<signed>; " style="box-sizing: inherit; outline-color: inherit; font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; font-size: 1em; direction: ltr; border: 0px; line-height: 1.3571; display: block; position: relative;">From: Second Example <second.example@fabrikam.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=selector1-fabrikam-com; d=contoso.onmicrosoft.com; t=1429912795; h=From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=<body hash>; b=<signed field>; </signed>
In this example, the host name and domain contain the values to which the CNAME would point if DKIM-signing for fabrikam.com had been enabled by the domain administrator. Eventually, every single message sent from Microsoft 365 will be DKIM-signed. If you enable DKIM yourself, the domain will be the same as the domain in the From: address, in this case fabrikam.com. If you don't, it will not align and instead will use your organization's initial domain. For information about determining your initial domain, see Domains FAQ.
Set up DKIM so that a third-party service can send, or spoof, email on behalf of your custom domain
Some bulk email service providers, or software-as-a-service providers, let you set up DKIM keys for email that originates from their service. This requires coordination between yourself and the third-party in order to set up the necessary DNS records. Some third-party servers can have their own CNAME records with different selectors. No two organizations do it exactly the same way. Instead, the process depends entirely on the organization.
An example message showing a properly configured DKIM for contoso.com and bulkemailprovider.com might look like this:
Console
From: <sender> DKIM-Signature: s=s1024; d=contoso.com Subject: Here is a message from Bulk Email Provider's infrastructure, but with a DKIM signature authorized by contoso.com " style="box-sizing: inherit; outline-color: inherit; font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; font-size: 1em; direction: ltr; border: 0px; line-height: 1.3571; display: block; position: relative;">Return-Path: <communication@bulkemailprovider.com> From: <sender@contoso.com> DKIM-Signature: s=s1024; d=contoso.com Subject: Here is a message from Bulk Email Provider's infrastructure, but with a DKIM signature authorized by contoso.com </sender>In this example, in order to achieve this result:
- Bulk Email Provider gave Contoso a public DKIM key.
- Contoso published the DKIM key to its DNS record.
- When sending email, Bulk Email Provider signs the key with the corresponding private key. By doing so, Bulk Email Provider attached the DKIM signature to the message header.
- Receiving email systems perform a DKIM check by authenticating the DKIM-Signature d=<domain> value against the domain in the From: (5322.From) address of the message. In this example, the values match:sender@contoso.comd=contoso.com
Identify domains that do not send email
Organizations should explicitly state if a domain does not send email by specifying
v=DKIM1; p= in the DKIM record for those domains. This advises receiving email servers that there are no valid public keys for the domain, and any email claiming to be from that domain should be rejected. You should do this for each domain and subdomain using a wildcard DKIM.For example, the DKIM record would look like this:
Console
*._domainkey.SubDomainThatShouldntSendMail.contoso.com. TXT "v=DKIM1; p=" Next steps: After you set up DKIM for Microsoft 365
Set up SPF in Microsoft 365 to help prevent spoofing. For a more in-depth understanding of how Microsoft 365 uses SPF, or for troubleshooting or non-standard deployments such as hybrid deployments, start with How Microsoft 365 uses Sender Policy Framework (SPF) to prevent spoofing.
Next, see Use DMARC to validate email. Anti-spam message headers includes the syntax and header fields used by Microsoft 365 for DKIM checks.
This test will validate that the DKIM signing configuration has been configured correctly, and that the proper DNS entries have been published.
Note
This feature requires a Microsoft 365 administrator account. This feature isn't available for Microsoft 365 Government, Microsoft 365 operated by 21Vianet, or Microsoft 365 Germany.
Run Tests: DKIM
More information
Key rotation via PowerShell: Rotate-DkimSigningConfig
Use DMARC to validate email
Use trusted ARC Senders for legitimate mailflows
Recommended content
Use DMARC to validate email, setup steps - Office 365
Learn how to configure Domain-based Message Authentication, Reporting, and Conformance (DMARC) to validate messages sent from your organization, contains information on DMARC reject or OReject.Set up SPF to help prevent spoofing - Office 365
Learn how to update a Domain Name Service (DNS) record to use Sender Policy Framework (SPF) with your custom domain in Office 365.How Sender Policy Framework (SPF) prevents spoofing - Office 365
Learn how Microsoft 365 uses the Sender Policy Framework (SPF) TXT record in DNS to ensure that destination email systems trust messages sent from your custom domain.Configuring and controlling external email forwarding in Microsoft 365 - Office 365
This article covers topics including external email forwarding, Automatic forwarding, 5.7.520 Access Denied messages, disabling external forwarding, 'Your administrator has disabled external forwarding' messages, as well as outbound anti-spam policy.
Fix NDR error 5.7.700 through 5.7.750 in Exchange Online - Exchange
Learn how to fix email issues for error code 5.7.700 through 5.7.750 in Exchange Online.Remove blocked users from the Restricted users portal - Office 365
Admins can learn how to remove users from the Restricted users page in the Microsoft 365 Defender portal. Users are added to the Restricted users portal for sending outbound spam, typically as a result of account compromise.Configure outbound spam policies - Office 365
Admins can learn how to view, create, modify, and delete outbound spam policies in Exchange Online Protection (EOP).Fix 550 5.1.8 Access denied in Exchange Online - Exchange
Learn how to fix email delivery for error code 5.1.8 (550 5.1.8 Access denied) in Exchange Online (the account has been blocked for sending too much spam), when mail is not delivered.
Last updated 05/12/2023 3:42 am
Please Wait!
Please wait... it will take a second!