Understanding and using DMARC email message validation in Office 365

DMARC (Domain-based Message Authentication, Reporting and Conformance) is one of those acronyms that often shows up when diagnosing mail delivery issues in Microsoft Office 365. If you already use SPF and DKIM, DMARC adds a policy layer on top to help mail receivers decide what to do with suspicious messages.

DMARC records are configured in your company's DNS. A typical DMARC record is a "TXT" record and looks similar to this:

_dmarc.myexample.com  IN TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@myexample.com"

Here's a brief description of what the fields mean:

• v=DMARC1: the version
• p=quarantine: tells receivers what to do with failing mail (options are none, quarantine and reject)
• rua=mailto:...: where aggregate reports should be sent

In Office 365, DMARC plays together with SPF and DKIM like this:

• SPF: checks whether the server sending the email is allowed
• DKIM: verifies that the message was not modified
• DMARC: tells the recipient what to do if SPF/DKIM fail

If you manage a domain in Microsoft 365, enabling DMARC is simply a matter of adding the DNS TXT record. The Microsoft 365 admin center provides a useful security report that shows whether messages pass or fail SPF/DKIM/DMARC alignment, which makes it easier to adjust your configuration.

In practice, I recommend starting with p=none so you can gather reports and see if any legitimate mail fails validation. After a week or two, you can move to quarantine and eventually reject.

Even if your organization is small, DMARC is worth enabling. It improves your domain's reputation and reduces the chance of spoofing attacks using your name.