SPF, DKIM and DMARC for Microsoft 365, explained

Email can be sent with any domain in the From address, including one that belongs to someone else. SPF, DKIM and DMARC are the standards that let receiving email systems check whether a message really came from the domain it claims, and decide what to do when it didn’t. This page explains how Microsoft’s documentation describes SPF, DKIM and DMARC for Microsoft 365, and the order it describes for setting them up. How phishing works, including spoofed “From” lines covers what this looks like from the recipient’s side.

What each one does

SPF (Sender Policy Framework) is a DNS TXT record identifying valid sources of mail for a domain. Microsoft notes that each domain and subdomain needs its own SPF record, because subdomains don’t inherit the parent’s. Microsoft’s documentation notes two limits: SPF checks only the domain in the hidden “MAIL FROM” address, not the From address people see, and it breaks when messages go through server-based forwarding, because the forwarding server isn’t authorised to send for the original domain.

DKIM (DomainKeys Identified Mail) uses a domain to digitally sign important parts of a message, including the From address. Microsoft explains that the receiving server verifies the signed parts weren’t altered. Microsoft also notes that the signing domain doesn’t have to match the From address shown in email clients.

DMARC (Domain-based Message Authentication, Reporting and Conformance) uses SPF and DKIM to check for alignment between the MAIL FROM and From domains. A DMARC record also says what receiving systems are to do with messages that fail (nothing, quarantine or reject), and where reports go.

Microsoft describes the three as “interdependent building blocks that work together”, and states that “anything less than all of the email authentication methods results in substandard protection”.

How they fit together

The order Microsoft describes for custom domains

Microsoft’s “How email authentication works” page describes these steps for a custom domain, such as yourbusiness.example:

1. Publish an SPF record containing all the email sources you know about, using the “soft fail” value (~all).
2. Discover other sources, such as on-premises servers, software-as-a-service providers and cloud-hosting services, then update the SPF record to “hard fail” (-all).
3. Set up DKIM to digitally sign messages.
4. Set up DMARC to check that the MAIL FROM and From domains match, to say what happens to messages that fail, and to identify reporting services.
5. Where bulk senders send on the domain’s behalf, verify that the From domain matches the domain that passes SPF or DMARC.

Microsoft’s DMARC page adds that SPF and DKIM are configured for each custom domain before DMARC, and that for email services outside your direct control, such as bulk email services, Microsoft’s documentation describes using a subdomain (for example, marketing.yourbusiness.example) instead of the main domain.

How to turn on DKIM for a custom domain

Microsoft’s DKIM page states: “Currently, no DKIM signing occurs for outbound mail from custom domains.” Mail from the onmicrosoft.com domain is signed automatically.

Based on Microsoft’s instructions (checked October 2026). Menus can change; Microsoft’s DKIM page has the latest steps.

1. In the Microsoft Defender portal (security.microsoft.com), go to Email & collaboration > Policies & rules > Threat policies > Email authentication settings, and select the DKIM tab.
2. In the row for the custom domain, slide the Toggle to Enabled. Microsoft says an error dialog then shows the CNAME details and the status changes to CnameMissing; select OK.
3. Select the domain’s row to open its details, and copy the two values under Publish CNAMEs.
4. At the DNS host, create two CNAME records with the hostnames selector1._domainkey and selector2._domainkey, pointing to those values. Microsoft says to copy the values from the portal rather than from its examples.
5. After the records are detected, reopen the domain’s details and turn on Sign messages for this domain with DKIM signatures. The status shows Signing DKIM signatures for this domain when it’s working.

Microsoft’s described DMARC rollout

Microsoft’s DMARC documentation describes a gradual rollout:

1. Start with a policy of p=none and monitor the results.
2. Move to p=quarantine and monitor. Microsoft notes that the pct= value can phase this in, for example 10, 25, 50, 75 and then 100 percent.
3. Move to p=reject and monitor.
4. Repeat for the remaining subdomains of increasing volume or complexity, saving the parent domain for last.

A DMARC record is a DNS TXT record at the hostname _dmarc. Based on Microsoft’s example syntax, a finished record might look like this:

v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-reports@yourbusiness.example

The rua address receives aggregate reports, which Microsoft says are typically sent once a day. Microsoft’s documentation describes designating specific people to monitor them, and using a specific mailbox or Microsoft 365 Group rather than a user’s own mailbox. The shared mailbox security guide explains how Microsoft describes shared mailboxes. Microsoft states there are no admin portals or PowerShell cmdlets in Microsoft 365 for DMARC records on custom domains; they are created at the domain registrar or DNS hosting service.

