DMARC Record for Microsoft 365: Setup, Syntax, and Testing

If you are searching for a DMARC record M365 setup, the goal is usually simple: stop attackers from spoofing your Microsoft 365 email domain without accidentally blocking legitimate mail. The record itself is short, but deploying DMARC safely requires an inventory of every system that sends using your domain, properly configured SPF and DKIM, and a staged enforcement plan.

What a DMARC record does in Microsoft 365

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It is a DNS-based policy that tells receiving mail systems how to evaluate messages using your domain in the visible From: address.

For a Microsoft 365 domain such as example.com, DMARC checks whether either SPF or DKIM passes and aligns with example.com. Alignment is the important part: a message can pass a basic SPF or DKIM check yet still fail DMARC when the authenticated domain does not match the domain recipients see in the From: field.

Microsoft 365 supports DMARC for mail it sends and evaluates DMARC for mail it receives. But Microsoft does not create a DMARC record for your custom domain automatically. You publish the record as a DNS TXT record at the DNS provider that hosts your domain zone.

A passing DMARC result requires one of these two paths:

• Aligned SPF pass: the SMTP envelope sender, also called MAIL FROM or Return-Path domain, passes SPF and aligns with the visible From: domain.
• Aligned DKIM pass: the domain in the DKIM signature's d= value passes DKIM verification and aligns with the visible From: domain.

You do not need both paths to pass. In practice, configure both. SPF is vulnerable to ordinary forwarding because a forwarding server changes the connecting IP address. DKIM is generally more resilient when the message body and signed headers are preserved in transit.

DMARC is not a spam-filter bypass or a deliverability guarantee. It is an authentication and policy layer. A correctly authenticated message can still be filtered for reputation, content, recipient engagement, or other reasons.

The correct DMARC record M365 syntax

A DMARC record is a DNS TXT record published under _dmarc for the domain in the visible From: address.

For the domain example.com, create this record:

Some DNS dashboards automatically append your root domain. In those interfaces, entering _dmarc.example.com as the host can incorrectly create _dmarc.example.com.example.com. Check how your provider handles hostnames before saving.

The following is a safe starting record for a Microsoft 365-only organization:

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

Replace dmarc-reports@example.com with a mailbox you control or an address provided by a DMARC reporting platform. The recipient must be able to receive a potentially large number of XML report attachments.

What each DMARC tag means

The record is semicolon-separated tag/value pairs.

• v=DMARC1 identifies the record as DMARC. Put it first.
• p=none tells receivers to take no requested enforcement action on failing mail. It is monitoring mode, not protection mode.
• p=quarantine requests that failing messages be treated suspiciously, commonly by routing them to spam or junk. Receivers retain discretion.
• p=reject requests that receivers reject failing messages during SMTP processing. This is the strongest DMARC policy.
• rua=mailto:... requests aggregate reports. These reports summarize authentication activity and are the operational foundation for a safe rollout.
• adkim=r uses relaxed DKIM alignment. A DKIM signing domain such as mail.example.com can align with example.com.
• aspf=r uses relaxed SPF alignment. An aligned subdomain can satisfy DMARC for the organizational domain.
• sp=... sets a policy for subdomains that do not publish their own DMARC record.
• pct=... expresses the percentage of failing messages to which a receiver should apply the requested policy. It is commonly used during legacy rollouts, but a receiver ultimately decides how to apply a policy.

For most M365 deployments, relaxed alignment is the sensible initial setting. Strict alignment (adkim=s or aspf=s) requires an exact domain match and can break valid mail flows, especially when different business systems use subdomains.

DMARC depends on SPF and DKIM first

Do not move to p=quarantine or p=reject until you understand every sender that uses your domain. A DMARC policy does not configure Microsoft 365 authentication on its own; it evaluates the SPF and DKIM authentication already associated with each message.

SPF for Microsoft 365

