DMARC Records O365: Set Up Microsoft 365 Without Breaking Mail

DMARC records O365 configurations are not an Exchange Online switch you turn on in the Microsoft 365 admin center. For a custom domain, DMARC is a DNS TXT record that tells receiving mail systems how to handle mail claiming to be from your domain when aligned SPF and DKIM authentication do not pass. (learn.microsoft.com)

The important word is aligned. An email can pass ordinary SPF or DKIM and still fail DMARC if the authenticated domain does not match the visible address in the message’s From: header closely enough. That distinction is why a copied DMARC record can be syntactically valid but still break marketing mail, help-desk notifications, application alerts, or messages sent by a relay.

This guide shows how to create a safe DMARC record for a Microsoft 365 domain, configure the SPF and DKIM prerequisites, understand the record syntax, monitor reports, and move from monitoring to enforcement. It applies to Exchange Online / Microsoft 365 cloud mailboxes using a custom domain such as example.com.

What a DMARC record does in O365

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It builds on SPF and DKIM rather than replacing them. SPF identifies permitted sending sources for the SMTP envelope sender; DKIM signs a message and lets recipients validate that signature through DNS. DMARC evaluates whether either passing result is aligned with the visible From: domain. (learn.microsoft.com)

For example, consider a message displayed to recipients as:

From: Billing <billing@example.com>

DMARC asks whether at least one of these is true:

1. SPF passes for an envelope sender domain that aligns with example.com.
2. DKIM passes with a d= signing domain that aligns with example.com.

If neither condition is met, the message fails DMARC. Your published policy then asks receivers to take no specific enforcement action (p=none), quarantine the message (p=quarantine), or reject it (p=reject). Microsoft describes a message as passing DMARC when either the aligned SPF check or aligned DKIM check passes; it fails when both fail. (learn.microsoft.com)

A DMARC record therefore has two jobs:

• Domain protection: It makes unauthorized use of your visible From: domain harder to deliver successfully.
• Sender inventory: Aggregate reports reveal systems that are sending mail using your domain, including systems your IT team may not know about.

DMARC is not a deliverability guarantee. A passing message can still be filtered for content, reputation, recipient behavior, or other signals. Conversely, setting p=none gives you visibility but does not ask receivers to quarantine or reject unauthenticated impersonation. Microsoft specifically notes that SPF alone does not prevent spoofing and that DKIM and DMARC are also needed for fuller protection. (learn.microsoft.com)

The DNS record you actually publish

For the root domain example.com, publish one TXT record at this hostname:

_dmarc.example.com

In many DNS dashboards, the zone is already example.com. In that case, enter only this host or name:

_dmarc

Do not enter _dmarc.example.com.example.com. DNS providers differ in whether they append the zone name automatically, so inspect the resulting fully qualified name after saving.

A sensible monitoring record is:

Type: TXT
Host/Name: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100
TTL: 3600

The same record in zone-file form is:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100"

The required elements are the version tag, v=DMARC1, and the requested policy, p=. The rua destination is strongly recommended because it supplies aggregate feedback. The current DMARC specification is split across RFC 9989, RFC 9990, and RFC 9991; RFC 7489 is obsolete, although its familiar record form remains widely recognized in operational documentation. (rfc-editor.org)

DMARC tag reference for Microsoft 365 domains

Use the smallest record that solves the immediate problem. These are the tags most useful during an O365 rollout:

adkim=r and aspf=r mean relaxed alignment. In relaxed mode, an aligned domain can share the same organizational domain as the visible From: domain. Strict mode, written as adkim=s or aspf=s, requires an exact domain match. Strict alignment is sometimes appropriate for tightly controlled domains, but it should not be your default simply because it sounds more secure; it can expose unexpected delegated or subdomain-based mail flows.

A note on rua addresses

DMARC aggregate reports are machine-readable XML files, usually compressed, not easy-to-read daily summaries. You can send them to a dedicated mailbox you control, but a reporting platform can make it far easier to group sources, identify failures, and distinguish Microsoft 365 from other mail vendors.

If rua points to a different organizational domain, receivers can require an external reporting authorization record before sending reports there. This is why a record such as rua=mailto:reports@vendor.example may require a related DNS authorization record published by that reporting vendor. Check the vendor’s onboarding instructions rather than assuming reports will arrive. (rfc-editor.org)

