Set up DMARC for Microsoft 365 (Office 365)

Before you publish anything

List every domain and subdomain that appears in an outbound From address. Include Microsoft 365 mailboxes, shared mailboxes, applications, ticketing systems, marketing platforms and any outbound gateway. Each route needs its own check, because one domain's DNS record says nothing about how each sender authenticates.

Name an owner for each of these:

• The DNS zone change.
• Microsoft 365 domain and DKIM configuration.
• The shared mailbox or reporting service that receives aggregate reports.
• Test-message delivery and header inspection.
• Approval for policy changes and rollback.

Decide your rollback condition before you change policy. If a legitimate source fails DMARC after a policy increase, go back to the last known-good policy while you fix that sender.

Review any existing DMARC record before you replace it. A domain publishes one DMARC record at _dmarc, and a second TXT value there leaves receivers with an invalid or ambiguous answer.

For background on policy tags and alignment, use the Palisade DMARC learning hub.

Choose the first policy for each domain

Pick the starting policy from what the domain does:

• An active domain with known and unknown senders starts at p=none and collects evidence before enforcement.
• A registered domain that never sends mail, a parked domain, gets v=DMARC1; p=reject; once you confirm nothing legitimate uses it. Microsoft gives that record for parked domains and says the same applies to your *.onmicrosoft.com domain when you do not send from it.
• A subdomain with its own mail stream can publish its own record when it needs a separate policy or reporting address.
• A subdomain without its own record inherits the parent domain's policy. Check what each subdomain actually sends before you rely on that.

If aggregate reports go to an address in a different domain, that domain must publish an authorization record before receivers will send to it. RFC 9989 defines the check.

How to set up DMARC for a Microsoft 365 custom domain

1. Inventory the domains and production senders

Record each visible From domain with its Microsoft 365 tenant or mail route, expected SPF identity, expected DKIM signing domain, DNS owner and a test recipient.

Keep Microsoft 365 mailbox traffic separate from other senders on the same From domain. A CRM or transactional service can use your brand domain while authenticating through different infrastructure.

2. Confirm SPF and DKIM are ready

Look up the domain's published TXT records to confirm it has the intended SPF record. Then check that Microsoft 365 DKIM signing is turned on for the custom domain, so the signing d= domain aligns with your From address.

Do not merge records by guesswork. A domain has one SPF policy record and one DMARC record. Keep the existing SPF value and change it only after reviewing every authorized sender.

3. Publish a monitoring record

Create one TXT record at _dmarc.yourdomain.com. In many DNS consoles the host field takes just _dmarc, because the console appends the zone name. Check which form yours expects.

This record is an example. Replace the report address with a mailbox or reporting service your organization controls.

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

p=none asks receivers to evaluate DMARC and report, without quarantining or rejecting anything. The rua tag asks for aggregate reports. Microsoft recommends a dedicated shared mailbox or Microsoft 365 Group for them, not a person's inbox.

4. Check the published DNS answer

Query the full record name at your authoritative DNS provider and at one public resolver. The answer should hold one DMARC policy that begins with v=DMARC1, the tag that identifies a DMARC record.

dig +short TXT _dmarc.yourdomain.com

A resolver can serve cached data for a while after a change. Compare against the authoritative answer before you edit the record again.

5. Send a new message through Microsoft 365

Send a new message from the exact mailbox and custom From domain you are setting up. Deliver it to a mailbox where you can read the full headers.

Find the receiver's Authentication-Results header. RFC 8601 defines that header as the receiving system's own assertion. Look for dmarc=pass, and confirm the SPF smtp.mailfrom domain or the DKIM header.d domain aligns with header.from. A message sent before the change cannot validate it.

6. Read the reports before raising policy

Let normal traffic produce aggregate reports, then compare the sources in them with your sender inventory. Fix legitimate sources that fail alignment before you ask for enforcement. Office 365 DMARC monitoring explains how the DNS, message and report layers differ.

