DMARC Record Microsoft 365: Complete Setup, Testing, and Enforcement Guide

A DMARC record Microsoft 365 setup protects your domain from direct spoofing and gives receiving mail systems clear instructions for handling unauthenticated messages. The safe approach is to establish SPF and DKIM first, publish DMARC in monitoring mode, inspect real sending sources, and only then move to quarantine or reject.

What a DMARC record does for Microsoft 365

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It is a DNS-based policy that tells a receiving mailbox provider what to do when an email claiming to be from your domain fails authentication.

For example, an attacker can send a message with a visible From: address of ceo@example.com without ever having access to Microsoft 365 or to example.com. A correctly configured DMARC policy lets Gmail, Outlook.com, Yahoo, corporate gateways, and other receivers determine whether that message was genuinely authorized by example.com.

DMARC does not encrypt email, block every phishing message, or fix poor sender reputation by itself. Its main job is preventing unauthorized use of the domain in the visible RFC 5322 From: header. It also produces aggregate reports that reveal which services are sending mail using your domain.

A DMARC pass requires at least one of these conditions:

1. SPF passes and the SPF-authenticated domain aligns with the visible From: domain.
2. DKIM passes and the DKIM signing domain (d=) aligns with the visible From: domain.

Alignment is the essential extra layer. A message may pass SPF for some-mailer.example but still fail DMARC if its visible From: header says billing@yourdomain.com and the authenticated domain does not align.

Microsoft 365 can send properly authenticated mail, but it cannot automatically authenticate every application, legacy relay, website form, CRM, ticketing system, scanner, and marketing platform that uses your domain. That inventory work is why moving directly to p=reject can break legitimate mail.

Before creating a DMARC record for Microsoft 365

A DMARC TXT record is simple to publish. The difficult part is confirming that all legitimate senders are configured to pass SPF or DKIM with alignment.

Inventory every sender, not just Exchange Online

Start by listing every system that can send mail with a visible From: address at your domain. Include services that send only occasionally, such as invoice platforms or disaster-recovery systems.

Common sources include:

• Microsoft 365 / Exchange Online user mailboxes
• Shared mailboxes and Microsoft 365 groups
• Applications using SMTP AUTH or authenticated SMTP submission
• Printers, scanners, multifunction devices, and on-premises line-of-business applications
• Website contact forms, password reset email, and ecommerce platforms
• Customer support systems, CRMs, accounting tools, recruiting platforms, and booking tools
• Email marketing providers and event platforms
• Transactional email APIs
• Third-party IT providers that send monitoring, backup, security, or alert messages

Record the domain used in the visible From: address for each source, the person who owns it, how it currently authenticates, and whether the source can sign mail with DKIM using your domain. This is more useful than maintaining a list of IP addresses alone.

If you operate multiple domains, treat each organizational domain separately. A DMARC record on example.com does not automatically create a policy for example.co.uk. Subdomains have inheritance rules, but they should still be reviewed explicitly before enforcing policy.

Check your existing DNS records

Before editing DNS, look for these records:

• One SPF TXT record at the root of the sending domain
• Microsoft 365 DKIM CNAME records for the domain
• An existing _dmarc TXT record
• SPF includes, custom return-path records, and DKIM selectors supplied by third-party senders

Do not create a second SPF record. SPF evaluation can return a permanent error when multiple SPF TXT records are published for the same domain, which can make a previously working configuration fail.

A domain can have multiple DKIM selectors because different sending services can sign with different selectors. It can have only one DMARC record at _dmarc.example.com.

Configure SPF for Microsoft 365 correctly

For a domain that sends only through Microsoft 365, Microsoft documents this SPF record pattern:

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

Some DNS providers display the root host as @; others require the domain name or leave the host field blank. The resulting DNS name must be example.com, not @.example.com.

The include:spf.protection.outlook.com mechanism authorizes the Microsoft 365 outbound infrastructure. The -all mechanism is a hard fail for all other sources. Use -all only after ensuring the record represents every legitimate sender.

Adding third-party senders to SPF

