A DMARC record O365 setup is not just one DNS entry: it is the final control that ties your Microsoft 365 SPF and DKIM configuration to the visible From address people see. Done well, it makes spoofing your domain materially harder; done too quickly, it can send legitimate messages from forgotten tools to spam or rejection.

What a DMARC record does in Office 365

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It is a DNS-published policy that tells receiving mail systems how to evaluate messages claiming to come from your domain and what to do when authentication fails.

For a Microsoft 365 organization using a custom domain such as example.com, the record lives in public DNS at:

_dmarc.example.com

It is a TXT record whose value begins with:

v=DMARC1

DMARC does not replace SPF or DKIM. It evaluates them against the domain in the visible From: header. A message passes DMARC when at least one of these conditions is true:

SPF passes and the SPF-authenticated envelope-sender domain aligns with the visible From domain.
DKIM passes and the DKIM signing domain (d=) aligns with the visible From domain.

That alignment rule is the reason DMARC is more useful than publishing SPF alone. An attacker can authorize their own infrastructure to send mail for a domain they control, but that does not make it aligned with your visible From: billing@example.com address.

For Microsoft 365, DKIM is commonly the durable path to DMARC alignment. Forwarding can break SPF because the forwarding server is not listed in the original sender’s SPF record, while a valid DKIM signature can survive forwarding as long as the message’s signed content is not modified.

The O365 prerequisites: SPF, DKIM, and a sender inventory

Do not start with p=reject. Before publishing an enforcing DMARC record, establish which systems send mail using your domain in the visible From address.

That includes more than Outlook and Exchange Online. Typical overlooked sources include:

Website contact forms and WordPress plugins.
CRM and marketing platforms.
Help desks and ticketing systems.
Accounting, invoicing, and payroll software.
Recruitment tools, document-signing services, and survey platforms.
Printers, scanners, building systems, and line-of-business applications.
Transactional email providers and custom application mail.
Legacy on-premises Exchange servers, SMTP relays, or hybrid connectors.

A DMARC policy protects the domain shown in the visible From field, not merely the system your employees use for day-to-day email. If a marketing tool sends From: updates@example.com, it needs an aligned SPF or DKIM path even if all employee mail is handled by Microsoft 365.

SPF for Microsoft 365

For an Exchange Online-only setup where Microsoft 365 is the only sender, Microsoft documents this SPF record format:

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

The include:spf.protection.outlook.com mechanism authorizes Microsoft 365’s sending infrastructure. The -all ending is a hard fail for sources not authorized by the record.

Do not create one SPF record for Microsoft 365 and another SPF record for a website platform. A domain must have one SPF TXT record. Combine approved services into that one record according to each provider’s official SPF instructions. For example, the conceptual pattern below has one Microsoft 365 include plus one additional vendor include:

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

Do not copy the second include literally unless that vendor documents it. SPF records are provider-specific, and an incorrect include can authorize the wrong service or cause an SPF permanent error.

SPF also has a limit of ten DNS-querying mechanisms and modifiers during evaluation. Multiple email vendors, nested includes, and old configuration fragments can push a record over that limit. A permerror result is not a pass, so consolidate sending services or move a distinct mail stream to a subdomain rather than endlessly adding includes.

Enable DKIM for every Microsoft 365 sending domain

Microsoft 365 can DKIM-sign mail from your custom domain, but it must be configured and enabled. In the Microsoft Defender portal, open the DKIM settings under the email authentication settings, select the custom domain, and publish the two CNAME records Microsoft provides.

The records generally follow this shape:

selector1._domainkey.example.com CNAME selector1-example-com._domainkey.<tenant>.onmicrosoft.com
selector2._domainkey.example.com CNAME selector2-example-com._domainkey.<tenant>.onmicrosoft.com

The target names are tenant- and domain-specific. Copy the exact CNAME values shown in your Microsoft 365 tenant instead of constructing them from an online example. After the CNAME records resolve publicly, enable DKIM for that domain in the Defender portal.

Send a new message from Microsoft 365 after DKIM is enabled. In its message headers, look for a DKIM-Signature header with an aligned value such as:

d=example.com;

A signature from onmicrosoft.com or another service domain may be technically valid but is not necessarily aligned with From: person@example.com. For DMARC, the passing identity needs to align with the visible From domain under the selected alignment mode.

Use a subdomain for independent bulk mail tools

Microsoft recommends using a subdomain for email services you do not directly control, especially bulk-mail providers. For example:

Employee mail: person@example.com
Marketing mail: news@mail.example.com

This separates sender reputation, DNS records, and operational risk. A problem at a high-volume vendor is less likely to affect ordinary person-to-person mail from example.com.

A subdomain requires its own configuration. If a platform sends from news@mail.example.com, configure its SPF and DKIM records as required by that platform and publish a DMARC policy that covers it explicitly or deliberately inherits from the parent domain. Do not assume that setting up the root domain automatically authenticates every sending subdomain.

DMARC record O365 syntax: the minimum safe record

The most useful starting record for a custom domain is:

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

In DNS providers that require a fully qualified name, use _dmarc.example.com. In providers that automatically append your domain, entering _dmarc is correct. Check the provider’s preview before saving: a common mistake is accidentally publishing _dmarc.example.com.example.com.

Here is what each component means:

Component	Meaning	Practical use
`v=DMARC1`	DMARC protocol version identifier.	Required and should be first.
`p=none`	Monitoring policy.	Requests reports without asking recipients to quarantine or reject failures.
`rua=mailto:...`	Aggregate-report destination.	Sends machine-readable XML summaries of mail claiming to be from the domain.

The p tag is required. The rua tag is optional in the protocol, but omitting it means you lose the reporting feedback that makes a safe rollout possible.

Use a mailbox or reporting service that can handle automated attachments and alerts. A shared mailbox such as dmarc-reports@example.com can work for low volume, but raw reports arrive as compressed XML files and become difficult to interpret at scale. A DMARC reporting provider can aggregate sources, identify aligned and unaligned senders, and show trends. Whichever destination you choose, make sure someone owns the review process.

Understanding DMARC policies: none, quarantine, and reject

The policy is the operational heart of the record.

`p=none`: observe, but do not enforce

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

p=none asks receivers for visibility but does not request a delivery action for failures. It is the correct first policy for most organizations because it exposes unknown mail sources before those sources cause customer-facing delivery failures.

Monitoring mode does not mean every suspicious message will reach an inbox. Receiving providers still apply their own spam, phishing, and reputation controls. It simply means your DMARC record is not asking them to quarantine or reject failures based on your policy.

`p=quarantine`: treat failures as suspicious

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com

p=quarantine asks receivers to treat failing mail as suspicious. A receiving provider may route it to junk, quarantine it, or apply another local treatment. It is not an absolute guarantee that every failed message lands in one identical folder across every provider.

Use quarantine after you have identified legitimate sources and corrected their alignment. It provides meaningful protection while making it possible to recover legitimate mail that a recipient can still locate in junk or quarantine.

`p=reject`: request rejection of unauthenticated spoofing

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com

p=reject is the strongest standard DMARC policy. It asks receiving systems to reject messages that fail DMARC rather than accepting them for later filtering.

This is the target policy for a domain whose sending inventory is stable and fully aligned. It is not a shortcut to better deliverability, and it cannot correct poor list quality, weak content, high complaint rates, or recipient-side filtering. Its primary value is domain anti-spoofing enforcement.

A worked example: Contoso moves from O365 monitoring to enforcement

Assume a company owns contoso.example and uses Microsoft 365 for employee mail. It also uses a CRM for sales emails and a transactional email service for password resets. The visible From addresses are:

Employees: alice@contoso.example
CRM: sales@contoso.example
Application: support@contoso.example

The administrator first makes a sender inventory and discovers that the CRM and application are not routed through Exchange Online. Adding Microsoft’s SPF include alone would therefore not be enough.

Step 1: publish a single SPF record

After obtaining each vendor’s officially documented mechanisms, Contoso builds one SPF record. This illustrative format shows the structure, not vendor values to copy:

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