Prerequisites: SPF and DKIM must be ready first

Do not begin enforcement until you understand every system sending mail with your domain in the visible From: address. Microsoft 365 is often one sender, not the only sender. Typical additional sources include a CRM, a support desk, a website form tool, an invoicing platform, a recruitment system, a copier or scanner relay, and a transactional email provider.

SPF for a Microsoft 365-only domain

If Microsoft 365 is the only sender for example.com, Microsoft’s standard SPF mechanism is:

v=spf1 include:spf.protection.outlook.com -all

Publish it as a TXT record on the root domain, usually shown as host @ in a DNS provider:

Type: TXT
Host/Name: @
Value: v=spf1 include:spf.protection.outlook.com -all

If other authorized services send mail using the same envelope sender domain, combine their mechanisms into the same SPF record. Do not create one SPF TXT record for Microsoft 365 and a second one for another platform. Multiple SPF records can cause an SPF permanent error, and SPF processing has a DNS lookup limit of 10. (learn.microsoft.com)

A simplified illustration for Microsoft 365 plus a vendor is:

v=spf1 include:spf.protection.outlook.com include:spf.vendor-example.net -all

That line is only an example. Use the exact SPF include mechanism your other vendor publishes. Do not guess at vendor hostnames, and do not paste an SPF record from a different product or account.

SPF is useful but fragile when mail is forwarded because the forwarding server’s IP address is usually not listed in the original sender’s SPF record. Microsoft notes that this SPF failure pattern is expected for forwarded messages. DKIM gives DMARC a more resilient authentication path in many forwarding scenarios. (learn.microsoft.com)

Enable DKIM signing in Microsoft 365

Microsoft 365 can DKIM-sign mail using your custom domain, but you must publish the two CNAME records Microsoft generates for that domain and then enable signing in the Microsoft Defender portal. Microsoft’s configuration uses CNAME records for its custom-domain DKIM setup; other mail services may use DKIM TXT records instead. (learn.microsoft.com)

The record names commonly begin like this:

selector1._domainkey.example.com
selector2._domainkey.example.com

The targets are tenant-specific. They follow a Microsoft-provided pattern involving your domain and onmicrosoft.com, but do not handcraft them from a blog post. In the Defender portal, go to the DKIM settings for the exact domain, copy both displayed CNAME values, create them at your DNS host, wait until DNS resolves, and enable DKIM signing for that domain.

Every custom domain and sending subdomain used in Microsoft 365 requires its own DKIM configuration. A signature from tenant.onmicrosoft.com may authenticate cryptographically but does not necessarily give you DMARC alignment for a visible From: address at example.com; the relevant domain is the d= value in the DKIM-Signature header. (learn.microsoft.com)

Why DKIM is the preferred DMARC path for O365

Microsoft 365 can use a Return-Path or envelope sender that does not align with the visible sender domain. That is normal mail-routing behavior, but it means you should not rely solely on SPF alignment. A properly configured custom-domain DKIM signature gives receivers an aligned authentication result tied to the domain recipients see in the From: line.

This does not eliminate SPF. Keep SPF accurate because it remains part of the authentication stack and reports can expose unauthorized infrastructure. But for reliable DMARC passage from Microsoft 365 and many third-party platforms, aligned DKIM is usually the cleaner target.

Step-by-step: create DMARC records for O365 safely

Follow this order. Skipping directly to p=reject is the common mistake because it protects against spoofing while potentially rejecting mail from an authorized but forgotten sender.

1. List every visible From domain

Inventory the domains and subdomains people see in outgoing email. Include:

• Employee mail such as person@example.com
• Shared mailboxes such as support@example.com
• Marketing mail such as news@example.com
• Transactional mail such as receipts@example.com
• Subdomain mail such as alerts@mail.example.com
• Inactive or parked domains that should never send mail

Write down the platform responsible for each one. A platform that sends with From: alerts@example.com is in scope even if it delivers through an entirely separate infrastructure from Exchange Online.

2. Verify the Microsoft 365 sender path

For each Microsoft 365 custom domain, confirm:

1. The domain is accepted and used for mail in Microsoft 365.
2. The root-domain SPF record includes include:spf.protection.outlook.com if Exchange Online sends mail for that domain.
3. The two tenant-specific DKIM CNAME records resolve correctly.
4. DKIM signing is enabled for the custom domain, not merely for the default onmicrosoft.com domain.

