How to set up DMARC for Microsoft 365

Before you start

DMARC (Domain-based Message Authentication, Reporting and Conformance) tells receiving mail servers what to do with messages that claim to come from your domain but fail authentication. It builds on two other standards: SPF, which lists the servers allowed to send for your domain, and DKIM, which adds a cryptographic signature to each message.

You'll need:

• Access to your domain's DNS, at your registrar or DNS host. Microsoft 365 can't create SPF or DMARC records for custom domains for you.
• Access to the Microsoft Defender portal, to enable DKIM.
• A list of every domain you own: domains you send email from, your yourcompany.onmicrosoft.com domain, and any domains you own but don't use for email.
• A list, even a rough one, of the services that send email as your domain: newsletter tools, CRM, helpdesk, invoicing, HR systems, website forms. The DMARC reports in step 4 will fill in the gaps.

Step 1: Set up SPF

For a domain that only sends email through Microsoft 365, create one TXT record at the root of the domain (often entered as @):

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

If other services also send as this domain, add their include: values from their documentation, before -all:

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

• One SPF record per domain. Two separate v=spf1 records cause SPF to fail with a permanent error. Merge them into one.
• Stay under 10 DNS lookups. Each include:, a, mx, exists and redirect counts, including lookups inside the services you include. Over 10, SPF fails for every message.
• Use -all. Microsoft recommends a hard fail for Microsoft 365 domains.
• Government clouds use different values: spf.protection.office365.us for GCC High and DoD, and spf.protection.partner.outlook.cn for Microsoft 365 operated by 21Vianet.

Step 2: Enable DKIM

Microsoft 365 doesn't sign email from your custom domains with your own domain until you turn DKIM on. Until then, DMARC relies on SPF alone, and SPF breaks whenever a message is forwarded.

In short: in the Defender portal, go to Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM. Publish the two CNAME records Microsoft gives you, then turn on signing. Our step-by-step DKIM guide covers every screen.

Step 3: Publish a DMARC record in monitoring mode

Create a TXT record with the host name _dmarc and this value, using an address that you or your monitoring service will read:

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

Step 4: Review your DMARC reports

Within a day or two, providers such as Google, Yahoo and Microsoft start sending daily XML reports to your rua address. Each report lists the servers that sent email as your domain, how many messages they sent, and whether SPF and DKIM passed and aligned.

Collect at least two to four weeks of reports, then look for:

• Legitimate services that fail. A newsletter tool or CRM sending as your domain without its own DKIM for your domain is the most common problem. See why third-party email fails DMARC.
• Services passing only SPF. They'll fail when their messages are forwarded. Add DKIM for them.
• Sources you don't recognize. These may be spoofing attempts, or a tool someone in your organization set up without telling IT.

You can open your reports in our free DMARC Report Analyzer. It runs in your browser and explains each sender in plain English.

Step 5: Move to quarantine, then reject

Once every legitimate sender passes DMARC consistently, tighten the policy in stages:

1. Quarantine: v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com. Failing mail goes to spam. To ease in, Microsoft suggests raising pct gradually, for example 10, 25, 50, 75, then 100.
2. Watch for two to four weeks. Check the reports and ask staff whether any expected email went missing.
3. Reject: v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com. Failing mail is refused. This is the setting that stops spoofing of your domain.

Keep receiving reports after you reach p=reject. New services get added over time, and the reports are how you'll catch them before email starts bouncing.

Don't forget onmicrosoft.com and parked domains

Your onmicrosoft.com domain

Microsoft manages SPF and DKIM for yourcompany.onmicrosoft.com, but not DMARC. If you don't send email from it, protect it with a reject policy in the Microsoft 365 admin center:

1. Go to Settings → Domains and select your onmicrosoft.com domain.
2. Open the DNS records tab and select Add record.
3. Choose type TXT, enter _dmarc as the name and v=DMARC1; p=reject as the value, then save.

Domains you don't use for email

Attackers often spoof unused domains because nobody is watching them. For each parked domain, publish:

Don't publish DKIM records for parked domains. Without a public key, forged signatures can't validate.

How Microsoft 365 handles DMARC on incoming email

DMARC also protects your users from email that spoofs other organizations. In Microsoft 365, the anti-phishing setting Honor DMARC record policy when the message is detected as spoof is turned on by default. When a message fails the sender's DMARC check:

Check the setting in the Defender portal under Threat policies → Anti-phishing. If a legitimate partner's email fails DMARC because a service in front of your mailboxes changes it, Microsoft recommends adding that service as a trusted ARC sealer rather than turning this setting off.

Outlook.com requirements for bulk senders

Since May 2025, Microsoft requires domains that send 5,000 or more messages a day to Outlook.com, Hotmail and Live.com addresses to have:

• SPF published and passing.
• DKIM published and passing.
• A DMARC record of at least p=none, with SPF or DKIM aligned to the From domain.

Messages that don't meet the requirements are rejected with 550 5.7.515 Access denied, sending domain does not meet the required authentication level. If you send newsletters or transactional email at volume, this alone is a reason to complete steps 1 to 3.

Common mistakes

• Going straight to p=reject. Without reports, you can't know which legitimate services will start bouncing.
• Two SPF records, usually after a new service tells you to "add an SPF record". Merge them into one.
• Skipping DKIM. SPF alone fails when messages are forwarded or pass through mailing lists.
• Forgetting third-party senders. They're behind most DMARC failures. Set up DKIM for your domain in each service.
• Publishing DMARC and never reading the reports. The reports are the point of p=none. Without them, you never get safely to enforcement.