How to set up DMARC in Microsoft 365 (and move safely to enforcement)

DMARC tells receiving servers what to do with email that fails authentication, and it shows you when that happens. It’s the layer that sits on top of SPF and DKIM, which is why it’s usually the last of the three you set up. It’s also the part most likely to backfire if you rush it, because too strict a setting too soon can push legitimate mail into spam or get it rejected.

Delaying isn’t an option either. Google and Yahoo have required a DMARC policy from bulk senders since February 2024, and Microsoft followed in May 2025, now rejecting non-compliant bulk mail to its consumer domains rather than routing it to junk. For a Microsoft 365 admin, that means your own provider now turns unauthenticated bulk mail away. Even so, Exclaimer’s State of Business Email 2025 research found fewer than a third of organizations have SPF, DKIM, or DMARC in place.

This is the third guide in a trio, after setting up an SPF record in Microsoft 365 and DKIM setup in Microsoft 365. It explains what DMARC is and how it builds on the other two, breaks down the three policy levels and when to use each, walks through publishing your record, shows how to read the reports it sends back, and lays out how to move from monitoring to full enforcement without disrupting mail flow.

What is DMARC and how does it work?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email authentication standard that builds on SPF and DKIM. It tells receiving servers what to do with mail that fails those checks, and it reports back to the domain owner on how the domain is being used.

When a message arrives, the receiving server runs SPF and DKIM, then applies DMARC. DMARC adds three things the other two lack:

• A policy that tells the receiving server whether to deliver, quarantine, or reject mail that fails authentication.

• Reporting that sends the results back to you, so you can see what’s passing and what isn’t.

• Alignment, which ties the authenticated domain to the one your recipients actually see in the From address.

That reporting loop is what makes DMARC useful before you enforce anything. Even at its lowest setting, it shows you every source sending mail as your domain, which is exactly what you need to reach enforcement safely.

How DMARC builds on SPF and DKIM

SPF and DKIM each handle one check. SPF lists the servers authorized to send for your domain, so a receiving server can confirm a message came from one of them. DKIM adds a signature that proves the message wasn’t altered between sending and delivery.

But SPF and DKIM both share a blind spot. They validate domains the recipient never sees: the return-path for SPF and the signing domain for DKIM. Neither validates the From address shown in the receiver’s inbox. That’s the gap DMARC closes.

What DMARC protects against

DMARC protects your From domain from spoofing. It stops someone passing authentication on their own infrastructure while displaying your domain in the From address.

This matters because recipients act on the From name they see. They reply to it, click its links, and pay invoices against it. Enforced DMARC means only senders authorized on your domain can clear the check, so an impersonator can’t trade on the trust your domain has built.

Its reach has limits, though. DMARC doesn’t encrypt mail, and it doesn’t stop every kind of impersonation. Lookalike domains, where an attacker registers an address close to yours, fall outside its scope, because that mail is genuinely sent from a domain the attacker controls.

Why DMARC is now mandatory for bulk senders (Google, Yahoo, and Microsoft)

For bulk senders, DMARC is effectively mandatory. Google, Yahoo, and Microsoft now reject or filter high-volume mail that arrives without a DMARC policy, so a message from a non-compliant domain may never reach the inbox at all.

Non-compliant bulk mail no longer just lands in spam. Google and Yahoo began enforcing shared bulk-sender rules in February 2024, and Microsoft applied the same expectations to its consumer domains from May 2025. Google and Microsoft now return permanent rejection errors at the SMTP level, which means the message bounces back to the sender and never reaches the recipient, spam folder included. If you run a Microsoft 365 tenant, Microsoft’s move is the one closest to home, since it’s your own mail provider turning that mail away.

Bulk sender has a specific meaning. Google and Yahoo define it as any domain sending roughly 5,000 or more messages a day to their consumer inboxes. The threshold is measured per domain, and once you cross it the label sticks even if your volume later drops, so a single large campaign can classify you for good.

The mandated minimum is modest: a DMARC policy of p=none with alignment. But 2026 guidance across the major providers already points past that toward p=reject as the real target, which is the journey the rest of this guide walks through.

The three DMARC policy levels: none, quarantine, and reject

DMARC has three policy levels, set with the p tag in your record. p=none monitors without affecting delivery, p=quarantine sends failing mail to spam, and p=reject blocks it. They’re designed to be used in sequence, from none to reject.

The policy you publish tells receiving servers what to do with mail that fails DMARC. You work through the three levels in order, monitoring first and tightening only once your reports show that legitimate mail passes. Advancing before that point can break mail flow.

p=none: monitor without affecting delivery

At p=none, nothing changes for your recipients. Mail that fails DMARC is still delivered normally, while receiving servers send you reports on what passed and what failed. Every DMARC rollout begins here.

The point of p=none is visibility. Your reports reveal every source sending mail as your domain, including ones you’d forgotten or never knew about: a marketing platform, a helpdesk tool, an invoicing system. Use that picture to bring each legitimate sender into alignment before enforcing anything.