When the evidence is clean, change the existing record from p=none to p=quarantine and repeat the DNS, message and report checks. Microsoft's guidance also describes stepping the pct= value from 10 up to 100. The pct tag comes from RFC 7489, and RFC 9989 retires it, so receivers that follow the newer standard may ignore it, and each step still has to be driven by report evidence. Move to p=reject only after the quarantine stage stays clean.

Add DMARC for your onmicrosoft.com domain

Microsoft documents these steps for the *.onmicrosoft.com domain in its DMARC configuration guidance:

1. In the Microsoft 365 admin center, open Settings, then Domains (select Show all first if Settings is hidden).
2. Select the *.onmicrosoft.com domain, then open its DNS records tab.
3. Select Add record. Keep the type as TXT, enter _dmarc as the TXT name, and enter v=DMARC1; p=reject as the value, with a rua=mailto: address added if you want reports.
4. Leave the TTL at one hour and save.

How to validate the setup

Validation has four separate layers, and each one proves something different:

• DNS: one intended DMARC TXT record at _dmarc, the same at the authoritative service and a public resolver.
• Microsoft 365 sender state: the custom domain and DKIM configuration are the ones the production mailbox route actually uses. A green status is useful, but it is not message evidence.
• Delivered message: a new message from the production route shows an aligned SPF or DKIM pass and dmarc=pass.
• Aggregate reports: after normal traffic builds up, the sources in the reports match your sender inventory. This finds the routes a one-message test missed.

Keep a short record for each route:

from_domain: yourdomain.com
sending_route: Microsoft 365 mailbox
dns_record: v=DMARC1; p=none
delivered_message: dmarc=pass
aligned_identifier: yourdomain.com
aggregate_report_status: reviewed
policy_stage: monitoring

Troubleshooting

The DMARC record does not resolve

Check how your DNS console handles the zone suffix. Typing _dmarc.yourdomain.com into a console that appends yourdomain.com creates _dmarc.yourdomain.com.yourdomain.com. Query the full owner name and compare it with what the console shows.

Also check for more than one TXT record at _dmarc. A DMARC lookup expects exactly one policy record there.

SPF or DKIM passes but DMARC fails

That is an alignment failure. SPF is checked against the MAIL FROM domain and DKIM against the signing d= domain. Either can pass for a domain that does not match your From address, and DMARC still fails. Microsoft's own example is a third-party service that uses its bounce domain for MAIL FROM and signs DKIM with its own domain. Fix it by having the service sign DKIM with your domain, or by moving its MAIL FROM onto your domain or a subdomain.

Send another message through the same route after the fix. Do not infer alignment from a DNS record.

A header shows dmarc=bestguesspass

Microsoft adds dmarc=bestguesspass when the From domain publishes no DMARC record, and infers a result. Publish an explicit record so every receiver evaluates the same policy.

Legitimate mail fails after a policy increase

Go back to the last known-good policy while you investigate. Keep the evidence: the published record, the message headers, the route owner and the report rows. Fix the SPF, DKIM or From-domain mismatch, then retry the change.

Microsoft adds one more reason to get this right before enforcing. Outbound Microsoft 365 mail that fails DMARC at the destination, from a domain at p=quarantine or p=reject, is routed through its high-risk delivery pool, with no override. If recipients report delivery failures, compare the message evidence with Microsoft 365 outbound blocking and Microsoft 365 550 5.7.x rejections.

Aggregate reports do not arrive

Confirm the rua mailbox exists and accepts mail. If it sits in another domain, check that domain publishes the authorization record. Reports come only from receivers that send them, and Microsoft says coverage is typically 70 to 90 percent of mail volume, so an empty mailbox does not prove the record is unused or that every sender passes.

Check the record before you raise the policy

Use the Palisade DMARC checker to read the public record receivers resolve, and compare it with your intended value and a delivered message's headers before you move from monitoring to quarantine or reject.

Check your Microsoft 365 domain's DMARC record

A lookup reads public DNS only. It cannot confirm your tenant's DKIM state, the result for a specific delivered message, a receiver's future decision, or every sending route that uses the domain. For a rollout across several domains, Palisade reads the aggregate reports, names each sending source, drafts the SPF and DKIM fixes it needs, and proposes the next policy step. You review and approve each change before it ships.

Get started