If a legitimate vendor requires SPF authorization, its documentation may provide a mechanism such as include:spf.vendor.example. Add it to the existing SPF record, for example:

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

Do not replace your Microsoft 365 include with the vendor’s include, and do not publish the vendor’s line as a separate TXT record. Both mistakes can cause authentication failure.

SPF has a limit of 10 DNS-query-causing mechanisms and modifiers during evaluation. Nested include mechanisms count toward that limit. A sprawling SPF record with many vendors can therefore produce permerror, even if its text looks reasonable. When this happens, prioritize DKIM for vendors that support it, use a vendor’s dedicated custom return-path domain where available, and remove obsolete services rather than trying to add every historical platform indefinitely.

SPF does not always provide DMARC alignment

A message can pass SPF yet fail DMARC alignment. This is common when a platform uses its own bounce or return-path domain, such as mailer.vendor.example, while showing news@example.com in the visible From field.

That is not automatically a delivery problem if the platform also signs with aligned DKIM, such as d=example.com or an aligned subdomain. For this reason, DKIM is generally the more durable authentication method for SaaS senders.

Enable DKIM signing in Microsoft 365

For Microsoft 365 mail, enable DKIM for every accepted custom domain used in visible From addresses. DKIM adds a cryptographic signature to outbound messages. Receiving servers validate that signature through a public key published in DNS.

Microsoft 365 uses two selector CNAME records, typically selector1 and selector2. The exact target values depend on your Microsoft 365 tenant’s initial onmicrosoft.com domain, so copy the values shown for your domain in the Microsoft 365 Defender portal rather than guessing them.

The required pattern is typically similar to this:

Host/Name: selector1._domainkey.example.com
Type: CNAME
Points to: selector1-example-com._domainkey.exampletenant.onmicrosoft.com

Host/Name: selector2._domainkey.example.com
Type: CNAME
Points to: selector2-example-com._domainkey.exampletenant.onmicrosoft.com

In many DNS interfaces, enter only selector1._domainkey and selector2._domainkey in the host field because the provider appends example.com. Entering the full domain into a provider that auto-appends it can accidentally create selector1._domainkey.example.com.example.com.

Turn on the DKIM keys after publishing CNAMEs

Publishing CNAME records alone does not necessarily cause Exchange Online to sign mail. In the Microsoft 365 Defender portal, go to the DKIM settings area, select the custom domain, and enable DKIM signing after Microsoft confirms the CNAME records are available.

The portal wording and navigation can change, but the practical sequence does not:

1. Select the custom domain in Microsoft 365’s DKIM configuration.
2. Copy the two CNAME names and targets it supplies.
3. Publish those CNAME records at your DNS host.
4. Wait for DNS publication and validation.
5. Enable DKIM for the domain.
6. Send a test message and inspect its authentication headers.

Microsoft uses two selectors to support key rotation. Do not delete either record just because one selector appears in current message headers.

Verify DKIM from a real received message

Send from a Microsoft 365 mailbox at your custom domain to a mailbox you control outside your tenant. In the received message’s original headers, find the Authentication-Results line and the DKIM-Signature header.

You want to see a result resembling:

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

The formatting varies by recipient. What matters is dkim=pass and an aligned header.d domain. A signature from example.onmicrosoft.com does not align with a visible From domain of example.com under strict alignment, and may not align under relaxed alignment either. Configure and enable DKIM for the actual custom domain.

For application and vendor mail, repeat this test per service. A successful Microsoft 365 mailbox test says nothing about your website platform or CRM.

The exact DMARC record syntax to publish

A DMARC record is a DNS TXT record placed at _dmarc under the domain. A practical starting record for Microsoft 365 is:

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

This creates the DNS record _dmarc.example.com. Replace example.com in the reporting address with a mailbox or reporting service endpoint you control.

Each tag has a specific role:

DMARC tags are separated by semicolons. DNS services may display long values in quoted chunks; that is acceptable when the DNS provider formats one logical TXT value. Do not add line breaks, smart quotes, or a second TXT record at _dmarc.

Why p=none is not enforcement