The admin verifies that there is no second TXT record starting with v=spf1 at contoso.example. They also check the final record with an SPF lookup tool and confirm it does not return permerror.

Step 2: enable Microsoft 365 DKIM

In the Defender portal, the admin selects contoso.example in the DKIM settings. Microsoft 365 displays two tenant-specific CNAME records. The administrator publishes both exactly as supplied, waits until public DNS returns them, and enables DKIM.

A new message sent from Outlook has headers resembling:

Authentication-Results: recipient.example;
 spf=pass smtp.mailfrom=contoso.example;
 dkim=pass header.d=contoso.example;
 dmarc=pass header.from=contoso.example

This confirms that ordinary Microsoft 365 mail has at least one aligned authentication path. In this example both SPF and DKIM align, which gives useful resilience when one mechanism is affected by forwarding or routing changes.

Step 3: configure the CRM and application for aligned DKIM

Contoso logs in to each external sender. Rather than relying solely on a vendor-owned DKIM signing domain, the admin enables custom-domain DKIM signing where supported. The CRM may ask for CNAME records; the transactional provider may ask for DKIM CNAME or TXT records plus a custom return-path domain.

After each setup, Contoso sends test messages to an external mailbox and checks that each message has:

dkim=pass header.d=contoso.example

or an aligned subdomain under relaxed alignment, such as header.d=mail.contoso.example for mail visibly sent from news@contoso.example only if the organizational-domain relationship and policy configuration make that alignment valid. The safest operational rule is simpler: configure the provider to DKIM-sign with the same domain used in the visible From address whenever it supports that configuration.

Step 4: publish the monitoring DMARC record

Contoso creates this DNS record:

Host: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@contoso.example

The domain name is the record location, not the TXT value. Do not place _dmarc inside the value field, and do not publish this at the root @ location.

Step 5: review reports and investigate every legitimate source

Aggregate reports show which receiving systems observed messages using contoso.example, which source IPs they saw, SPF and DKIM outcomes, and DMARC disposition. They are not a complete log of every message and they are not a substitute for application logs, but they are strong evidence of domain use in the wider email ecosystem.

Suppose reports reveal a copier sending invoices with From: invoices@contoso.example through an ISP relay. It fails both SPF alignment and DKIM because it was never configured as an approved sender. Contoso has several choices:

Configure the copier to relay through an approved Microsoft 365 or application relay path.
Configure aligned authentication if the device and route support it.
Change the workflow so it sends from a dedicated, properly authenticated service.
Stop it from sending external mail if it has no business need.

The wrong fix is to weaken the entire domain’s DMARC policy permanently just to preserve an unmanaged sender.

Step 6: enforce deliberately

Once reports show that legitimate Microsoft 365, CRM, and application mail passes DMARC, Contoso moves to:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@contoso.example

It continues to monitor reports and internal support tickets. When valid traffic remains aligned and no unresolved sender is found, it changes the policy to:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@contoso.example

The technical change is only one policy value. The difficult work was identifying all mail sources before that change.

How to add the record in your DNS provider

Microsoft 365 does not host your public DNS by default. You publish DMARC at the registrar or DNS host authoritative for the domain, such as Cloudflare, GoDaddy, Squarespace Domains, Route 53, or another provider.

The provider interface varies, but the fields are fundamentally the same:

Sign in to the DNS host for the domain.
Open the DNS zone for the exact sending domain, such as example.com.
Add a record with type TXT.
Set the name to _dmarc, unless the provider explicitly requires the full _dmarc.example.com name.
Paste the DMARC value as a single TXT string.
Save the record and wait for DNS propagation according to the TTL and provider behavior.
Query public DNS and send live tests before changing to an enforcing policy.

A TTL controls how long resolvers may cache a DNS response. During a rollout, a moderately short TTL can make changes easier to validate, but DNS is still distributed and you should not assume every recipient sees a new record instantly.

Some DNS panels automatically wrap a long TXT value in quotation marks or split it into display segments. That is normally fine if the DNS provider publishes one valid logical TXT record. What matters is the value returned by a public DNS lookup, not how the provider visually wraps it in the dashboard.

