What is DMARC for Office 365?
DMARC, or Domain-based Message Authentication, Reporting & Conformance, is a protocol for ensuring that email is
sent from legitimate domains. DMARC is one of the most effective ways of protecting against phishing attacks, domain
spoofing and other email-based threats.
DMARC builds on the widely used SPF and
DKIM
protocols for authenticating email. To pass a
DMARC check
, an email must authenticate with SPF and/or DKIM. Additionally, DMARC requires that all the information about the
sender within the message is aligned, which helps to block email where attackers spoof the "From" header of trusted
organizations. Finally, the
DMARC record
stipulates what the recipient of an email should do with the message if authentication fails.
DMARC is an essential tool for organizations using Microsoft Office 365. While DMARC in Office 365 is enabled for
inbound emails by default, organizations that use their own domain must manage DMARC monitoring on their own and
configure their own DMARC records.
How to Configure DMARC in Office 365
Setting up DMARC in Office 365 starts in your domain’s DNS, not inside the Microsoft 365 admin center. The goal is to
publish a DMARC TXT record that tells receiving mail servers how to handle messages that fail authentication and where
to send reporting data.
1. Go to your DNS manager
Open your domain registrar or DNS hosting provider and navigate to the DNS management area for the domain you want to
protect. Create a new TXT record and use:
-
Host/Name: _dmarc.yourdomain.com (or just _dmarc, depending on your provider)
-
TTL: 1 hour (may appear as 3600 seconds)
-
Value: Your DMARC policy string
2. Choose your DMARC policy
The policy is set in the required p= tag and tells receiving servers how to handle messages that fail DMARC. You can
choose from:
-
p=none – monitors email activity without changing delivery behavior
-
p=quarantine – sends failing messages to spam or junk
-
p=reject – blocks failing messages from reaching inboxes
If you are setting up DMARC for the first time, start with p=none. This gives you visibility into your email traffic
before moving to stricter enforcement.
3. Add a reporting address
Use the rua= tag to receive an aggregate DMARC report. These reports show which servers are sending mail on your
behalf and whether
SPF
and DKIM are passing. Example:
-
rua=mailto:reports@yourdomain.com;
You can also send reports to more than one address by separating them with commas.
4. Build and publish the full DMARC record
Combine the required version tag, your policy, and your reporting address in the TXT value field. A simple starting
record looks like this:
-
v=DMARC1; p=none; rua=mailto:reports@yourdomain.com;
Once saved, DNS changes can take time to propagate, and reports may begin arriving within the next few days.
If you want to speed up setup and reduce formatting errors, a
DMARC record generator can help you create a properly structured TXT value before you publish it.
5. Review reports before moving to enforcement
After publishing your record, monitor aggregate reports to confirm that legitimate Microsoft 365 mail and any
third-party senders are authenticating correctly. Once you’ve verified alignment and fixed any issues, you can move
from:
-
p=none → p=quarantine → p=reject
This phased approach helps reduce the chance of legitimate mail being flagged while you strengthen protection against
spoofing.
Regularly reviewing aggregate reports also helps support
DMARC compliance by showing whether your legitimate senders are properly aligned before you move to stricter enforcement.
DMARC tells receiving servers what action you request, but the receiving system still decides how to handle failed
mail. In Microsoft environments, some failed messages may still be treated as spoofed or spam based on Exchange Online
Protection and other filtering logic.