Microsoft’s email authentication documentation treats SPF, DKIM, and DMARC as interdependent components, not interchangeable settings. (learn.microsoft.com)

3. Configure third-party senders before enforcement

For a bulk mail, transactional, or support platform, configure the vendor’s custom sending domain or authenticated sending domain. A vendor signature using only its own domain can pass DKIM without aligning to your visible From: address, which does not satisfy DMARC for your domain.

Use a delegated subdomain when the vendor supports it. For example, send promotional mail from updates.example.com and transactional mail from notify.example.com rather than giving every external platform unrestricted use of example.com. Microsoft also recommends a subdomain for bulk email services that are not under your direct control. (learn.microsoft.com)

If your application sends product emails, make its From domain and authenticated DKIM domain intentional. The operational details for integrating an application sender belong in your email API setup guides, but the DMARC rule remains the same: the visible From domain needs an aligned SPF or DKIM pass.

4. Create the monitoring record

Create this TXT record, replacing the address with one you control:

Host: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100

p=none is a monitoring policy. It lets you collect feedback while asking no specific quarantine or rejection action for DMARC failures. That is the correct starting point for most domains because the report data is what reveals unknown senders and alignment gaps.

Do not create a second DMARC TXT record for the same hostname. If you already have _dmarc.example.com, edit the existing record after confirming who owns it and what reporting workflow depends on it. Two competing policy records create an invalid or unpredictable configuration for receivers.

5. Confirm public DNS resolution

Use a DNS lookup tool or command line after publication:

dig +short TXT _dmarc.example.com

Expected output should contain your full policy string, for example:

"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100"

A DNS TTL controls caching behavior, but propagation timing depends on your authoritative DNS provider and resolver caches. Do not interpret an immediately missing record from one resolver as proof that the record is wrong. Instead, check the authoritative zone, wait for the TTL and normal DNS distribution, and test from more than one lookup service.

6. Send controlled test messages

Send a message from a Microsoft 365 mailbox at your custom domain to a mailbox where you can inspect full headers. Gmail’s “Show original” and Outlook’s message-source/header views are common options.

Look for results conceptually like:

Authentication-Results: ...;
 spf=pass ...;
 dkim=pass header.d=example.com;
 dmarc=pass header.from=example.com

The exact wording and ordering differ by receiving provider. The result you want is dmarc=pass and an aligned identifier, usually header.d=example.com for DKIM. Microsoft 365 itself adds an Authentication-Results header to received messages showing checks including SPF, DKIM, DMARC, and composite authentication. (learn.microsoft.com)

Worked example: Contoso’s O365 DMARC rollout

Assume Contoso uses Microsoft 365 for employee mail at contoso.com. Its website uses a transactional email service for password resets, while marketing uses a separate platform. Contoso wants to stop direct spoofing of @contoso.com without disrupting those legitimate systems.

Phase 1: identify sources

Contoso records these mail streams:

Phase 2: set Microsoft 365 authentication

Contoso’s SPF record becomes:

v=spf1 include:spf.protection.outlook.com include:spf.transactional-vendor.example include:spf.marketing-vendor.example -all

In real life, Contoso must validate both vendor includes, count SPF DNS lookups, and remove mechanisms for tools no longer used. It does not create three SPF records.

Contoso then publishes the two exact DKIM CNAME records displayed in its Microsoft 365 DKIM setup screen and enables DKIM for contoso.com. A test message sent by an employee now shows dkim=pass with header.d=contoso.com and dmarc=pass.

Phase 3: publish monitoring DMARC

Contoso publishes:

v=DMARC1; p=none; rua=mailto:dmarc-reports@contoso.com; adkim=r; aspf=r; pct=100

Reports show Microsoft 365 is passing. The transactional provider is passing after Contoso adds its vendor-supplied DKIM CNAME records. The marketing provider is failing because it signs as the provider’s own domain and uses From: news@contoso.com.

Instead of enforcing immediately, Contoso configures the marketing platform to send from news@updates.contoso.com, authenticates updates.contoso.com in that platform, and publishes a DMARC record for the subdomain:

Host: _dmarc.updates
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@contoso.com; adkim=r; aspf=r