For a domain that sends mail only through Microsoft 365, the SPF record is commonly:

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

Publish SPF at the root domain, not at _dmarc. For example.com, the host is generally @ or blank in a DNS dashboard, depending on the provider.

There must be one SPF TXT record per domain. Do not publish one TXT record for Microsoft 365 and another for a newsletter provider. Merge the authorized mechanisms into a single record instead.

For example, if Microsoft 365 and another email service both send mail as example.com, the final SPF record might resemble this shape:

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

Use the other provider's official SPF include domain, not the placeholder shown above. Also account for SPF's DNS lookup limit: a record that causes more than 10 DNS-mechanism lookups can return a permanent SPF error. Nested include statements count toward that limit.

SPF alone is not enough for DMARC because Microsoft 365 messages can use an envelope sender domain that differs from the visible From: domain. DKIM is usually the cleaner aligned authentication path for Exchange Online mail.

DKIM for Microsoft 365 custom domains

Microsoft 365 can DKIM-sign mail using your custom domain, but you need to create two CNAME records first and then enable DKIM in the Microsoft Defender portal.

The records use these names:

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

The target values are tenant-specific and service-specific. Do not guess or copy a CNAME target from another tenant. In Microsoft 365, open the DKIM configuration for the exact custom domain and copy the two CNAME targets Microsoft provides. Microsoft can use targets under its DKIM infrastructure, and the values can differ from examples found in old documentation or blog posts.

After publishing both CNAME records, enable DKIM signing for the domain in the Microsoft Defender portal. The portal path can change, but Microsoft documents DKIM under its email authentication settings. Send a fresh test email after enabling it; old mail will not acquire a DKIM signature retroactively.

Inventory every sender before enforcement

The most common failed DMARC rollout is not a DNS typo. It is publishing p=reject while a legitimate system is still sending as you@example.com without aligned DKIM or SPF.

Microsoft 365 is often only one sender among many. Create a sender inventory before changing policy.

Include at least these categories:

1. Microsoft 365 user mailboxes — Outlook, Outlook on the web, mobile clients, shared mailboxes, and distribution workflows.
2. Application and transactional email — product notifications, password resets, receipts, monitoring alerts, CI/CD notices, and CRM workflows.
3. Marketing and event platforms — newsletters, webinar invitations, recruitment campaigns, surveys, and automated sequences.
4. Support and ticketing systems — help desk replies, knowledge-base notifications, and customer-service tools.
5. Devices and relays — printers, scanners, VoIP systems, building systems, ERP servers, and on-premises SMTP relays.
6. External agencies and vendors — systems managed by a marketing agency, franchise operator, regional office, or acquired business.
7. Subdomains and dormant domains — news.example.com, alerts.example.com, typo domains, parked domains, and domains that do not send mail at all.

For every sender, record the visible From domain, envelope sender domain, DKIM signing domain, owner, purpose, and remediation status. This turns vague DMARC reporting into a practical deployment plan.

A useful sender inventory table looks like this:

Dedicated subdomains make this easier. Rather than allowing an external bulk-mail provider to send as your primary corporate domain, use a domain such as news.example.com or updates.example.com when the provider supports custom-domain authentication. That contains risk, improves sender ownership, and lets you apply a subdomain-specific DMARC policy when appropriate.

A safe rollout from monitoring to reject

Start with reporting, not enforcement. Monitoring reveals senders you did not know existed and shows whether their mail authenticates and aligns.

Phase 1: Publish monitoring mode

Publish:

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

p=none means you are asking for reports but not asking receivers to quarantine or reject messages that fail. It does not protect against spoofing by itself.

Keep monitoring until you can explain the meaningful traffic in the reports. There is no universal number of days because some systems send only monthly invoices, quarterly notices, or exception alerts. The key test is coverage of your real mail cycles, not the passage of an arbitrary number of days.

Phase 2: Fix legitimate failures

For each legitimate source that fails DMARC, choose one of these remedies:

• Enable the sender's custom-domain DKIM feature and make its d= domain align with the visible From domain.
• Configure an aligned envelope sender or custom return-path domain so SPF can align.
• Move the sender to a dedicated subdomain and publish SPF, DKIM, and DMARC for that subdomain.
• Relay the application through Microsoft 365 or another controlled SMTP service that supports authenticated sending.
• Change the application's visible From address so it does not claim your primary domain.
• Retire the sender if it is no longer approved.

Avoid the tempting workaround of weakening your root SPF record to accommodate every vendor indefinitely. SPF is limited, vendors change infrastructure, and basic SPF pass alone may still fail DMARC because of alignment.

Phase 3: Quarantine failing mail

Once legitimate sources are authenticated, change the policy to:

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

Continue monitoring. A quarantine policy requests suspicious handling, but mailbox providers can make their own delivery decisions. It is a useful transition because it exposes remaining mistakes with less impact than rejection.

Phase 4: Reject unauthorized mail

When your reporting shows that the intended sources consistently pass DMARC, use:

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

A p=reject policy is the desired final state for a domain that sends mail. It tells participating receivers to reject messages that claim to be from your domain and fail aligned SPF and DKIM.

For a domain that never sends mail, use a strict policy too:

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

That is particularly useful for parked domains and defensive domains that attackers could otherwise use in impersonation attempts.

Worked example: Contoso-style M365 setup

Assume acmeexample.com uses Microsoft 365 for employee email. Its marketing platform sends newsletters from news.acmeexample.com, and its product application sends receipts from notify.acmeexample.com.

The company should not force all three systems into a single root-domain configuration. Instead, it can make every sender responsible for its own authenticated sending identity.

Step 1: Configure the root domain for Microsoft 365

At the DNS provider, create or update the single SPF TXT record for acmeexample.com:

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

In Microsoft 365, open the DKIM settings for acmeexample.com. Copy the two CNAME records shown by Microsoft, create them at the DNS provider, wait until public DNS resolves them, then enable DKIM for the domain.

Next, create this DMARC TXT record:

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

Step 2: Authenticate the newsletter subdomain

In the newsletter provider, configure news.acmeexample.com as a verified sending domain. The provider should supply the exact DKIM records and possibly a custom return-path or SPF configuration.

Publish a separate DMARC record for the subdomain if you want independent reporting and policy control:

Host: _dmarc.news
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@acmeexample.com; adkim=r; aspf=r

DNS host fields differ by provider. The intended full name is _dmarc.news.acmeexample.com.

Step 3: Authenticate application receipts

Configure the application's sender as receipts@notify.acmeexample.com. Use the application's custom-domain DKIM setup, then publish the DNS records it provides.

Publish a DMARC record for notify.acmeexample.com if that system is independently managed:

Host: _dmarc.notify
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@acmeexample.com; adkim=r; aspf=r

Step 4: Review reports, then enforce

The reports should show Microsoft 365 mail passing through an aligned Microsoft 365 DKIM signature, newsletter mail passing through the marketing provider's aligned signature, and receipts passing through the product provider's aligned signature.

After every legitimate source is understood and consistently passes, change each active sending domain to p=quarantine, then ultimately p=reject. Do not assume that a parent-domain p=reject is automatically the best operational policy for every subdomain; evaluate each sender and use explicit subdomain records when you need independent ownership or reporting.

How to check that the record is published

DNS propagation timing depends on your DNS provider, TTL, recursive resolvers, and cached responses. Validate the live public DNS result rather than relying only on a success message in your DNS dashboard.

From a terminal, query the record:

nslookup -type=TXT _dmarc.example.com

On systems with dig, use:

dig TXT _dmarc.example.com +short

You should see one DMARC value beginning with v=DMARC1.

Check SPF too:

dig TXT example.com +short

