How do you enable DMARC for Microsoft 365?

To enable DMARC for Microsoft 365, publish a DMARC TXT record at _dmarc.yourdomain.com after SPF and DKIM are working for every Microsoft 365 custom domain or subdomain that sends mail. Microsoft recommends a gradual rollout: start with p=none, monitor reports, move to p=quarantine, then move to p=reject after legitimate mail is aligned. The change is made in DNS, not by flipping one Microsoft 365 tenant switch for an active custom domain.

Quick takeaways

• DMARC for an active Microsoft 365 custom domain is a DNS record at _dmarc, not a single Defender portal toggle.
• Microsoft says to configure SPF and DKIM for all sending custom domains and subdomains before publishing or tightening DMARC.
• Start active sending domains at p=none with aggregate reporting, then move gradually to p=quarantine and p=reject.
• Microsoft 365 DKIM for custom domains requires two CNAME records and Defender portal or Exchange Online PowerShell verification.
• Parked domains and *.onmicrosoft.com domains have separate guidance. Do not treat them like normal active custom domains.
• Validate with DNS, Microsoft DKIM status, delivered-message headers, and DMARC aggregate reports before increasing enforcement.

DMARC enforcement should follow evidence, not calendar pressure. Open the full-size Microsoft 365 DMARC rollout map.

Microsoft 365 DMARC starts with the sending domain

Microsoft's current DMARC setup guide says custom domains and subdomains should have SPF TXT records and DKIM signing configured before DMARC is configured. That matters because DMARC only passes when a message has a passing SPF or DKIM identity that aligns with the visible From domain.

Start by listing every domain and subdomain that appears in outbound From addresses:

• employee mailbox domains, such as example.com
• shared mailbox or application domains
• marketing subdomains
• transactional subdomains
• legacy domains that still send through Microsoft 365
• domains that do not send and should be treated as parked

Do not publish one aggressive parent-domain policy until you know how subdomains behave. Microsoft recommends starting with a lower-volume or less complex domain or subdomain, then saving the parent domain for last.

The guide to Microsoft's equivalent to Google Postmaster Tools is useful if you are separating Microsoft consumer-mail telemetry from Microsoft 365 tenant administration.

Prerequisites before you publish DMARC

SPF covers Microsoft 365 and other real senders

Microsoft's SPF configuration guide says SPF identifies valid email sources for a domain through a DNS TXT record. For a Microsoft 365-only custom domain in the worldwide cloud, Microsoft shows an SPF value with v=spf1, the include spf.protection.outlook.com, and an -all ending.

That example is not enough if the same domain also sends through an on-premises server, CRM, help desk, marketing platform, or cloud application. Add only the sources that actually send for that domain. Microsoft also notes that each defined subdomain requires its own SPF record and that only one SPF record is allowed per domain or subdomain.

If you are fixing a Gmail-specific SPF problem at the same time, use the Gmail SPF error diagnostic guide to confirm the exact MAIL FROM domain and connecting IP before editing DNS.

DKIM signs with the custom domain

Microsoft's DKIM guide says custom domains do not automatically DKIM sign outbound mail in the same way the initial *.onmicrosoft.com domain does. For a custom domain, Microsoft 365 generates two selector CNAME records. You publish those records at the domain's DNS host, then enable DKIM signing in the Defender portal or Exchange Online PowerShell.

Use the values Microsoft gives you for the specific domain. The DKIM article warns that example CNAME values are illustrative and that the correct values should come from the Defender portal or PowerShell. Microsoft also introduced an updated DKIM CNAME format for new custom domains in May 2025, so old examples are not a reliable source for a new tenant.

For a custom domain in the Defender portal, Microsoft describes this path:

• go to Email & collaboration > Policies & rules > Threat policies > Email authentication settings
• select the DKIM tab
• choose the custom domain or subdomain
• copy the required CNAME records
• publish both CNAMEs at the DNS host
• return after DNS is detected and enable signing

