Does Microsoft 365 create the DMARC record for me?

No. SPF and DKIM are configured inside the admin center, but the DMARC TXT record at _dmarc is one you publish in your own DNS. The exception is the tenant's onmicrosoft.com domain, whose DMARC record Microsoft has you create in the Microsoft 365 admin center.

Can I go straight to p=reject if SPF and DKIM already pass?

You can, and on a tenant with third-party senders it usually breaks something. Start at p=none, read two weeks of aggregate reports, align every sender you find, then spend a week at quarantine before you reject.

Why do the reports show failures from my own users?

Almost always forwarding or an unauthenticated relay. Forwarded mail breaks SPF because the forwarding server is not in your record, and printers or applications using Direct Send arrive with no authentication at all. DKIM on your custom domain is what keeps forwarded mail passing.

DMARC for Office 365: the exact record and the safe ramp

Say a 25-person freight broker runs on Microsoft 365. Mail works, nobody thinks about it. Then a customer forwards an invoice the company never sent, with the company's own domain in the From line, and in the same week accounting notices that their real invoices are landing in Gmail spam. Two symptoms, one gap. The domain publishes SPF and DKIM, so mail leaving the tenant looks correct, but nothing tells a receiving server what to do with the mail that fails those checks.

That instruction is DMARC, and it is the one record Microsoft does not create for you. SPF and DKIM are set up inside the admin center. DMARC is a TXT record you publish in your own DNS, and it is the only part of the three that both protects the domain from forgery and tells you who is sending as you.

Here is the order we work in on a Microsoft 365 tenant: the record we publish on day one, what the reports show, how we raise the policy, and the traps that belong to Exchange Online.

What DMARC adds on top of the SPF and DKIM Microsoft gives you

SPF answers one question: did this message come from a server the domain authorized? DKIM answers a different one: was this message signed with a key the domain published, and did it arrive unaltered? Both can pass while the message still lies about who sent it, because both check a domain the reader never sees.

SPF checks the envelope sender, the address in the SMTP MAIL FROM command. DKIM checks the domain in the d= tag of the signature. The address your recipient actually reads is the From header, and nothing so far has compared the two.

DMARC is that comparison. It requires the domain in the visible From header to match the domain that passed SPF, or the domain that signed with DKIM. One of the two is enough. That match is called alignment, and DMARC's default is relaxed alignment, which accepts a subdomain of the same organizational domain. You can tighten it with aspf=s and adkim=s, and on a small tenant with third-party senders you usually should not.

Once that comparison exists, two things follow. You can tell receivers to quarantine or reject the mail that fails it, and you can ask for reports listing every source sending mail as your domain. The reports are the part people skip, and the part that makes the policy safe to raise.

There is a floor to this now. Since 1 February 2024 Google has required senders of more than 5,000 messages a day to Gmail to publish a DMARC record, and p=none satisfies that rule. Microsoft applied a comparable requirement to Outlook.com, Hotmail.com and Live.com, announced 30 April 2025 and phased in from 5 May 2025, starting with junk routing and moving to rejection with 550 5.7.515. Both rules ask for the record, not for enforcement. Enforcement is your decision, not theirs.

The exact TXT record at _dmarc, tag by tag

This is the day one record for a domain that has never had DMARC:

Host:  _dmarc
Type:  TXT
TTL:   1 hour
Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1

Reading left to right:

v=DMARC1 is mandatory and has to come first, or the record is ignored.
p= is the policy for the domain itself: none, quarantine or reject. It is an instruction to receiving servers, not a switch inside your tenant.
rua= is where aggregate reports are sent. This tag is what the record is worth on day one. Point it at a shared mailbox or a group that a person opens, not at an individual who might leave.
ruf= requests per-message failure reports. Many large receivers never send them, and those that do may include message content, so treat that mailbox as sensitive or leave the tag out.
sp= sets a separate policy for subdomains. Leave it out and subdomains inherit whatever p= says, which is usually what you want once the root is at reject.
pct= applies the policy to a sample of failing mail. It only means anything at quarantine or reject, which makes it a ramp, not a setting you leave behind.
fo=1 asks for a failure report whenever either check fails to align, rather than only when both do.

Two details catch people inside a DNS panel. The host is _dmarc, not the bare domain, and some panels want _dmarc.example.com spelled out while others append the domain for you. And the whole thing is one TXT record. A second DMARC record on the same host is not additive: receivers that find two treat the domain as having no usable policy at all.

Publishing this changes nothing about delivery. It starts the flow of evidence that every later decision depends on.

What the reports show for a Microsoft 365 tenant

Aggregate reports arrive as gzipped XML, one file per receiving provider per day, usually within 48 hours of publishing the record. Each groups messages by sending IP and says whether SPF and DKIM passed and whether each aligned to your From domain. Give it two weeks, because the monthly senders are the ones that break policy changes.