Look for a single string beginning with v=spf1. Your domain may have other TXT records for Microsoft verification or services; that is normal. The issue is multiple separate SPF records, not multiple unrelated TXT records.

For DKIM, query the selectors Microsoft provided:

dig CNAME selector1._domainkey.example.com +short
dig CNAME selector2._domainkey.example.com +short

The returned CNAME targets should match the values displayed in Microsoft 365 for your custom domain.

How to verify DMARC in a real email message

A DNS lookup proves publication, not correct message authentication. Send a fresh test message from Microsoft 365 to an external mailbox you control, then inspect the complete message headers.

Look for an Authentication-Results header. The exact format varies by receiving system, but a healthy result commonly contains indicators similar to:

spf=pass
 dkim=pass
dmarc=pass

Then inspect the identifiers:

• SPF should show the domain evaluated for the envelope sender.
• DKIM should show a signature such as d=example.com or a permitted aligned subdomain.
• DMARC should show that the visible header.from domain passed policy evaluation.

For Microsoft 365-originated mail, confirm that DKIM is not merely signed by a Microsoft-owned service domain. The DKIM signature that satisfies DMARC should align with the visible From domain. That is why enabling custom-domain DKIM matters.

A valid result might look conceptually like this:

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

The values will vary by recipient system. Focus on the pass/fail result and the domains named after smtp.mailfrom, header.d, and header.from.

Reading aggregate DMARC reports

Aggregate reports are usually compressed XML files sent by participating receivers to the rua address. They are not intended for convenient manual reading at scale.

A report can reveal:

• Source IP addresses sending messages that claimed to be from your domain.
• Counts of messages associated with each source and authentication result.
• SPF and DKIM pass/fail outcomes.
• Whether SPF or DKIM aligned with the visible From domain.
• The DMARC policy the reporting receiver discovered and applied.
• Policy override reasons, where a receiver did not apply the requested disposition exactly.

Do not automatically trust a familiar IP address. First determine which service owns it, whether it is authorized, and whether it is sending under the expected domain. An unrecognized source that fails DMARC is often spoofing, but it can also be an old application, consultant-managed platform, or acquired system that was never documented.

A DMARC reporting platform can parse the XML and group mail streams by vendor, IP, domain, and failure reason. That can be worthwhile for organizations with many domains or senders. For a low-volume domain, a dedicated mailbox and careful periodic review may be enough during the initial audit.

Common M365 DMARC mistakes and fixes

Publishing p=reject before enabling DKIM

A basic Microsoft 365 SPF record may authorize Exchange Online, but SPF alignment can fail depending on how mail is sent and what envelope sender is used. Enable DKIM for each Microsoft 365 custom domain before relying on enforcement.

Multiple SPF records

Publishing two records beginning with v=spf1 produces an SPF permanent error. Merge mechanisms into one record and remove the extra SPF TXT record.

Using an old or guessed DKIM CNAME target

Microsoft 365 DKIM CNAME targets are specific to the tenant and configuration. Copy the two current values from the Defender portal for the domain you are configuring. If the portal cannot verify the records, confirm the hostnames, CNAME targets, DNS provider behavior, and public DNS response.

Authorizing a vendor in SPF but not aligning it

Adding a vendor include can make SPF pass for the vendor's envelope sender domain, yet DMARC still fails if that domain does not align with the visible From domain. Prefer the vendor's custom DKIM configuration or a custom aligned return-path domain.

Forgetting subdomains

A root-domain record does not eliminate the need to understand mail sent as news.example.com, billing.example.com, or alerts.example.com. Use sp= only when you deliberately want one policy for undisclosed subdomains. Publish dedicated records for important sending subdomains.

Treating p=none as protection

Monitoring mode provides visibility but does not ask receivers to block or quarantine DMARC failures. It is a deployment stage, not the end state for a domain that needs anti-spoofing protection.

Ignoring forwarded mail and mailing lists

