How to set up a DMARC record in Microsoft 365 in 2026

Setting up DMARC in Microsoft 365 (formerly Office 365) is a four-step process:

1. Navigate to your DNS manager
2. Select a DMARC policy
3. Add a reporting address
4. Publish the TXT record

It’s straightforward for most organizations, but the details matter, and a misconfiguration can block legitimate email or leave your domain unprotected against spoofing.

This guide walks you through the full setup process with real DMARC record examples, covers the policy options and what each one does, and addresses the common issues that Microsoft’s documentation doesn’t fully explain.

What is DMARC?

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is an email authentication protocol that tells receiving mail servers how to handle email that fails SPF or DKIM authentication checks. Domain administrators use DMARC records to publish the email authentication policy used to protect against cyberattacks such as email spoofing and phishing.

DMARC records are published on your DNS as a plain text file, most likely named “_dmarc.yourdomain.com,” where “yourdomain.com” is your actual domain name.

You use DMARC records to instruct receiving servers on what to do with emails that have failed authentication tests. For example, you might request that emails that have failed the authentication test be quarantined into a spam folder, or you might want them to be deleted entirely. 

A DMARC record contains the DMARC policy that informs ISPs (like Gmail, Yahoo!, and Microsoft’s Office 365) if a domain is set up to use DMARC. In Microsoft 365, DMARC works alongside Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) to verify outbound email and protect your domain from impersonation.

SPF and DKIM must be configured and passing before DMARC enforcement will function correctly.

How DMARC works in Microsoft 365

This question is a common one that we hear. We can split the topic up into inbound and outbound mail.

• Inbound mail: For inbound mail, DMARC is automatically set up by Office 365, regardless of whether it is hosted on a custom domain or not.
• Outbound mail: For those not using a custom domain (e.g., their email is hosted at a domain like onmicrosoft.com), their DMARC records are handled automatically. However, some work is required for those with their own custom domain or who use an on-premise exchange server. These customers must configure their DMARC settings for their domain themselves to enable DMARC for outbound mail sending.

How to set up DMARC in Microsoft 365

A few notes before you begin. Enforcing DMARC means setting up Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) beforehand. You’ll also need to ensure that your Office 365 account is connected to your domain and verified. 

Step 1: Navigate to the DNS manager

Before configuring your DMARC records, please go to your domain registrar and navigate to your DNS manager.

DMARC policies are formatted as a TXT file. Add a new TXT file to your DNS records with the following details to create one.

• Fill in the hostname as “_dmarc.yourdomain.com.” This will let you and the system identify this TXT file as a DMARC record.
• Set the TTL to one hour. Depending on your domain registrar, you may have to set it as 1 hour, 60 minutes, or 3,600 seconds.
• The value field is where you’re going to write your DMARC record.

Step 2: Select the DMARC policy

Your DMARC policy outlines the treatment or actions you’d like for emails to take that fail authentication tests.

In your DMARC record, the policy is stored in the “p” tag and is a required entry. There are three types of policies you can choose from:

• None (p=none): The none policy asks the receiving server to treat the email messages as if there is no DMARC authentication policy, but you’ll still get DMARC reports.
• Quarantine (p=quarantine): The quarantine policy asks the receiving server to receive the email anyway but separates it from others. This typically means that the email will land in a spam folder.
• Reject (p=reject): The reject policy asks the receiving server to reject the email from landing in any inbox or folder.

If you don’t have a DMARC record in place, you should start with the p=none policy. It lets you enter the monitoring phase to collect data about your email activity without affecting the deliverability of your emails. You can receive DMARC reports to check the configuration of your DKIM records and SPF records and see the sources of your outbound emails.

Note: On the other hand, new-to-DMARC users shouldn’t set up quarantine and reject policies. If you don’t have someone who’s knowledgeable about DMARC and email security on your team, consider using a service like Valimail to set up your DMARC records.

Step 3: Add a reporting email address

Aggregate reports only contain the overview of the email traffic, such as when the email is sent, the sender’s IP address, and the results from the authentication tests. Aggregate reports are sent daily in an XML file. Use the “rua” tag to specify where to send these reports.

You can also send reports to multiple email addresses by adding a comma between addresses, as shown in this example:

rua=mailto:human@valimail.com,mailto:robot@valimail.com;

Besides aggregate reports, you might also encounter failure or forensic reports when learning about DMARC from other sources. However, these reports are no longer used, as they are not as useful as aggregate reports and can be dangerous.

Step 4: Create the TXT record value

To create the TXT record, all you need to do is combine the previous components we’ve discussed in the “value” field.

In the end, here are the attributes you most likely will need to create to set up your first DMARC record:

v=DMARC1; p=none; rua=mailto:human@valimail.com;

While only the “rua” tag is optional, it’s just as important when you’re setting up your first DMARC record. It lets you receive aggregate reports. These reports contain important data you need to collect when starting out. 

You should see your first DMARC report within 72 hours of creating this text file. However, if you create that text file, you may inadvertently impact the deliverability of your emails without realizing it. To avoid this, start with the p=none policy (unless you’re already at enforcement). 

Note: Your DMARC policy can only request the treatment. However, it’s up to the receiving server to decide what they’d like to do with emails that fail authentication tests.

For example, Microsoft’s Exchange Online Protection (EOP) filtering service marks inbound emails that fail DMARC tests as spoof or spam by default, even if the sending server has a “p=reject” tag. Office 365 treats them this way because certain scenarios make a DMARC check fail, even if they come from a legitimate source.

DMARC record examples for Microsoft 365

Here are the most common DMARC record configurations for Microsoft 365 environments.

Monitoring only: start here if you’re new to DMARC:

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

Use this while you collect data on your email-sending sources. Aggregate reports will arrive without any impact on email delivery. Most organizations should spend two to four weeks at p=none before moving to enforcement.

Quarantine policy: intermediate enforcement:

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

The pct=25 tag applies the quarantine policy to 25% of failing messages, routing them to spam. Gradually increase the percentage (25 → 50 → 75 → 100) as you verify all legitimate senders are passing authentication.

Reject policy: full enforcement:

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

Full enforcement. Failing email is blocked before delivery. The sp=reject tag applies the same policy to subdomains. Only move to this policy once your aggregate reports show all legitimate senders consistently passing authentication.

With multiple reporting addresses and explicit alignment settings:

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@yourdomain.com,mailto:dmarc@thirdparty.com; adkim=r; aspf=r

The adkim=r and aspf=r tags set relaxed alignment for DKIM and SPF respectively, which is the recommended setting for most organizations. Strict alignment (s) requires an exact domain match rather than allowing subdomain matches.

Microsoft 365-specific note: Make sure your SPF record includes include:spf.protection.outlook.com to authorize Exchange Online as a legitimate sender for your domain. Without this, email sent through Microsoft 365 will fail SPF at receiving servers.

Protect your email domains with Valimail’s DMARC services

Now you know how to create DMARC records in Office 365. Although a DMARC record is necessary, maintaining one can be challenging. This is especially true for businesses that may not have a dedicated IT team to protect their domains. Further, maintaining a DMARC record requires you to set up and enable DKIM and SPF, adding even more to what you need to do to secure your domain from malicious cyber attacks.

Enter: Valimail.

Valimail helps businesses set up and automatically update SPF, DKIM, and DMARC records for their Office 365 accounts. Valimail is a trusted Microsoft partner, recommended for ensuring email security across its cloud email products. DMARC implementation and DNS configuration require little to no technical expertise, thanks to our user-friendly authorization tools. This means you can set your authorization once and keep your domain secure forever.

Want to learn more? Start by creating your free Valimail Monitor account for Office 365 users.