The common mistake is stopping here: p=none offers no protection of its own, because failing mail still gets delivered, so a domain parked at none is monitored but not defended.

p=quarantine: send failing mail to spam

At p=quarantine, mail that fails DMARC is routed to the recipient’s spam or junk folder instead of the inbox. It’s the middle setting, and its value is that it’s recoverable. A legitimate sender you overlooked will have its mail filtered rather than lost, so recipients can still retrieve it while you fix the alignment problem.

That safety margin is why quarantine is worth a deliberate stop, not a level you skip on the way to reject. Many teams treat quarantine as a monitoring checkpoint of its own, watching reports here before committing to reject.

p=reject: block failing mail

p=reject tells receiving servers to refuse any mail that fails DMARC outright. It’s the enforcement level that meets bulk-sender requirements in full and gives your domain its strongest protection against spoofing.

At p=reject, failing mail isn’t delivered at all, to inbox or spam. This is full enforcement: unauthorized use of your domain is stopped at the receiving server, and you meet what Google, Yahoo, and Microsoft require of bulk senders.

The catch is that reject is unforgiving of gaps. Any legitimate sender still failing alignment when you switch over will have its mail bounced, which is how invoices and password resets go missing. That’s why you move here only after your reports show every legitimate source passing and aligned.

How to create a DMARC record in Microsoft 365

DMARC is published as a single DNS TXT record at _dmarc on your domain. Microsoft 365 doesn’t generate it for you the way it does DKIM, so you write the record yourself, add it at your DNS host, and start with a monitoring policy.

A minimal starting record looks like this:

v=DMARC1; p=none; rua=mailto:[email protected]

This is the right first record for a domain new to DMARC, because it turns on reporting without affecting delivery. From there you add or adjust tags as you move toward enforcement.

DMARC record tags explained

The record is a set of tags separated by semicolons, read left to right. Only two are required, v and p, while the rest control reporting, subdomains, and rollout behavior.

A note on the last three. DMARCbis, published as RFC 9989 in May 2026, deprecated pct and added np and t. Existing v=DMARC1 records keep working, so there’s no need to rewrite them, but a record you build today should leave out pct and use t=y when you want to flag a policy as provisional.

Publishing the record at your DNS host

Add a new TXT record at your DNS provider with the host or name set to dmarc. Some providers want the full dmarc.yourdomain.com, while others append your domain automatically, so check how yours behaves. Paste your record as the value and set the TTL to 3600 seconds.

This record sits alongside the other DNS entries that route and authenticate your mail, including your MX record and SPF record. Propagation usually takes minutes, though it can run to a few hours. Once the record resolves, a DMARC checker confirms it’s valid and readable, and aggregate reports begin arriving at the rua address within a day or so.

How to read DMARC aggregate reports (rua)

DMARC aggregate reports are XML files that receiving servers send to your rua address, usually once a day. Each one summarizes the mail seen from your domain: the sending IP addresses, how much mail each sent, and whether it passed SPF, DKIM, and DMARC alignment.

Each report comes from a single receiver, such as Google, Yahoo, or Microsoft, and covers a set window, typically 24 hours. Inside, the mail is grouped by sending source. For each source you get the IP address, the message volume, the domain in the From address, and the pass or fail result for SPF, DKIM, and alignment.

Read across those fields and a picture forms: this IP is my Microsoft 365 tenant and it passes, this one is my marketing platform and it fails alignment, this one I don’t recognize at all. That picture is the whole point of starting at p=none, and it’s what you work from for the rest of the rollout.

Making sense of the XML

Raw aggregate reports aren’t built for human eyes. The XML is repetitive and machine-oriented, and a busy domain can generate dozens a day from different receivers, far too many to read by hand.

A DMARC report parser handles this for you. These tools ingest the XML and turn it into a readable dashboard, grouping sources, resolving IP addresses to recognizable names, and flagging what’s failing. Options range from open-source parsers you can self-host to commercial services, several of which have free or low-cost tiers at the volumes a typical organization produces. Whichever you pick, the job is the same: turn a pile of XML into a list of senders you can act on.

What to look for before you tighten your policy

Your goal is to account for every legitimate source. Work through the sending IPs until you can name each one that should be sending as your domain, and confirm each passes SPF or DKIM with alignment. The unknowns sort into two kinds: legitimate services you’d overlooked, which you bring into alignment, and genuine spoofing, which your enforcement policy will later stop.

You’re ready to move past p=none when the reports show every legitimate sender authenticated and aligned, with nothing left failing that you can’t explain.

Moving safely from p=none to p=reject

You reach p=reject in stages, not in one move. Start at p=none to see who’s sending as your domain, fix every legitimate source until it passes and aligns, then step up through quarantine to reject as your reports confirm nothing legitimate is failing.

This is the part of DMARC that goes wrong most often, almost always for the same reason: someone jumps to enforcement before the reports say it’s safe. Each policy level is a stage of the rollout, and your reports tell you when you’ve finished one and can move to the next.

