Skip to main content
DMARC 5 min read

Do Office 365 Users Need DMARC? Configuring DMARC for Office 365

Brad Slavin
Brad Slavin General Manager
Updated May 8, 2025

Quick Answer

Office 365 users do need DMARC. Microsoft enables outbound DMARC but doesn't provide reporting or monitoring, and it lacks visibility into SPF and DKIM configuration, leaving the domain exposed to spoofing without warning. For inbound mail, Office 365 honors DMARC automatically. For outbound mail on the onmicrosoft.com domain, SPF and DKIM are set up by default. For a custom domain: (1) inventory authorized sending IPs and check that 5321.MailFrom and 5322.From align for third-party senders; (2) generate an SPF TXT record starting with v=spf1, ending in -all (hardfail) or ~all (softfail), avoiding the deprecated ptr mechanism, and using include: for vendors; (3) set up DKIM with your own keys (relying on Microsoft 365 default DKIM can cause DMARC failures because of MailFrom/From mismatch); (4) publish a DMARC TXT record with v= and p= (none, quarantine, or reject) and add rua and ruf for reporting. Recommended rollout: start at p=none for 3 to 4 weeks, move to p=quarantine, then p=reject using the pct tag to ramp gradually. Set explicit subdomain policies (sp=) where needed. The post recommends against DIYing the rollout because of the cost of misconfiguration.

DMARC for Office 365

If you are seeking a one-liner answer to ‘Do Office 365 users need DMARC?’ then it’s ‘Yes, they do need DMARC protection.

Here’s a more explanatory answer to help you understand everything better.

While DMARC can be enabled for outbound emails in Office 365, it doesn’t offer reporting and monitoring, which means it can’t replace third-party email protection. This keeps Office 365 users at a high risk of phishing and domain spoofing, underlining the need to configure SPF, DKIM, and DMARC.

This Microsoft platform lacks a mechanism to provide visibility into SPF or DKIM configuration, which gives a hacker the opportunity to infiltrate your email ecosystem without tipping you off at all. 

Configuring DMARC for Inbound Emails Received in Office 365

As users, you don’t have to do anything to set up DMARC for inbound emails. 

Configuring DMARC for Outbound Emails Sent From Office 365

If you use the onmicrosoft.com domain, then Sender Policy Framework (SPF) is already set up for you and DKIM keys will also be generated automatically for messages you send. 

But if you are using a custom domain for your company, then here’s what you need to follow:

Step 1: Gather a List of Sending Sources Authorized By You

Identify which all IP addresses should be included in the list of authorized senders. Also, consider if the 5321.MailFrom and 5322.From domains match for emails sent from third-party vendors on your behalf. 

Step 2: Generate an SPF Record For Your Custom Domain

You can use an online SPF record generator to create a TXT record. Ensure it begins with v=spf1 and ends with either ‘-all’ or ‘~all,’ indicating a hardfail or softfail, respectively. Follow the best practices and avoid using the ‘ptr’ mechanism, as it’s deprecated due to being slow and unreliable. Use the ‘include’ tag to add sending sources of third-party vendors allowed to send messages on your behalf. 

email security report

Step 3: Generate a DKIM Record For Your Custom Domain

After configuring the SPF record for your custom domain, focus on generating a pair of cryptographically secured DKIM keys to add a digital signature to outgoing emails. 

It’s recommended not to rely on Microsoft 365’s default DKIM configurations because, in that case, Microsoft 365 would work as per the default DKIM configurations, which can cause DMARC to fail. This would happen due to the mismatch between the 5321.MailFrom and the 5322.From addresses in all the emails sent from your domain.

To prevent DMARC failures and potential email spoofing issues, set up DKIM Office 365 for your domain with third-party senders. This not only allows Microsoft 365 to authenticate their emails but also enables other providers like Yahoo and Gmail to verify them as legitimate, fostering trust across mailboxes and preventing spam classification.

Step 4: Create a DMARC Record For You Custom Domain

Visit your DNS hosting provider and find the option to create DMARC record or find the TXT section to edit. Choose the DNS record type as ‘TXT’ and add the host value.

Next, add the mandatory ‘v’ and ‘p’ tags to add the DMARC version and specify the DMARC policy, respectively. The “p=” can be paired with none, quarantine, or reject. As tag-value pairs, they would look like: p=none or p=quarantine or p=reject.

  • The ‘none’ policy instructs recipients’ mailboxes to take no action against unauthorized messages.
  • The ‘quarantine’ policy instructs recipients’ mailboxes to place unauthorized messages in the spam folders.
  • The ‘reject’ policy instructs recipients’ mailboxes to reject unauthorized messages.

Although adding ‘rua’ and ‘ruf’ tags aren’t mandatory but, they are highly recommended. The ‘rua’ and ‘ruf’ tags allow you to specify email addresses where you want to receive DMARC aggregate and forensic reports, respectively. Deploying DMARC without reporting and monitoring is only half efficient. 

Best Practices for Configuring and Managing DMARC For Microsoft Office 365 Custom Users

SPF, DKIM, and DMARC work together to ensure convenience and security coexist. To leverage the optimum benefit of setting up DMARC for Office 365, you must consider the following-

Gradually Advance Your Policies

As a new user, use the ‘none’ policy and monitor your domain’s performance for around 3-4 weeks. Then, move to the ‘quarantine’ policy instead of the ‘reject’ policy to ensure minimal impact of false positives on email marketing ROI and general communication.

While shifting to the strictest policy, that is p=reject, use the pct tag (percentage tag) to apply it to only a prespecified chunk of messages. You can increase the percentage to 100 only when there are very rare instances of false positives

Setup DMARC for Subdomains

DMARC works by stating a policy in a special record in DNS. It follows a hierarchy, meaning a policy for “sample.com” will affect subdomain.sample.com unless there’s a different rule for the subdomain. This is useful as it lets organizations use fewer general DMARC rules for broader coverage. But be careful- if you don’t want subdomains to follow the main domain’s rules, set up specific DMARC records for them.

You can use a wildcard-type DMARC rule with the “sp=reject” value if you don’t want any subdomains to send emails.

Avoid DIYing DMARC

DIYing DMARC, or attempting to implement DMARC on your own, is not recommended due to its complexities and potential pitfalls. DMARC involves configuring DNS records, setting policies, and interpreting reports, which can be challenging for those without specialized knowledge of email authentication protocols. 

Misconfigurations can lead to unintended consequences, such as blocking legitimate emails or leaving the domain vulnerable to phishing attacks. Professional expertise ensures a proper setup, reducing the risk of errors and enhancing the effectiveness of DMARC in preventing email spoofing and phishing. 

email deliverability

Therefore, seeking professional assistance is advisable to successfully navigate the intricacies of DMARC implementation. DuoCircle is always available to help you with anything related to cybersecurity,  email authentication, and email deliverability. Feel free to book a demo.

Topics

DMARCemail securityNews
Brad Slavin
Brad Slavin

General Manager

General Manager at DuoCircle. Product strategy and commercial lead across the email security portfolio.

Secure your email infrastructure

Protect, authenticate, and deliver. Contact our team to find the right solution.