You have somewhere useful to send reports

DMARC aggregate reports are XML files. Microsoft recommends designating specific people to monitor reports and using a specific mailbox or Microsoft 365 Group rather than delivering reports to an individual user's mailbox.

For most teams, a dedicated report processor or DMARC monitoring platform is easier than a normal inbox. The important point is that someone must be able to read reports, identify legitimate sources, and decide when enforcement is safe.

How do you publish the Microsoft 365 DMARC record?

1. Choose the starting policy

For active sending domains, start with monitoring:

Example value:

• Version: v=DMARC1
• Policy: p=none
• Percent: pct=100
• Aggregate reports: rua=mailto:d@example.com

Microsoft's active-domain rollout example starts at p=none with reporting, then moves to p=quarantine, then p=reject. Use your own report address. If the report address is outside the domain, confirm any external-report authorization required by the reporting provider.

2. Add the TXT record at the DNS host

Create one TXT record at the DMARC owner name:

• Hostname: _dmarc
• TXT value: your v=DMARC1 policy
• TTL: use the DNS host's normal value unless your change-control process requires a temporary lower TTL

For example.com, the full owner name is _dmarc.example.com. For marketing.example.com, the full owner name is _dmarc.marketing.example.com.

Do not create several DMARC TXT records at the same owner name. Publish one policy for that exact domain or subdomain.

3. Monitor reports before enforcement

Microsoft says DMARC aggregate and forensic reports show numbers and sources of messages that pass and fail DMARC checks. Use the p=none phase to answer operational questions:

• Which services send as this domain?
• Which sources pass SPF or DKIM but fail alignment?
• Which sources are unknown?
• Which subdomains send mail unexpectedly?
• Which sources only fail at some receivers?
• Which legitimate senders need DKIM, SPF, or route changes before enforcement?

Do not shorten this phase just because the DNS record is syntactically valid. A valid p=none record is a starting point, not proof that p=reject is safe.

4. Move to quarantine in controlled increments

After legitimate traffic is passing aligned authentication, change the policy to quarantine:

Example value:

• Version: v=DMARC1
• Policy: p=quarantine
• Percent: pct=100
• Aggregate reports: rua=mailto:d@example.com

Microsoft notes that pct= can gradually affect more messages and gives example increments of pct=10, pct=25, pct=50, pct=75, and pct=100. Use partial enforcement when the domain is complex, the business impact is high, or a sender has just been repaired.

5. Move to reject when evidence supports it

When quarantine reports and delivered-message checks show that legitimate mail is aligned, move to reject:

Example value:

• Version: v=DMARC1
• Policy: p=reject
• Percent: pct=100
• Aggregate reports: rua=mailto:d@example.com

Microsoft describes the goal as reaching p=reject for custom domains and subdomains, but it also warns that you need to test and verify along the way to prevent good mail from being rejected because of unintended DMARC failures.

How do parked and onmicrosoft.com domains differ?

For parked custom domains that should never send mail, Microsoft's DMARC guide recommends:

v=DMARC1; p=reject;

Microsoft's SPF guide pairs parked domains with:

v=spf1 -all

Microsoft also says DKIM CNAME records are not recommended for parked domains. That makes sense: a parked domain has no legitimate outbound signing route to enable.

The .onmicrosoft.com domain is different because Microsoft owns the domain. Microsoft says the initial .onmicrosoft.com domain is already covered for SPF and automatically DKIM signs outbound messages. Microsoft now provides admin-center steps for adding a DMARC TXT record for *.onmicrosoft.com domains, with _dmarc as the TXT name and v=DMARC1; p=reject as the basic value.

Do not copy a parked-domain policy onto an active custom domain that still has unverified senders. Use the active-domain rollout for domains that send real mail.

Validate the setup

1. Check DNS for the exact domain

Query _dmarc.example.com and confirm one TXT record begins with v=DMARC1. Also confirm SPF for each active domain or subdomain and the two DKIM selector CNAME records Microsoft provided.