With DMARCbis removing the pct tag, there’s no in-protocol dial to phase the policy in a percentage at a time. The rollout is managed operationally instead, by reading your reports and stepping up only when they’re clean.

Phase 1: monitor with p=none

Publish p=none with a rua address and leave it in place long enough to see a full cycle of your mail, including anything that runs weekly or monthly, such as payroll, billing, or a quarterly newsletter. A few weeks is typical, and longer is sensible if your sending is seasonal.

Use that time to build a complete list of legitimate senders and bring each one into alignment. You leave phase 1 when your reports account for every legitimate source and each one passes and aligns.

Phase 2: step up to p=quarantine

Move to p=quarantine once the reports are clean. Failing mail now goes to spam rather than the inbox, so a legitimate sender you missed is still recoverable.

Stay here and keep reading reports, watching for anything that starts failing that phase 1 didn’t surface: a newly added SaaS tool, a forgotten subdomain, a sender that changed its infrastructure. When quarantine runs clean for a couple of weeks with no surprises, you’re ready for the final step.

Phase 3: move to p=reject

Change the policy to p=reject. Failing mail is refused outright, your domain meets bulk-sender requirements in full, and unauthorized senders can no longer get mail delivered under your name.

Reaching reject doesn’t end the work. New sending sources appear over time, and any that fails alignment will now be blocked, so the rua reports that got you here are the same ones that keep you safe. Check them periodically, and treat a new failure as something to investigate rather than ignore.

DMARC alignment: strict vs. relaxed

Alignment is the check that makes DMARC work. It requires that the domain validated by SPF or DKIM matches the domain in your visible From address. A message can pass SPF or DKIM and still fail DMARC if neither one aligns with the From domain.

The reason is that authentication and alignment answer different questions. Authentication confirms a message is legitimate; alignment confirms it’s legitimate for the domain in the From address. DMARC asks both, which is where it catches people out, because a message can clearly pass one and quietly fail the other.

The saving grace is that DMARC needs only one of the two to align. If either SPF or DKIM aligns with the From domain, DMARC passes. Getting DKIM aligned tends to be the more dependable route, because a valid DKIM signature survives the forwarding and routing changes that routinely break SPF.

SPF alignment vs. DKIM alignment

The two align on different things. SPF alignment compares the From domain against the return-path, the hidden envelope address SPF checks. DKIM alignment compares the From domain against the domain in the DKIM signature. Each supports two modes.

Relaxed alignment, the default, treats a domain and its subdomains as a match, so a message from mail.yourdomain.com aligns with a From address at yourdomain.com. Strict alignment demands an exact match, with no subdomain flexibility. Most organizations use relaxed, since it accommodates normal subdomain use without giving up the protection that counts.

Common alignment failures

Most DMARC failures aren’t spoofing. They’re legitimate mail that authenticates on a different domain than the one in the From address, most often mail sent by a third-party service on your behalf.

Three patterns cause most alignment failures:

• Third-party senders. A marketing platform, help desk, or CRM sends as your domain but signs with its own, so DKIM authenticates against the vendor’s domain and never aligns with yours. This is the most common failure of the three, and the subject of the next section.

• Subdomains. Mail from a subdomain fails because the policy or sending setup doesn’t account for it, or because strict alignment is in force where relaxed was needed.

• Forwarding. A forwarded message changes sending server, which breaks SPF. A message with an aligned DKIM signature still passes, which is why DKIM alignment is worth prioritizing.

These are configuration problems, not attacks. Each is a legitimate source you bring into alignment during phase 1, before enforcement makes a failure consequential.

Third-party senders and DMARC alignment

A third-party tool that sends mail on your behalf can fail DMARC alignment if it sends from its own domain rather than yours. How a tool handles sending decides whether it aligns, so check any service that mails as your brand before you reach enforcement.

Most tools that send on your behalf, from marketing platforms to CRMs to help desks, route mail through their own infrastructure and sign it with their own domain. You authorize that mail by adding the vendor’s domain to your SPF record, and it authenticates, but it authenticates on the vendor’s domain rather than yours. Unless the vendor supports alignment to a custom domain, DMARC fails the moment you enforce, which is why the move to p=reject so often surfaces a sending tool nobody had flagged.

Email signature tools sit in your outbound mail flow, so they’re worth checking closely. The question is whether the tool sends from a domain of its own or works within your existing Microsoft 365 mail flow.

Exclaimer’s cloud solution does the latter. It applies email signatures as mail passes through the flow, then hands the message back to Microsoft 365 to sign and send, so no separate sending domain is introduced. The signature step strips the DKIM signature on receipt and lets Microsoft 365 re-apply it after the email signature is added and before delivery. Because Microsoft signs the final message on your domain, DKIM stays aligned to your From address and DMARC keeps passing with the email signature in place.

For an admin working toward enforcement, that’s the difference that matters. A tool sending from its own domain is another source to align and monitor. A tool that works inside your Microsoft 365 mail flow adds nothing new to align.