Configuring DMARC for validating the FROM: address domain for senders in Microsoft 365
DMARC validates emails sent from your Microsoft 365 domain to prevent spoofed senders from attempting business email compromise (BEC) attacks, ransomware, and other phishing instances. For the DMARC validation process, the domains in the MAIL FROM and FROM addresses are verified for alignment.
DMARC in Microsoft 365 for different domain types
For MOERA domain users
SPF and DKIM are already configured for Microsoft Online Email Routing Address or MOERA domain (for example, testing.onmicrosoft.com), but you have to generate and publish a DMARC record for it in the Microsoft 365 admin center.
For custom domain users
You need to set up SPF and DKIM for all the domains and subdomains you own, including the parked ones. Once done, you need to configure DMARC for them, as described later in this article.
Here are a few considerations you need to bear in mind-
Subdomains
For email services you don’t control directly, it’s better to use a subdomain so that you don’t have to deal with related issues. This will also protect your brand reputation. Unlike SPF and DKIM, a DMARC TXT record automatically covers all subdomains that don’t have their own DMARC records. You can create a specific DMARC record for a subdomain to override this inheritance. However, each subdomain still needs its own SPF and DKIM records for DMARC to function correctly.
If your domain is not registered
For unused or parked domains, set the DMARC TXT records to indicate that no email should come from them. This applies to the *.onmicrosoft.com domain if not used for email.
For online email service users
If you use an email service that modifies messages before delivery to Microsoft 365, mark the service as a trusted ARC sealer to prevent the modified messages from failing DMARC checks.
Adding DMARC records for .onmicrosoft.com domains in Microsoft 365
- Go to the Microsoft 365 admin center.
- Select Show All > Settings > Domains, or go directly to the Domains page using this link.
- On the Domains page, select the *.onmicrosoft.com domain by clicking anywhere in the row except the checkbox.
- In the domain details page, go to the DNS records tab.
- Click Add record on the DNS records tab.
- In the Add a custom DNS record flyout, configure the following settings:
- Type: Verify that TXT (Text) is selected
- TXT Name: Enter _dmarc
- TXT Value: Enter v=DMARC1; p=reject
- TTL: Verify that 1 hour or 3600 seconds is selected.
- When you’re finished on the Add a custom DNS record flyout, select Save.
Configuring DMARC for active custom domains in Microsoft 365
It’s best for your domain health and reputation if you gradually proceed toward the best protection against spoofing and phishing. Don’t set your DMARC record to p=reject right from the start; begin with p=none and monitor the results for testing and verifying to prevent recipients’ mailboxes from rejecting genuine emails because of unintentional DMARC failures.
We suggest you also opt to receive aggregate and forensic reports to get the number and sources of emails that pass and fail DMARC checks. These reports give you insights into your email traffic, further helping you troubleshoot issues.
Once you gain confidence and the number of false positives goes down, move to p=quarantine and continue monitoring the aggregate and forensic reports. We suggest using the ‘pct=’ tag, also called the percentage tag. The `pct` tag in a DMARC record specifies the percentage of email messages to which the DMARC policy is applied. For example, `pct=50` means the policy is applied to 50% of emails.
You can move in the following increment to test the policy’s impact on a portion of email traffic before applying it to all messages.
- pct=10
- pct=25
- pct=50
- pct=75
- pct=100
The end goal is to set the DMARC policy to p=reject and continue reviewing the reports. You can also use the ‘pct=’ tag here.
DMARC for inbound emails in Microsoft 365
DMARC authentication checks for emails coming in Microsoft 365 are affected by the following features in Exchange Online Protection or EOP:
Image sourced from office365concepts.com
- Whether spoof intelligence is turned on or off in the anti-phishing policy. Turning it off removes implicit spoofing protection from composite authentication checks.
- Whether the “Honor DMARC record policy when the message is detected as spoof” setting is turned on or off in the anti-phishing policy. Actions are based on the DMARC policy of the source domain (p=quarantine or p=reject in the DMARC TXT record).
Also, note that Microsoft 365 doesn’t send DMARC forensic reports even if you add a valid ‘ruf=mailto:’ address to your DMARC record. On the bright side, it sends DMARC aggregate reports to all domains with a valid ‘rua=mailto:’ address in their DMARC records. However, this requires the MX record to point directly to Microsoft 365. This limitation applies to hybrid or standalone EOP scenarios where mail is first delivered to the on-premises environment and then routed to Microsoft 365 using a connector.
We at DMARCReport help with everything related to receiving and monitoring DMARC aggregate and forensic reports. So, if you feel stuck or confused at any point, contact us; we’ll handle the reports on your behalf.