Forwarding commonly breaks SPF because the forwarding server's IP is not in the original sender's SPF record. DKIM can survive forwarding when the message remains unmodified, but mailing lists and gateways may alter signed content. Investigate these flows from actual headers and reports rather than weakening the entire domain policy immediately.

Sending from consumer or unmanaged SMTP services

Printers, websites, legacy applications, and scripts often bypass Microsoft 365 entirely. If they use From: user@example.com without supported aligned authentication, a final reject policy can disrupt their delivery. Route them through an approved sending service or assign a properly authenticated subdomain.

Microsoft 365 inbound DMARC and spoofing protection

Publishing your own DMARC record protects your domain when other organizations receive mail that claims to be from you. It does not replace inbound anti-phishing controls inside Microsoft 365.

For inbound mail, Exchange Online evaluates sender authentication and uses that information in its filtering decisions. Organizations should also configure anti-phishing policies, user and domain impersonation protections, safe handling for external mail, and mail-flow controls appropriate to their environment.

Be especially cautious with internal-looking messages. A message that displays an employee's name or uses your domain in a From header is not automatically legitimate. Authentication results, message routing headers, and Microsoft 365 threat investigation tools help distinguish real internal mail from spoofed or misrouted traffic.

Operational checklist before changing to reject

Use this checklist before setting p=reject on a production domain:

• The domain has exactly one SPF record.
• The SPF record authorizes Microsoft 365 and every remaining approved sender.
• Microsoft 365 custom-domain DKIM is enabled and signs new outbound mail.
• Every external sender uses aligned DKIM, aligned SPF, or both.
• Aggregate reports are delivered to and reviewed at the rua destination.
• Unknown failing sources have been investigated.
• Legacy devices, relays, applications, and vendors have been tested.
• Important subdomains have explicit ownership and authentication plans.
• You have tested fresh mail headers from Microsoft 365 and each external sender.
• You have a documented rollback process if a missed sender is discovered.

The rollback is simple: change the policy back to p=none or p=quarantine, but DNS caching means it is not instantaneous everywhere. That is another reason to monitor thoroughly before enforcement.

Conclusion

The best DMARC record M365 deployment is not just a copied TXT value. It is a managed authentication program: publish a monitoring record, enable custom-domain DKIM in Microsoft 365, identify every authorized sender, correct alignment failures, validate live headers, and only then enforce with quarantine and reject.

For an M365-only root domain, the core DNS starting point is straightforward: Microsoft 365 in SPF, Microsoft-generated DKIM CNAME records, and a DMARC record at _dmarc.yourdomain.com. The real work is making sure every system that sends as your domain can prove it is authorized.

FAQ

What is the DMARC record for Microsoft 365?

A common initial record is v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; adkim=r; aspf=r. Publish it as a TXT record at _dmarc.yourdomain.com, then progress to p=quarantine and p=reject after reviewing legitimate senders.

Does Microsoft 365 create my DMARC record automatically?

No. Microsoft manages DNS for its own onmicrosoft.com domains, but you must publish a DMARC TXT record for a custom domain at the DNS provider that hosts that domain.

Do I need DKIM if I already have the Microsoft 365 SPF record?

Yes. SPF and DKIM serve different purposes, and DMARC requires aligned SPF or aligned DKIM. DKIM is strongly recommended because SPF often fails during normal forwarding and external services may use an envelope sender that does not align with your visible From domain.

What should I put in the DMARC rua tag?

Use a mailbox or DMARC reporting service you control, for example rua=mailto:dmarc-reports@yourdomain.com. Ensure it can receive compressed XML aggregate reports and that someone reviews them.

Why does my Microsoft 365 message fail DMARC when SPF passes?

A basic SPF pass is not enough. The SPF-authenticated envelope sender domain must align with the visible From domain. Check the message headers, enable custom-domain DKIM in Microsoft 365, and verify that the DKIM d= domain aligns with the header From domain.