On a typical M365 tenant, four groups show up:

Exchange Online itself. Normal user mail. If SPF includes spf.protection.outlook.com and DKIM signs with your custom domain, these rows pass aligned. If DKIM is still signing with the tenant's onmicrosoft.com domain, SPF carries the alignment alone, which holds until a message is forwarded.
Third-party senders. The CRM, the invoicing or e-invoicing platform, the helpdesk, the marketing tool, the e-commerce store. These are the rows that decide your timeline. Each one needs its own authentication set up at the vendor end before the policy can move.
On-premises relays and devices. An old Exchange server in a hybrid setup, a multifunction printer, a line-of-business application sending scans and statements.
Forwarders and genuine forgery. A mailing list or an auto-forward will break SPF on perfectly legitimate mail. Everything left after you have accounted for the rest is somebody else using your domain, and it is the reason to keep going.

Read the first file yourself rather than trusting a summary. If the XML is unfamiliar, paste one in here and look at the source rows.

Moving to quarantine, then reject

We do not move the policy on a calendar. We move it when the sender inventory from the reports is complete and every entry in it is either aligned or deliberately retired. The sequence we run:

Confirm the tenant's own mail first. SPF contains the Microsoft include and stays under the 10-lookup limit. DKIM is enabled for the custom domain in the Defender portal, with both selector1._domainkey and selector2._domainkey CNAMEs published, so Microsoft can rotate keys without an outage.
Fix third-party senders one at a time. Each vendor has its own path: a custom return-path or sending subdomain, DKIM CNAMEs, or a delegated subdomain that carries its own SPF. Fix one, wait for it to appear as aligned in the next report, then move to the next. Doing four at once means you cannot tell which change worked.
Deal with the relays. A printer or an application that cannot authenticate does not keep sending as the main domain. Move it to authenticated SMTP submission, a connector with an IP restriction, or a subdomain of its own.
Go to p=quarantine for a week. Failures land in junk instead of the inbox, which is recoverable. Watch the reports and, more importantly, ask the people who send the odd unusual message whether anything bounced.
Go to p=reject. If you want a ramp, pct=25 then pct=50 buys you a slower failure. If the inventory is genuinely complete, the ramp mostly buys time.

Keep the rua tag forever. A policy at reject with nobody reading reports is a configuration that will silently break the first time marketing signs up for a new tool.

The Microsoft traps that are not in the generic guides

The onmicrosoft.com domain. Every tenant has one, and attackers can use it. Microsoft's documentation is explicit that SPF and DKIM are already configured for the *.onmicrosoft.com domain but the DMARC record is not, and that you create it in the Microsoft 365 admin center rather than in public DNS. It is easy to lock the custom domain and leave this one open.

Domains you own and never send from. Microsoft recommends publishing a DMARC record on parked domains that says no mail should ever come from them, in the form v=DMARC1; p=reject; rua=mailto:d@rua.contoso.com; ruf=mailto:d@ruf.contoso.com. The old defensive domain registration from three years ago is a free spoofing channel until you do.

Direct Send. Exchange Online accepts unauthenticated mail on port 25 addressed to your own tenant's mailboxes, which is how printers and scanners have always worked and also how an outsider can drop a message that appears to come from a colleague. Microsoft added an organization-level control for this, RejectDirectSend, set through Set-OrganizationConfig. If you turn it on, inventory the devices that rely on it first and move them to authenticated submission or a restricted connector.

Forwarding. Auto-forward rules and mailing lists break SPF by design, because the forwarding server is not in your SPF record. DKIM survives forwarding as long as the message is not rewritten. That is the practical reason DKIM has to work on the custom domain before you enforce, not just SPF.

Inbound is a separate setting. Publishing DMARC protects other people from forged mail claiming to be you. It does nothing about forged mail arriving at your users. That is governed by your anti-phishing policy, where honoring a sender's p=quarantine and p=reject is controlled separately. Check it while you are in there.

What we watch after the flip

For the first month we read the reports weekly and look for three things: a source that has never appeared before, a known source whose alignment rate has dropped, and a rise in rejected mail from your own IP ranges. The first is usually a tool somebody signed up for. The second is usually a rotated key or a vendor changing infrastructure. The third is worth a phone call.

After that, monthly is enough, as long as somebody still opens that mailbox.

How Guanacos Tech helps

We do this work on Microsoft 365 tenants as often as on Google Workspace ones. A typical engagement is two weeks of reports, a sender inventory, the vendor-by-vendor alignment work, and the walk up to reject with somebody watching while it happens. If you would rather hand it over than learn the XML, our email deliverability consulting for small business covers exactly this. Bring your domain to the call and we will tell you what is published today and how far you are from enforcement.

DMARC for Office 365: the record, the policy ramp, and the reports nobody reads