Two kinds of domain Microsoft addresses separately

The onmicrosoft.com domain. Every tenant has one. Microsoft states that SPF and DKIM are already configured for it, but that the DMARC TXT record for it is created in the Microsoft 365 admin center.

Based on Microsoft’s instructions (checked October 2026). Menus can change; Microsoft’s DMARC page has the latest steps.

1. In the Microsoft 365 admin center, select Show all > Settings > Domains.
2. Select the onmicrosoft.com domain, then open the DNS records tab.
3. Select Add record, check that TXT (Text) is selected, enter _dmarc as the TXT name and Microsoft’s example value v=DMARC1; p=reject as the TXT value, and leave the TTL at 1 hour.
4. Save the record.

Parked domains. For registered domains that no one expects to receive mail from, such as old brand names, Microsoft’s DMARC documentation describes a record of v=DMARC1; p=reject;, and its SPF documentation describes an SPF record of v=spf1 -all to indicate that no email should come from the domain. Microsoft’s DMARC page adds that the parked-domain DMARC record also applies to the onmicrosoft.com domain if it isn’t used for email.

Issues Microsoft’s documentation highlights

• More than one SPF record. Microsoft states that only one SPF record is allowed per domain or subdomain, and that multiple records cause SPF to return a permanent error (permerror).
• Too many DNS lookups. Microsoft states that if an SPF record needs more than 10 DNS lookups, the message fails SPF with a permanent error. Each include: statement needs at least one lookup.
• Senders that weren’t included. Microsoft’s staged approach starts with soft fail because many organisations don’t know all the sources of email for their domain.
• Forwarding and services that modify messages. Microsoft notes that legitimate services that change messages in transit, and automatic forwarding between organisations, can cause SPF, DKIM or DMARC checks to fail. How Microsoft describes automatic external forwarding settings covers the forwarding controls in Exchange Online.
• Reports nobody reads. Microsoft’s documentation describes sending reports to a dedicated mailbox or group monitored by designated people.

Common questions

What are SPF, DKIM and DMARC?

They’re email authentication standards that let receiving systems check whether a message really came from the domain it claims. SPF lists valid sources of mail for a domain, DKIM digitally signs parts of a message, and DMARC checks that the domains align and says what happens to messages that fail. Microsoft describes them as “interdependent building blocks that work together”. What each one does explains each.

Do I need SPF, DKIM and DMARC for Microsoft 365?

Microsoft states that “anything less than all of the email authentication methods results in substandard protection”. For a custom domain, Microsoft’s documentation describes setting up SPF first, then DKIM, then DMARC. The onmicrosoft.com domain already has SPF and DKIM configured, according to Microsoft, but its DMARC record is created in the Microsoft 365 admin center. The order Microsoft describes for custom domains has the steps.

How do I set up DMARC in Microsoft 365?

For a custom domain, Microsoft states there are no admin portals or PowerShell cmdlets in Microsoft 365 for DMARC records; they’re created as a TXT record at _dmarc with the domain registrar or DNS host. Microsoft describes starting at p=none, moving to p=quarantine and then p=reject, monitoring at each stage. Microsoft’s described DMARC rollout shows an example record.

Is DKIM turned on by default for my domain?

Not for custom domains. Microsoft’s DKIM page states: “Currently, no DKIM signing occurs for outbound mail from custom domains.” Mail from the onmicrosoft.com domain is signed automatically. Microsoft’s steps involve enabling DKIM for the domain in the Defender portal, publishing two CNAME records at the DNS host, and then turning on signing. How to turn on DKIM for a custom domain lists each step.

What DMARC record do I need for a domain that doesn’t send email?

For parked domains that no one expects to receive mail from, Microsoft’s DMARC documentation describes a record of v=DMARC1; p=reject;, and its SPF documentation describes v=spf1 -all to indicate no email should come from the domain. Microsoft says the parked-domain DMARC record also applies to an onmicrosoft.com domain that isn’t used for email. See two kinds of domain Microsoft addresses separately.

What happens if my domain has two SPF records?

Microsoft states that only one SPF record is allowed per domain or subdomain, and that multiple records cause SPF to return a permanent error (permerror). Microsoft also states that an SPF record needing more than 10 DNS lookups fails with a permanent error, and each include: statement needs at least one lookup. Issues Microsoft’s documentation highlights lists other common problems.

Related guides

• Business email compromise explained
• Microsoft 365 security checklist: the settings Microsoft’s guidance covers