p=none asks receivers to take no DMARC-specific action against failing messages. It is a monitoring policy, not domain-spoofing protection. Receivers can still apply their own spam and phishing filters, but DMARC itself is not asking them to quarantine or reject the message.

The purpose of this phase is to learn. Aggregate reports identify known and unknown mail streams, their passing or failing authentication, their source IPs, and their reported volume. It commonly exposes old vendors, unsanctioned tools, and services configured with a visible From domain they are not authorized to use.

Strict versus relaxed alignment

By default, DMARC uses relaxed alignment for SPF and DKIM unless you specify otherwise. Under relaxed alignment, mail.example.com can align with example.com because the domains share the same organizational domain. Strict alignment requires an exact match.

You can explicitly set strict alignment like this:

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

Do not treat strict alignment as automatically “more secure” in every deployment. It is useful when you deliberately control all subdomain sending and want an exact domain match. It can also break valid mail from systems that correctly use aligned subdomains but not the exact parent domain. Start relaxed, understand the traffic, then decide whether strict alignment serves a real policy goal.

A worked Microsoft 365 DMARC setup example

Assume Contoso uses contoso.com for Microsoft 365 mail. It also sends password reset messages through an application vendor and a monthly newsletter through a marketing platform.

Step 1: Build the sending map

Contoso documents these streams:

The copier is changed to submit through a supported Microsoft 365 route rather than sending directly from the office’s public IP. This reduces the number of independent sources that must be managed and avoids creating a brittle SPF exception for changing ISP addresses.

Step 2: Publish and enable Microsoft 365 DKIM

Contoso copies the two DKIM CNAME targets shown in its Microsoft 365 tenant. It publishes both CNAMEs, waits until they resolve publicly, enables DKIM in Microsoft 365, then sends a test from admin@contoso.com to an external mailbox.

The received headers show dkim=pass with header.d=contoso.com. That confirms aligned DKIM for regular Exchange Online mail.

Step 3: Configure the vendors

The application vendor provides CNAME records for a DKIM selector and confirms that it will sign as d=contoso.com. Contoso publishes those vendor-supplied records.

The marketing platform provides three CNAME records for branded tracking and DKIM. Contoso publishes them and verifies a test campaign header shows dkim=pass header.d=contoso.com. If the platform supports only d=marketingvendor.example and cannot use an aligned custom domain, Contoso should not send it as @contoso.com while expecting DMARC to pass. It should configure the vendor’s domain-authentication feature or use a separate properly authenticated sending domain.

Step 4: Publish the monitoring record

Contoso creates a dedicated reporting destination, then publishes:

_dmarc.contoso.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@contoso.com; pct=100"

A dedicated mailbox can work at small volume, but raw DMARC aggregate reports are compressed XML and become difficult to interpret. A DMARC reporting service can group sources, visualize pass rates, and flag new senders. If you are operating a high-volume transactional program, consider reporting and authentication requirements alongside transactional email pricing rather than selecting a sender solely on its per-message cost.

Step 5: Review reports and remediate failures

Contoso examines reports over a complete business cycle, including a newsletter date, month-end invoices, and scheduled application jobs. It finds an old help-desk service sending as support@contoso.com with SPF and DKIM both failing.

The team either configures custom DKIM in that help-desk service, routes its mail through a supported authenticated path, changes its From domain, or retires it. It does not simply add an arbitrary IP to SPF without understanding whether that source can maintain aligned authentication.

Step 6: Enforce gradually

After all legitimate streams pass aligned SPF or DKIM, Contoso changes the policy to:

v=DMARC1; p=quarantine; rua=mailto:dmarc@contoso.com; pct=25

It watches reports and delivery feedback. If no legitimate failures appear, it increases pct over time, then uses:

v=DMARC1; p=quarantine; rua=mailto:dmarc@contoso.com; pct=100

Finally, once the organization is confident in its sender inventory and ongoing monitoring, it publishes:

v=DMARC1; p=reject; rua=mailto:dmarc@contoso.com; pct=100

p=reject is the strongest requested disposition. It asks receivers to reject messages that fail DMARC rather than accept or place them in spam. Receiving systems ultimately make their own delivery decisions, but a reject policy is the clear standard for a domain that should not be impersonated.

