Microsoft 365 SPF, DKIM and DMARC: configure and verify your domain

For a Microsoft 365 custom domain you publish three things at your DNS host: one SPF TXT record, which for most Microsoft 365 organizations includes spf.protection.outlook.com, the two DKIM CNAME records your own tenant generates, and a DMARC TXT record at _dmarc. Then you switch on DKIM signing in the Defender portal. Microsoft documents each one as a method of email authentication: Sender Policy Framework (SPF)↗ (opens in a new tab), DomainKeys Identified Mail (DKIM)↗ (opens in a new tab) and Domain-based Message Authentication, Reporting, and Conformance (DMARC)↗ (opens in a new tab). Take the DKIM targets from your own tenant: the values in Microsoft's article are for illustration only.

Custom domain or onmicrosoft.com#

What you have to do depends on the domain in your From address.

The SPF row comes from Microsoft's SPF setup article↗ (opens in a new tab), the DKIM row from Microsoft's DKIM setup article↗ (opens in a new tab) and the DMARC row from Microsoft's DMARC setup article↗ (opens in a new tab). Microsoft calls each of SPF and DKIM alone not enough, and for DMARC on a custom domain it asks you to set up SPF and DKIM signing for every custom domain and subdomain you send from first.

Step 1: list every sender, then write one SPF record#

As Microsoft's SPF setup article↗ (opens in a new tab) explains, Microsoft 365 has no admin portal or PowerShell cmdlet for managing SPF records: you create the SPF TXT record at your domain registrar or DNS hosting service. If Microsoft 365 is your only source of email, the record in Microsoft 365 and Microsoft 365 Government Community Cloud (GCC) is:

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

Microsoft lists other includes for other clouds: spf.protection.office365.us for GCC High and DoD, and spf.protection.partner.outlook.cn for Microsoft 365 operated by 21Vianet. Checked against live DNS, spf.protection.outlook.com publishes only ip4 and ip6 ranges and ends in -all, with no further include.

Before you write the record, list every service that sends as your domain. Other non-Microsoft email services often need their own include: value, and IP addresses in the record are typically for on-premises servers, such as Exchange Server hybrid deployments, though some non-Microsoft services also use an IP address range instead of an include:. For example, if one other service used include:spf.example.net, the record would be:

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

Rules that apply whatever you add:

• One record per name. Multiple SPF TXT records on the same domain or subdomain make SPF return permerror.
• Ten lookups at most. Above 10 DNS lookups the message fails SPF with a permanent error. IP addresses and ranges cost none; each include: costs at least one, and might need more when it points to nested records. SPF too many DNS lookups covers which terms count and how to fix it.
• Each sending subdomain needs its own record. Microsoft recommends a subdomain such as marketing.example.com for services that are not under your direct control.
• End with -all. Microsoft recommends hard fail for Microsoft 365 domains because it also recommends DKIM and DMARC.

Step 2: get both DKIM CNAMEs from your tenant, then turn on signing#

As Microsoft's DKIM setup article↗ (opens in a new tab) explains, Microsoft 365 uses CNAME records in your DNS that point to the public keys used to verify the DKIM signature. Two key pairs are generated for each custom domain; only one selector is active, and the other is used only after a future key rotation. You create two CNAME records in each custom domain.

The host names are the same for every organization: selector1._domainkey and selector2._domainkey. Fill in this worksheet from your tenant:

Here <CustomDomainWithDashes> is your custom domain with periods replaced by dashes, <InitialDomainPrefix> is the custom part of the *.onmicrosoft.com domain you enrolled with, and <DynamicPartitionCharacter> is a dynamically generated character, such as r or n, that Microsoft assigns when you add a new custom domain and enable DKIM. That format is for new custom domains since May 2025; existing custom domains and initial domains keep the old format. The old and new formats can't coexist for the same selector. Checked against live DNS, selector1._domainkey.microsoft.com points to selector1-microsoft-com._domainkey.microsoft.onmicrosoft.com, the old format. The values in Microsoft's article are for illustration only; read yours in the Defender portal or with Exchange Online PowerShell:

Get-DkimSigningConfig -Identity example.com | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME

The order in the Defender portal:

1. Add the domain to Microsoft 365 first; only then can it DKIM sign outbound mail.
2. Go to Email & collaboration > Policies & rules > Threat policies > Email authentication settings, and select the DKIM tab.
3. Try to slide the domain's Toggle value from Disabled to Enabled. A Client error dialog opens with the two CNAME values; select OK. The domain's status is now CnameMissing.
4. Click anywhere in the domain's row, other than the check box or the toggle, to open its details flyout, and copy the values from the Publish CNAMEs section.
5. At your domain registrar or DNS host, create the two CNAME records.
6. Wait: Microsoft 365 takes a few minutes, or longer, to detect them. Then select Sign messages for this domain with DKIM signatures. The status changes to Signing DKIM signatures for this domain.

Each subdomain you send from needs its own DKIM configuration.

Step 3: publish DMARC, starting at p=none#

Microsoft's DMARC setup article↗ (opens in a new tab) enables DMARC with a TXT record in DNS, and the host name _dmarc is required. Microsoft recommends a gradual approach: start with p=none and monitor the results, then increase to p=quarantine and monitor again. p=none gives no suggested action for failing messages and is the value for testing and tuning. A starting record from the DMARC record generator, which starts by monitoring with a reporting address:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

The rua=mailto: value is where the aggregate reports go; they typically arrive once per day and cover the previous day. Microsoft suggests a specific mailbox or Microsoft 365 Group for them, not a user's mailbox. The record also covers every subdomain without its own DMARC record, including nonexistent ones.

Move to enforcement only once the reports show your real senders pass. One Microsoft-specific effect: outbound mail from Microsoft 365 that fails DMARC at the destination is routed through the High-risk delivery pool when your policy is p=reject or p=quarantine. DMARC policy not enabled covers whether p=none affects delivery and the safe order to move to quarantine or reject.

Verify: the DNS and a real message#

The two checks answer different questions.

DNS. The SPF, DKIM and DMARC check is a free one-off check of the records your domain publishes, with no account needed. For SPF it flags a missing record, +all, ?all, ~all, and a record close to or over the 10 DNS lookup limit; for DMARC it flags a missing record, a policy of none, no reporting address, a policy covering only part of your email, and subdomains left at none. For DKIM it looks for keys under commonly used selectors; SPF and DMARC details show straight away, and the DKIM details appear after you add your email address. A DNS finding shows how your domain is set up; it does not show where a particular message landed.

A message. Microsoft's DKIM setup article↗ (opens in a new tab) tests signing with a message from your DKIM-enabled domain to a recipient in another email system. In the received message's header, find the DKIM-Signature field: its d= value is the domain that signed the message. The Authentication-Results field should include DKIM=pass or DKIM=OK. DKIM passes DMARC only if the signing domain and the From domain align. Under Microsoft's DMARC setup article↗ (opens in a new tab), a message passes DMARC if one or both of the SPF and DKIM checks pass, where each check includes alignment with the domain in the From address.

When the header shows a failure, DKIM fail explains how to read the reason in brackets, and DMARC fail how to read dmarc=fail in the Authentication-Results header.

Troubleshooting#

• Status stuck at CnameMissing. In Microsoft's DKIM setup article↗ (opens in a new tab), the DKIM tab shows this status after you try to slide the toggle to Enabled and select OK in the Client error dialog. Create both CNAME records with the values from Publish CNAMEs, then allow a few minutes, or longer, for Microsoft 365 to detect them.
• A test message carries no DKIM signature. Microsoft omits the signature when sender and recipient are in the same domain, or in different domains controlled by the same organization. Test with a recipient in another email system.
• A DKIM record copied from another domain or an article. The old and new formats can't coexist for the same selector, and the article's values are for illustration only. Read the values for this domain from your tenant.
• SPF permerror. Microsoft's SPF setup article↗ (opens in a new tab) lists causes of a permanent error that include two SPF records on one name, more than 10 DNS lookups, and an include: domain that doesn't resolve or has no SPF record. Keep one record, check each include: domain, and see SPF too many DNS lookups for the lookup limit.

Sources#

• Microsoft Learn: Set up SPF to identify valid email sources for your custom cloud domains↗ (opens in a new tab)
• Microsoft Learn: Set up DKIM to sign mail from your cloud domain↗ (opens in a new tab)
• Microsoft Learn: Set up DMARC to validate the From address domain for cloud senders↗ (opens in a new tab)