---
title: "Exchange DMARC setup"
description: "Exchange DMARC setup: publish a DMARC TXT record after SPF and DKIM, validate a real Microsoft 365 message, then use reports before enforcement."
canonical: https://www.palisade.email/learning/exchange-dmarc-setup
last-updated: 2026-11-07
---
# Exchange DMARC setup

> Exchange DMARC setup: publish a DMARC TXT record after SPF and DKIM, validate a real Microsoft 365 message, then use reports before enforcement.

Exchange DMARC setup means publishing a DMARC TXT record for the custom domain that Microsoft 365 or Exchange Online sends from, after SPF and aligned DKIM are working. Start with a monitoring policy, validate DNS and a real delivered message, then review DMARC reports before moving toward quarantine or reject. For the broader policy model, see the [DMARC setup hub](/learning/dmarc).

## Quick takeaways

- Microsoft 365 custom-domain DMARC records are published at your DNS host or registrar, not in the Microsoft 365 admin center.
- DMARC passes when aligned SPF or aligned DKIM passes, and fails when both fail.
- Start with `p=none` so reports expose legitimate senders before enforcement affects mail.
- A parent-domain DMARC record covers subdomains unless a subdomain has its own DMARC record.
- A public DNS check cannot prove that Exchange Online or another production sender authenticated a delivered message.
- Move from monitoring to quarantine and then reject only after report evidence supports each change.

## Scope and prerequisites

This procedure covers an Exchange Online or Microsoft 365 custom sending domain, such as `yourdomain.com`. It does not configure inbound DMARC handling, ARC, DKIM selector generation, or a registrar-specific DNS interface.

Before editing DNS, identify the exact visible From domain used by employee mail, applications, marketing platforms, and any outbound gateways. Record the DNS zone owner, the person who can approve a rollback, a test recipient, and the report mailbox or reporting service that will receive aggregate reports.