Read DMARC reports without missing the important signals

Aggregate reports are generally sent by participating receivers on their own schedules. They are machine-readable XML files, often delivered as .zip or .gz attachments. They contain counts rather than copies of individual messages.

Each report record commonly identifies:

• The source IP address observed by the receiver
• The number of messages represented by that record
• The policy domain and published disposition
• SPF and DKIM evaluation results
• The visible From domain used for DMARC evaluation
• Identifiers that help establish whether SPF or DKIM aligned

A large count from Microsoft 365 infrastructure that passes aligned DKIM is expected. A low-volume unknown IP is not necessarily an attack: it could be a forgotten SaaS tool, a consultant’s system, or an application that runs once per month. Investigate it before enforcement.

Distinguish spoofing from a broken legitimate service

A source is more likely spoofing when it has no known business owner, fails both SPF and DKIM, uses an unrelated IP range, and appears in a pattern that does not match business activity. Once you publish p=reject, those messages are exactly what you want receivers to block.

A source is more likely legitimate but broken when report timing matches a known campaign or system job, the From local part is recognizable, or an internal owner confirms use of the platform. The remediation is authentication configuration, not an exemption in DMARC. DMARC has no safe “allow this random IP” mechanism; authorization must be expressed through aligned SPF or DKIM.

Common Microsoft 365 DMARC mistakes and fixes

Publishing multiple SPF records

Symptom: SPF returns permerror, and DMARC may fail where DKIM is absent.

Fix: Consolidate all authorized SPF mechanisms into one TXT record beginning with v=spf1. Remove old duplicate SPF records after confirming the combined record covers every legitimate source.

Forgetting to enable DKIM after DNS is ready

Symptom: The CNAME records resolve, but outbound message headers do not show a DKIM pass for your custom domain.

Fix: Enable DKIM for that custom domain in the Microsoft 365 security administration experience. DNS publication is necessary, but the tenant setting must also be active.

Putting the DMARC record at the wrong hostname

Symptom: A checker cannot find DMARC, or it finds a malformed record.

Fix: Publish at _dmarc.example.com. In a DNS provider that appends the domain automatically, use _dmarc as the host, not _dmarc.example.com unless the interface explicitly expects a full name.

Moving to reject before third-party mail is authenticated

Symptom: Password reset, invoicing, ticketing, or campaign messages disappear after policy enforcement.

Fix: Return temporarily to a less aggressive policy only if needed to protect business mail, identify the failing source in reports, and configure aligned DKIM or SPF. Then resume the staged rollout.

Trusting SPF alone for SaaS mail

Symptom: A vendor says its SPF passes, yet the message fails DMARC.

Fix: Inspect the envelope sender / return-path domain and the DKIM d= domain. Configure the vendor’s domain-authentication option so one of those identifiers aligns with your visible From domain.

Sending directly from devices or applications

Symptom: Printers and on-premises apps fail DMARC unpredictably, especially after ISP or infrastructure changes.

Fix: Use a supported Microsoft 365 submission or relay design where appropriate, or give the application a deliberately configured sending service with DKIM. Avoid treating a changing public IP address as a long-term mail identity.

How to test that your DMARC record worked

DNS lookup alone is necessary but insufficient. A record can exist and still fail to protect mail if DKIM is disabled, a vendor is misconfigured, or a policy remains p=none forever.

Use this validation checklist:

1. Query _dmarc.example.com and confirm there is exactly one valid TXT value beginning with v=DMARC1.
2. Query the two Microsoft 365 DKIM selector CNAME records and confirm they resolve to the tenant-specific targets Microsoft supplied.
3. Send a message from a Microsoft 365 mailbox to an external recipient and inspect original headers for spf=pass, dkim=pass, and dmarc=pass.
4. Send a test from each third-party platform using your domain in the visible From header and inspect the same results.
5. Confirm aggregate reports arrive at the rua destination or appear in your DMARC monitoring service.
6. During monitoring, investigate every meaningful failed source before raising the policy.
7. After publishing quarantine or reject, repeat tests and watch reports for legitimate failures.