How to verify the record and prove DMARC works

A published TXT record is only the first verification. You need to check DNS, message authentication, and ongoing reports.

Check public DNS

From a terminal, query the record:

nslookup -type=TXT _dmarc.example.com

On systems with dig, use:

dig TXT _dmarc.example.com +short

The response should contain one logical record beginning with v=DMARC1. If nothing is returned, check the record name, the DNS zone, and whether you edited the authoritative DNS provider rather than a parked registrar DNS page.

You can also use a reputable DMARC lookup tool. A lookup confirms record publication and basic syntax; it does not prove that your outbound mail is aligned.

Inspect headers from an external test mailbox

Send a new message from Outlook on the web or desktop to an external mailbox you control. Open the full message headers or original source and look for an Authentication-Results line.

A successful Microsoft 365 example resembles:

spf=pass ...;
dkim=pass ...;
dmarc=pass header.from=example.com

Exact formatting differs by receiving system. The decisive field is dmarc=pass, with an appropriate header.from value. Also inspect header.d= for DKIM and smtp.mailfrom= for SPF when troubleshooting alignment.

Repeat this test for every major mail source: a normal employee message, a CRM campaign test, an application notification, a help-desk ticket, and any other sender listed in your inventory.

Read the difference between a pass and an aligned pass

This is the mistake that catches many otherwise careful administrators:

spf=pass

does not automatically mean:

dmarc=pass

Likewise:

dkim=pass

does not automatically guarantee DMARC. The SPF domain or DKIM signing domain must align with the visible From: domain. An email service may successfully sign mail with d=vendor.example, but that signature does not normally align with From: person@example.com.

Microsoft 365 adds an Authentication-Results header to received email, which can help your security team inspect inbound results. For outbound testing, use the headers at the destination mailbox because that shows what the receiving system actually evaluated.

DMARC alignment settings: relaxed versus strict

DMARC supports alignment modes for SPF and DKIM:

aspf=r
adkim=r

The r values mean relaxed alignment. This is also the default when those tags are omitted. Under relaxed alignment, a subdomain relationship can align with the organizational domain. Strict alignment uses s and requires an exact domain match.

A record explicitly declaring relaxed alignment might be:

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

In many cases, you do not need to state the defaults. Keeping a record short reduces configuration noise and makes it easier to audit.

Use strict alignment only when you understand every sender and domain relationship involved. It can be appropriate for a tightly controlled domain, but it is not a generic security upgrade. Strict SPF alignment often exposes return-path domain differences at SaaS providers, while strict DKIM alignment can fail legitimate mail signed by a sending subdomain.

For most Microsoft 365 organizations, start with default relaxed alignment, build aligned DKIM for each sending service, and choose strict alignment only after confirming it is compatible with your architecture.

Common O365 DMARC mistakes and how to fix them

Publishing more than one DMARC record

A domain should publish one DMARC TXT record at _dmarc.example.com. Multiple records can produce an invalid or indeterminate result for receivers.

Fix: Merge the needed tags into one record, then verify the public DNS response.

Publishing DMARC at the root domain

This is wrong:

Host: @
Value: v=DMARC1; p=none

That creates a generic TXT record at example.com, not a DMARC policy location.

Fix: Publish it at _dmarc.example.com.

Assuming Microsoft 365 covers third-party mail

Microsoft 365 SPF and DKIM settings only address mail sent through Microsoft 365. A Shopify app, CRM, or billing platform may use completely different infrastructure.

Fix: Configure each sender using its official custom-domain SPF, DKIM, and return-path instructions. Prefer aligned DKIM rather than expanding SPF without checking whether the service uses a different envelope sender.

Starting at reject without monitoring

p=reject can block spoofing, but it can also block valid mail sent from an old application, a copier, or a vendor that nobody included in the sender inventory.

Fix: Begin with p=none, analyze reports, test each sender, then move through quarantine to reject when the evidence supports it.

Treating DMARC reports as ordinary email

Aggregate reports are structured XML, often compressed. Reading them manually is possible but not an efficient ongoing process for organizations with meaningful mail volume.