Once reports show the marketing platform passing for its subdomain, Contoso can progress the parent domain.

Phase 4: enforce gradually

A reasonable next record is:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@contoso.com; adkim=r; aspf=r; pct=25

That asks receivers to apply the quarantine policy to a percentage of failing mail. After continued report review and remediation of legitimate failures, Contoso can increase pct and eventually use:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@contoso.com; adkim=r; aspf=r; pct=100

The final record asks receivers to reject messages that claim to be from contoso.com but fail DMARC. DMARC policies are requests made to receiving systems, not a promise of identical handling by every mailbox provider, but p=reject is the strongest standard policy for direct spoofing protection. (learn.microsoft.com)

Reading DMARC reports without getting lost

Aggregate reports answer four operational questions:

1. Which IP addresses or providers sent mail claiming my domain?
2. How much volume came from each source?
3. Did SPF pass, DKIM pass, and did either result align?
4. What disposition did the receiver apply?

A failure is not automatically an attack. It might be a forwarded message, a mailing list that modified content, an old office scanner, an acquired company’s tool, a vendor configured without your custom DKIM domain, or a malicious impersonator.

Treat each report row as a classification task:

• Authorized and passing: Keep monitoring.
• Authorized but failing: Fix authentication or change the visible From domain before increasing enforcement.
• Unknown and low volume: Investigate; it may be spoofing or an unowned legacy system.
• Unknown and clearly malicious: Do not authorize it. It is evidence that enforcement is valuable.

Reports commonly use source IP addresses rather than friendly product names. A DMARC reporting service can enrich IP ownership and aggregate results, but you should still retain ownership of the report destination, vendor account, and domain DNS. Do not delegate a domain’s authentication posture entirely to a consultant without documented access and an exit plan.

Common O365 DMARC mistakes and how to fix them

Publishing DMARC before enabling custom-domain DKIM

Symptom: Employee messages pass SPF but show inconsistent or failed DMARC results, especially through forwarding or routing changes.

Fix: Publish the Microsoft-generated DKIM CNAME records and enable DKIM signing for each custom sending domain. Verify the d= field in a real outbound message aligns with the visible From domain. Microsoft states that the signing domain is the d= value in the DKIM-Signature header and that receivers use DNS to validate it. (learn.microsoft.com)

Adding multiple SPF records

Symptom: SPF returns permerror, or one sending platform is authorized while another is not.

Fix: Merge authorized mechanisms into one SPF TXT record. Recalculate the lookup count whenever a vendor is added. Microsoft identifies multiple SPF records and the 10-DNS-lookup limit as causes of SPF permanent errors. (learn.microsoft.com)

Thinking SPF pass automatically means DMARC pass

Symptom: A vendor says SPF passes, but recipient headers show dmarc=fail.

Fix: Compare the SPF-authenticated envelope sender domain with the visible From: domain. If they do not align, configure aligned DKIM or a custom return-path domain through the vendor.

Publishing at the wrong hostname

Symptom: A lookup for _dmarc.example.com returns no record even though the DNS dashboard shows one.

Fix: Check whether your DNS provider appended the zone twice. The record must resolve at _dmarc.example.com, not at _dmarc.example.com.example.com.

Going directly to p=reject

Symptom: Legitimate invoices, support replies, form notifications, or campaign mail stop arriving after the policy change.

Fix: Return temporarily to p=none or reduce pct while fixing the authorized failing source. Use aggregate reports and real message headers to confirm the correction before resuming enforcement.

Forgetting subdomains and parked domains

Symptom: The root domain is protected, but a previously used subdomain can still be impersonated or a dormant domain has no DMARC policy.

Fix: Audit the full namespace. Use a dedicated record for subdomains that send email; use sp= intentionally for subdomains that do not publish their own record. For domains that should never send mail, a restrictive DMARC policy can be appropriate after confirming no hidden mail stream exists. Microsoft separately documents DMARC reporting and protection considerations for onmicrosoft.com and parked domains. (learn.microsoft.com)

Assuming DMARC fixes inbound phishing by itself

Symptom: Your domain is protected, but users still receive phishing messages from lookalike domains or compromised legitimate accounts.

Fix: Keep inbound anti-phishing controls, user reporting, mailbox protection, and incident response in place. DMARC helps authenticate claimed domains; it does not make every malicious message disappear.

What “working” looks like