A successful header result may look generally like this:

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

The exact header names and order differ across mailbox providers. The reliable outcome is dmarc=pass for legitimate mail, plus reports showing your known senders passing at expected volumes.

For individual addresses, verify the recipient exists before sending important messages with an email address verification tool. Address validation does not replace DMARC; it helps reduce bounces, while DMARC establishes domain-level sender authenticity.

DMARC policies, subdomains, and parked domains

A parent-domain DMARC policy can affect subdomains when those subdomains do not publish their own DMARC record. You can specify an explicit subdomain policy with sp=:

v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@contoso.com

This example requests rejection for contoso.com and quarantine for subdomains that inherit the policy. Use this only when you know which subdomains send mail and which publish their own records.

If your organization has domains that never send email, they still benefit from DMARC. A common end state is a strict policy such as:

v=DMARC1; p=reject; rua=mailto:dmarc@contoso.com

For a non-sending domain, first verify that it truly has no legitimate sender, including web forms, forwarding services, or old application configurations. A reject policy then reduces its attractiveness for impersonation.

Do not assume a p=reject policy on the parent makes every subdomain safe without review. Marketing, regional, product, and application teams frequently create subdomains for sending platforms. Each one is part of your attack surface and sender inventory.

Operational ownership after enforcement

DMARC is not a one-time DNS project. New software purchases, agency campaigns, acquisitions, and application changes can introduce a sender that fails alignment.

Assign clear ownership across IT, security, marketing, and application teams. A useful operating process is:

• Require authentication review before any vendor sends mail as your domain.
• Prefer vendors that support custom aligned DKIM.
• Keep a sender inventory with owner, purpose, From domain, return-path domain, DKIM selector, and renewal date.
• Review DMARC reports regularly and investigate new sources.
• Retest after changes to DNS, tenant configuration, email providers, or branded domains.
• Retire SPF includes and DKIM records only after confirming the associated service no longer sends.

Microsoft 365 administrators should also separate inbound and outbound concerns. Microsoft 365’s anti-phishing and anti-spam controls help evaluate messages arriving in your tenant. Your public DMARC record tells external receivers how to evaluate messages that claim to be from your domain. Both matter, but one does not substitute for the other.

Conclusion: the safe path to DMARC enforcement in Microsoft 365

The correct DMARC record Microsoft 365 configuration begins with aligned authentication, not with an aggressive policy. Publish one accurate SPF record, enable Microsoft 365 DKIM for every custom sending domain, configure aligned DKIM for external platforms, and use p=none reports to discover what is actually sending.

When legitimate mail consistently passes DMARC, progress through quarantine to reject with ongoing monitoring. The result is measurable: authorized mail shows dmarc=pass, aggregate reports identify expected sources, and spoofed messages using your visible domain are subject to the policy you publish.

FAQ

What is the basic DMARC record for Microsoft 365?

A safe monitoring record is v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100, published as a TXT record at _dmarc.example.com. It collects reports but does not request quarantine or rejection of failures.

Does Microsoft 365 automatically set up DMARC?

No. Microsoft 365 can provide and use SPF and DKIM settings for your domain, but your organization must publish and manage its DMARC TXT record in public DNS. You must also configure third-party senders that use your domain.

Should I use p=quarantine or p=reject?

Start with p=none while you analyze reports. Use p=quarantine as a staged enforcement step, then use p=reject after legitimate sources are authenticated and monitored. Reject is the strongest request for blocking direct spoofing.

Why does my Microsoft 365 email pass SPF but fail DMARC?

SPF must align with the visible From domain to satisfy DMARC. The envelope sender may use a Microsoft or vendor domain that does not align. Enable DKIM on your custom Microsoft 365 domain; an aligned DKIM pass can satisfy DMARC even when SPF alignment does not.

How long should a domain remain at p=none?

Keep monitoring until reports cover normal and infrequent business mail cycles and every legitimate sending source passes aligned SPF or DKIM. The right duration depends on your systems and sending schedule, not a fixed number of days.