Microsoft 365: DKIM and SPF setup

Before you start

You work in two places: the Microsoft Defender portal at https://security.microsoft.com, and the DNS settings of example.com. Microsoft's DKIM page does not name the admin role this needs.

Microsoft says it does not DKIM-sign mail from a custom domain such as example.com until you set it up. Mail from your initial *.onmicrosoft.com address is signed with that domain automatically. Each subdomain that sends mail needs its own DKIM setup.

Turn on DKIM

Microsoft 365 uses two CNAME records, one per selector. Both names are the same in every organization: selector1._domainkey and selector2._domainkey. The values are specific to your organization, so copy them from the portal.

1. In the Defender portal, go to Email & collaboration > Policies & rules > Threat policies > Email authentication settings. The direct link is https://security.microsoft.com/authentication.
2. Select the DKIM tab.
3. In the row for example.com, slide the Toggle from Disabled to Enabled. A Client error dialog opens with the record values. Select OK.
4. The Status of example.com is now CnameMissing. Click the row, not the toggle, to open its details.
5. Copy the two records in the Publish CNAMEs section. Leave the details open.
6. At your DNS host, create both CNAME records. Microsoft's example value for contoso.com is selector1-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoft. Yours carries your own domain and organization.
7. After a few minutes, return to the details and turn on Sign messages for this domain with DKIM signatures.

When Microsoft finds the records, the status reads Signing DKIM signatures for this domain. It can take a few minutes or longer for Microsoft 365 to detect them.

Sign with your own domain

Reports show mail from Microsoft 365 that is DKIM-signed by a domain other than example.com, such as your onmicrosoft.com domain. DMARC counts DKIM only when the signing domain is example.com or a subdomain of it. Turn on DKIM for example.com as in Turn on DKIM.

Check the DKIM key

Microsoft's troubleshooting section lists the common mistakes:

1. Name entered twice. Enter only selector1._domainkey as the host name. Many DNS hosts add example.com themselves, which turns a full name into selector1._domainkey.example.com.example.com.
2. Only one record. Create both selector1 and selector2. Microsoft uses the second one when it rotates the key.
3. TXT instead of CNAME. A TXT record with a public key does not work for Microsoft 365. Delete it and create the CNAME.
4. Short TTL. Microsoft recommends a TTL of at least 3600 seconds on both records.

After you select Rotate DKIM keys in the domain's details, Microsoft signs with the new key after four days, or 96 hours. Both CNAME records must stay in place.

SPF

Most Microsoft 365 organizations need include:spf.protection.outlook.com. If Microsoft 365 is the only service that sends as example.com, Microsoft documents this record:

v=spf1 include:spf.protection.outlook.com -all

Microsoft recommends -all when DKIM and DMARC are also set up. A domain may have only one SPF record. If example.com has one already, add the include to it. Microsoft notes that an SPF record needing more than 10 DNS lookups fails with a permerror, and each include needs at least one.

Check it worked

1. On the DKIM tab, the status of example.com reads Signing DKIM signatures for this domain.
2. Send a message to an address at another mail service. Microsoft advises against AOL for this test. In the message header, look for d=example.com in the DKIM-Signature field and dkim=pass in Authentication-Results.
3. Most mailbox providers send one report a day. Reports from the next 24 to 48 hours show whether DKIM aligns for Microsoft 365. The DKIM table on Mailmoni's DNS tab lists selector1 or selector2 once a report includes it.

Microsoft's pages: DKIM for your custom domain and SPF for your domain.