Fix: Use a report parser or DMARC monitoring service, establish an owner, and review newly discovered sending sources rather than letting reports accumulate unread.

Confusing forwarding failures with a broken setup

Forwarding commonly breaks SPF because the forwarding host is not authorized by the original sender’s SPF record. That is expected behavior, not necessarily evidence that your Microsoft 365 SPF record is wrong.

Fix: Ensure DKIM is enabled and aligned. Consider authenticated received chain (ARC) handling where appropriate in Microsoft 365, but do not weaken DMARC merely because forwarding exists.

What to do with parked domains, subdomains, and onmicrosoft.com domains

A parked domain is registered but does not send legitimate email. It is often a strong candidate for an immediate restrictive policy because there should be no approved sources to preserve.

A typical parked-domain record is:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com

Only use this after confirming the domain truly does not send mail. Check old forwarding rules, marketing accounts, corporate acquisitions, and forgotten web forms first.

For subdomains, be explicit when they send mail. For example, if you send from marketing.example.com, publish and test SPF, DKIM, and DMARC records for that subdomain rather than relying on implicit inheritance. This makes the intended policy clear to administrators and reduces ambiguity as your email architecture changes.

Microsoft owns and manages DNS for your tenant’s onmicrosoft.com domain. Custom-domain mail is the priority for most organizations because that is the domain customers and attackers see. Microsoft also provides guidance for enabling DMARC reporting for Microsoft Online Email Routing Address domains and parked domains through the Defender portal when that is relevant to your tenant.

DMARC standards and record longevity

The current core DMARC standard is RFC 9989, which supersedes the earlier RFC 7489 specification. The familiar record prefix remains v=DMARC1, and the core implementation model remains aligned SPF or DKIM plus a domain policy.

Many older guides recommend the pct tag to apply a policy to a percentage of failing messages, for example:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com

Avoid adding pct to new long-lived records. The newer standard removed it after inconsistent implementation experience. Safer rollout methods are monitoring first, testing each mail source, moving the whole domain from none to quarantine, and finally moving to reject. You can also isolate risk by moving third-party bulk mail to a dedicated subdomain.

The newer specification includes additional policy concepts, but broad receiver implementation can differ during standards transitions. Keep production records conventional and interoperable: v, p, and rua are sufficient for most Microsoft 365 deployments. Add only tags you can explain, test, and operationally maintain.

A practical O365 DMARC rollout checklist

Before enforcement, confirm each item below:

The final state for a mature Microsoft 365 domain is usually concise:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com

The apparent simplicity is intentional. Your security comes from the authenticated sending ecosystem behind the record, not from packing every possible optional tag into one DNS value.

FAQ

What is the correct DMARC record for Office 365?

For initial monitoring, use:

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

Publish it as a TXT record at _dmarc.yourdomain.com. Before moving to quarantine or reject, configure SPF and DKIM for Microsoft 365 and every other service that sends using your domain.

Does Microsoft 365 create a DMARC record automatically?

No. For a custom domain, you publish the DMARC TXT record in the public DNS service that hosts your domain. Microsoft 365 provides the email authentication features and DKIM configuration, but it does not automatically create DNS records at an external DNS host.

Should I use p=none, quarantine, or reject for O365?

Start with p=none to collect reports and find legitimate senders. Move to p=quarantine after correcting alignment failures, then use p=reject when your reports and live tests show that legitimate mail is consistently aligned.

Why does SPF pass but DMARC fail?

DMARC requires alignment. SPF can pass for the envelope-sender domain while the visible From: address uses a different domain. Check smtp.mailfrom= and compare it with header.from= in the receiving mailbox’s authentication results. Aligned DKIM is often the best fix for third-party senders.

Do I need a separate DMARC record for a marketing subdomain?

If the subdomain sends mail, it is best to configure and test it explicitly. For example, news@marketing.example.com should have the sending platform’s required SPF and DKIM records, plus an intentional DMARC policy at _dmarc.marketing.example.com if you want a policy distinct from the parent domain.

DMARC Record for Office 365: Configure Microsoft 365 Safely