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.
Images sourced from admindroid.com
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
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.
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.