Microsoft instructs organizations to configure SPF for all email-sending custom domains and subdomains, then configure DKIM signing with a custom domain or subdomain that aligns with the visible From domain before configuring DMARC. [Microsoft's DMARC configuration guidance](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure) also states that DMARC passes when aligned SPF or aligned DKIM passes.

If those terms are unfamiliar, read [what DMARC is](/learning/what-is-dmarc) before changing policy. DMARC evaluates a domain relationship, not only whether a sender has any SPF or DKIM record.

Set a rollback condition before publishing. Roll back the new DMARC record to the previous known-good DNS state if you discover that an essential production sender is failing DMARC and the published policy would affect that sender. Do not remove SPF or DKIM records as part of a DMARC change.

> Do not begin with `p=quarantine` or `p=reject` unless aggregate-report evidence already accounts for every legitimate sender using the domain. An enforcement policy can affect mail that fails both aligned SPF and aligned DKIM.

A message passes DMARC when SPF or DKIM passes and that passing check aligns with the visible From domain. Microsoft describes DMARC as failing only when both checks fail.

![DMARC pass logic: aligned SPF or aligned DKIM passes, otherwise the published policy applies](/images/editorial/exchange-dmarc-setup/exchange-dmarc-setup-pass-logic.webp "1200x676")

*Source: Palisade.*

## Choose the implementation approach

Choose the policy according to the evidence you have:

- Use `p=none` for an initial monitoring period. This asks receivers to apply no requested enforcement disposition while reports reveal authentication results.
- Use `p=quarantine` only after aggregate reports show legitimate production sources passing DMARC and the remaining failures are understood.
- Use `p=reject` only after the quarantine-stage evidence supports full enforcement.

Microsoft documents the policy tag as `p= reject | quarantine | none ;` and the percentage tag as `pct= 0-100 ;`. A percentage can limit the portion of failing mail to which a receiver applies the requested policy, but it does not replace sender inventory or report review.

Use a single parent-domain record when subdomains should inherit the same DMARC policy. Microsoft states that a parent-domain DMARC record automatically covers subdomains that do not have their own DMARC record. Adding a DMARC record at a subdomain stops that inheritance for that subdomain.

Treat each sending subdomain as its own authentication path. Microsoft also states that each subdomain needs its own SPF and DKIM record for DMARC. For a bulk-email service outside your direct control, Microsoft recommends using a subdomain so an issue there does not affect the main domain's sending reputation.

## How to configure Exchange DMARC

### 1. Confirm the domain that appears in From addresses

Send a new message from the Microsoft 365 path you are configuring to a test recipient. Record the domain after the `@` sign in the visible From address.

Do not assume that an accepted domain, Microsoft 365 tenant name, or return-path domain is the DMARC organizational domain. The visible From domain is the domain whose DMARC policy the receiver evaluates.

List other senders that use the same visible From domain. Include employee mail, help desk systems, applications, outbound gateways, and any third-party service. A DMARC record governs messages from the domain regardless of which system sent them.

### 2. Confirm SPF and DKIM are ready for the sending path

Verify that the Exchange Online path has an SPF record and that the sending domain has DKIM configured as Microsoft instructs. The goal is an aligned SPF or DKIM pass for the visible From domain.

A message can pass DMARC through either aligned method. That does not mean one method can be ignored. Separate senders may rely on different authentication paths, so inventory and test each material path before enforcement.

Keep existing SPF and DKIM records in place. DMARC is a separate TXT record under `_dmarc`; it is not text that should be appended to an SPF record.

### 3. Choose organization-controlled report addresses

Choose a mailbox or reporting service address that your organization controls for aggregate reports. Microsoft describes aggregate reports as periodic summaries of positive and negative DMARC results.

The destination after `rua=mailto:` must be an address you operate or have authorized. Do not copy another organization's report address from an example. If you use a reporting service, use the destination it provides for your domain and complete any authorization steps it requires.

### 4. Publish the DMARC TXT record in DNS

Microsoft says that custom-domain DMARC TXT records are managed at the domain registrar or DNS hosting service, not through Microsoft 365 admin portals or PowerShell cmdlets. Create a TXT record with the hostname `_dmarc` in the DNS zone for the visible From domain.

This is an illustrative monitoring record for `yourdomain.com`:

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

Replace `yourdomain.com` and the report address with your organization's values. Do not copy the example into production unchanged.

Microsoft's documented DMARC form requires the version tag and uses `_dmarc` as the hostname. Its examples also show policy, percentage, aggregate-report, and forensic-report tags. The exact record content should reflect the policy and reporting destinations your organization has approved.

![Illustrative DNS record shape for an Exchange Online DMARC monitoring policy](/images/editorial/exchange-dmarc-setup/exchange-dmarc-setup-records.webp "1200x533")

*Source: Palisade.*

### 5. Check the published record before changing policy

Query the fully qualified name from the authoritative DNS service and from at least one public resolver. Confirm that the answer contains one intended DMARC record and that the DNS interface did not duplicate the zone name.

Then use the [DMARC checker](/tools/dmarc) to inspect the public record before proceeding. Compare its result with the record you intended to publish.

A public record check only shows public DNS at the time of the query. It cannot prove that Exchange Online is signing mail, that every application uses the intended sending path, or that a receiving mailbox provider will make a particular delivery decision.

### 6. Leave the policy in monitoring while evidence accumulates

Keep `p=none` in place while you collect aggregate reports and investigate failures. Match report sources to the sender inventory created earlier.

If a legitimate source fails, identify whether aligned SPF, aligned DKIM, or both are failing before changing policy. A valid signature from an unrelated domain does not establish DKIM alignment for the visible From domain.

After reports show that legitimate sources pass DMARC, move in stages: monitor first, then quarantine, then reject. Gate each change on report evidence from the previous stage. Do not treat a successful DNS lookup as evidence that enforcement is safe.

## How to validate the setup

Use four separate checks. Each answers a different question.

- DNS: Query `_dmarc.yourdomain.com` at the authoritative DNS service and a public resolver. Confirm the returned record matches the approved policy and report address.
- Microsoft 365 sender state: Confirm SPF and DKIM remain configured for the exact custom domain or subdomain used in the visible From address. Microsoft's setup guidance requires both to be configured before DMARC.
- Delivered message: Send a new message through the exact Exchange Online or Microsoft 365 production path. Inspect the recipient's authentication result and confirm that the message has an aligned SPF or DKIM pass.
- DMARC reporting: Review aggregate reports after they arrive. Confirm that expected Microsoft 365 sources pass and that unexplained failures are investigated before policy enforcement.

Use a short acceptance record for each sending path:

```text
visible_from_domain: yourdomain.com
sending_path: Exchange Online employee mail
dmarc_dns_result: published record observed
spf_result: aligned pass or investigated failure
dkim_result: aligned pass or investigated failure
dmarc_result: pass or investigated failure
aggregate_report_status: expected source observed
policy_stage: none, quarantine, or reject
```

A green DNS result does not replace delivered-message evidence. A message sent before the change cannot validate the current configuration.

## Troubleshooting

### The DMARC record does not resolve

Check the record hostname and DNS provider suffix behavior. In a zone for `yourdomain.com`, entering `_dmarc.yourdomain.com` into an interface that automatically appends the zone could create the wrong name.

Compare the authoritative answer with the public-resolver answer. If they differ, investigate the DNS publication path before changing Microsoft 365 settings.

### The DMARC record exists but reports show failures

Identify the failing source from the aggregate report, then compare it with your sender inventory. Determine whether the source has an aligned SPF pass, an aligned DKIM pass, or neither.

Do not change policy until you know whether the source is legitimate. A third-party application may send with the same visible From domain while using a different authentication configuration than Exchange Online.

### Exchange Online mail passes but an application fails

Treat the application as a separate sending path. Verify its visible From domain, SPF configuration, DKIM signing domain, and alignment separately.

If the service is outside your direct control, consider the subdomain approach described in [Microsoft's DMARC guidance](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure). A subdomain can isolate that service from the main domain's policy and reputation exposure.

### A subdomain behaves differently than the parent domain

Check whether the subdomain has its own `_dmarc` record. Microsoft states that a subdomain record interrupts inheritance from the parent-domain DMARC record.

Also confirm that the subdomain has its own SPF and DKIM configuration. Parent-domain authentication records do not establish the subdomain's full sending path.

## Check the Exchange DMARC record you published

Run the sending domain through the [DMARC checker](/tools/dmarc) after publishing the record, then compare the public result with the exact DNS value and report destination you approved. This is the right next check when the immediate question is whether the DMARC record is publicly visible and structurally correct.

A passing public lookup does not prove that Exchange Online, applications, or third-party senders pass DMARC on delivered mail. It also cannot replace aggregate-report review after new sources appear or DNS changes.

For teams that need to track aggregate-report data across recurring sender changes, Palisade is agentic DMARC software that analyzes aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy step from the evidence, while a human reviews the evidence and applies the DNS change.

[Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=dmarc_troubleshooting&utm_content=exchange-dmarc-setup)

## Sources and further reading

- [Microsoft Learn: Configure DMARC for Microsoft 365](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure)
- [RFC 7489: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc7489) (historical background, marked obsolete by RFC Editor)
- [Palisade DMARC checker](/tools/dmarc)
- [How to set up DMARC](/dmarc-setup)

## Frequently asked questions

### Does Exchange Online need SPF and DKIM before DMARC?

Yes. Microsoft instructs organizations to configure SPF for all email-sending custom domains and subdomains, then configure DKIM signing with a custom domain or subdomain that aligns with the visible From domain before configuring DMARC.

### Can I create a custom-domain DMARC record in the Microsoft 365 admin center?

No. Microsoft says custom-domain DMARC TXT records are created at the domain registrar or DNS hosting service, not through Microsoft 365 admin portals or PowerShell cmdlets.

### Does a parent DMARC record apply to Exchange subdomains?

Yes. Microsoft says a parent-domain DMARC record automatically covers subdomains that do not have their own DMARC record. A DMARC record published at a subdomain interrupts that inheritance.

### Should an Exchange DMARC policy start at reject?

No. Start with `p=none` while aggregate reports identify legitimate sending sources and authentication failures. Move to quarantine and then reject only when report evidence supports each policy stage.

### Does a published DMARC record prove Exchange Online mail will pass DMARC?

No. A published DNS record proves only that the record can be retrieved. Send a new message through the production Exchange Online path and inspect its authentication result, then review aggregate reports as they accumulate.