A successful O365 DMARC implementation has evidence at three levels.

DNS level

• _dmarc.example.com returns exactly one valid DMARC TXT record.
• example.com has exactly one SPF TXT record.
• Microsoft 365’s two DKIM CNAME records resolve to the targets shown in your tenant.

Message level

A fresh message sent from a Microsoft 365 mailbox at user@example.com shows:

spf=pass
DKIM=pass
DMARC=pass

The most useful detail is that either the SPF domain or DKIM d= domain aligns with example.com. For Microsoft 365, expect aligned custom-domain DKIM to be your dependable indicator.

Reporting level

Aggregate reports show known sources passing and unexplained sources being investigated. When you move to p=quarantine or p=reject, the report stream should not reveal legitimate high-volume senders suddenly failing.

Do not use inbox placement as the only success metric. A message can land in the inbox for many reasons, and a spoof can sometimes be filtered even without DMARC. The verifiable goal is aligned authentication for authorized mail plus a policy that requests stronger handling of unauthorized mail.

Choosing between root-domain and subdomain sending

Using the same root domain for every system is convenient at first and expensive to govern later. Every external vendor becomes part of the risk surface for example.com, and every new tool requires SPF, DKIM, and DMARC review.

A cleaner design is often:

People and shared mailboxes:      example.com
Transactional application mail:   notify.example.com
Marketing campaigns:              updates.example.com
System alerts:                    alerts.example.com

This structure separates reputations, limits operational blast radius, and makes reporting easier to interpret. It also lets you set different policies where justified. For instance, a marketing subdomain can have its own DKIM configuration and DMARC record while employee mail remains protected under the root domain.

This is not a reason to make random subdomains. Create them around actual sending functions, document the owner for each one, and remove DNS authorization for systems you retire. Microsoft’s guidance specifically calls out use of subdomains for bulk email services outside your direct control. (learn.microsoft.com)

A practical rollout checklist

Before changing policy, complete this checklist:

• List every root domain and subdomain used in visible From addresses.
• Identify the actual sender for each mail stream.
• Consolidate each domain to one SPF record.
• Confirm Microsoft 365 SPF authorization where Exchange Online sends mail.
• Publish Microsoft-provided DKIM CNAME records for every Microsoft 365 sending domain.
• Enable DKIM signing in Microsoft 365 after DNS resolves.
• Configure custom-domain DKIM or aligned SPF for each third-party sender.
• Publish one _dmarc TXT record with p=none and an active rua address.
• Inspect message headers from every critical sender.
• Review aggregate reports and resolve authorized failures.
• Move to p=quarantine, then p=reject, only with evidence that legitimate mail is aligned.

DMARC is not a one-time DNS task. Treat it as a small security control with ownership, a sender-change process, and periodic report review. The moment a marketing team adds a new platform or engineering changes a transactional sender, your authentication configuration needs review as well.

FAQ

What is the basic DMARC record for O365?

For monitoring a Microsoft 365 custom domain, use a record in this form:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100

Publish it as a TXT record at _dmarc.example.com. Replace the reporting address with one you control, and do not enforce quarantine or rejection until SPF, DKIM, and third-party sender alignment have been verified.

Does Microsoft 365 create a DMARC record automatically?

Microsoft manages DNS for its onmicrosoft.com domains, but for a custom domain you control the DNS record at your DNS provider. You must publish the DMARC TXT record for that custom domain yourself. (learn.microsoft.com)

Can DMARC pass without DKIM in Microsoft 365?

Yes. DMARC can pass when aligned SPF passes, even if DKIM does not. In practice, DKIM is still strongly recommended because it provides a second path and is often more reliable when mail is forwarded or routed through intermediaries. A message passes DMARC when aligned SPF or aligned DKIM passes. (learn.microsoft.com)

Should I use p=quarantine or p=reject?

Start with p=none to identify all legitimate mail streams. Use p=quarantine as a staged enforcement step if your reports are clean, then move to p=reject once you are confident legitimate senders pass aligned authentication. p=reject is the stronger request against direct domain spoofing.

Why are DMARC reports not arriving?

Check that the rua address is valid, the TXT record is publicly resolvable, and the report destination is authorized when it belongs to a different organizational domain. Also remember that not every receiver sends reports, and report timing and format vary by receiver. (rfc-editor.org)