The free DMARC checker can inspect the public DMARC record. Use the SPF checker for SPF syntax and lookup risk. These checks prove public DNS visibility, not that a specific Microsoft 365 message is aligned.

2. Check Microsoft DKIM status

In the Defender portal, confirm that the custom domain's DKIM status shows signing enabled. In Exchange Online PowerShell, Microsoft documents Get-DkimSigningConfig with fields such as Name, Enabled, Status, Selector1CNAME, and Selector2CNAME for reviewing DKIM configuration.

Do not enable DMARC enforcement while the domain still shows missing CNAMEs or disabled DKIM unless you have another aligned authentication path and have verified it in delivered headers.

3. Send a real message through the same route

Send from the exact Microsoft 365 mailbox, shared mailbox, application, or relay route that will use the domain. Inspect a delivered message at Gmail, Outlook.com, Yahoo, or another mailbox provider that exposes authentication results.

Confirm:

• SPF passes for the expected MAIL FROM domain where that route depends on SPF
• DKIM passes with a d= domain aligned to the visible From domain
• DMARC passes for the visible From domain
• the message did not route through an unexpected gateway or third-party platform

The article on reading Authentication-Results in Gmail headers explains how to inspect those results on a delivered message.

4. Watch aggregate reports before tightening policy

Wait for DMARC aggregate reports from normal production mail. Reporting volume depends on where your mail is received and whether receivers send reports. Microsoft notes that the amount and variety of DMARC reports varies with mail volume and recipient systems.

Move policy only when the reports show legitimate sources are aligned and unknown sources are understood. If a new legitimate sender appears, fix the sender before increasing enforcement.

Palisade helps with the report-analysis part

Palisade does not publish DNS records, enable Microsoft 365 DKIM, change Defender settings, control recipient filtering, or guarantee inbox placement.

Palisade can analyze DMARC aggregate reports for domains you control. That helps IT teams and MSPs identify Microsoft 365 and non-Microsoft senders, compare SPF and DKIM alignment, find unknown sources, and decide when a domain is ready for the next policy stage.

Use the free Email Security Score to inspect public SPF and DMARC posture. If you need an ongoing workflow for sender inventory and staged DMARC enforcement across domains or clients, start a Palisade account after your first Microsoft 365 domain is reporting.

Frequently asked questions

Is there a Microsoft 365 switch that enables DMARC?

Not for an active custom domain. You publish a DMARC TXT record in DNS. Microsoft 365 provides SPF, DKIM, and admin-center guidance, but the active custom-domain DMARC policy lives at _dmarc.yourdomain.com.

Should I start Microsoft 365 DMARC at p=reject?

No, not for an active sending domain unless you have already verified every legitimate source and alignment path. Microsoft recommends starting with p=none, monitoring, moving to p=quarantine, and then moving to p=reject.

Do I need DKIM before DMARC in Microsoft 365?

Usually yes. Microsoft says custom domains should have SPF and DKIM configured before DMARC. DKIM is especially important when forwarding, gateways, or third-party senders make SPF alignment fragile.

What DMARC record should I use for a parked Microsoft 365 domain?

For a parked domain that should not send mail, Microsoft recommends v=DMARC1; p=reject;. Pair it with an SPF record such as v=spf1 -all, and do not add DKIM CNAMEs for a domain that has no legitimate sending route.

Does Microsoft 365 send DMARC reports for every message?

No. DMARC reports depend on destination email systems and normal mail volume. Microsoft notes that the amount and variety of reports varies. Treat aggregate reports as operational evidence over time, not as a complete per-message log.

Will DMARC improve Microsoft 365 deliverability?

Stronger SPF, DKIM, and DMARC help receivers trust authorized domain use and reduce spoofing risk. They do not guarantee inbox placement. Microsoft says delivery is not guaranteed even when mail is authenticated.