Domain-based Message Authentication, Reporting & Conformance
With a DMARC policy in place on your domains, email providers (like Gmail and Outlook) will start investigating emails coming from your domains. They'll report back to you when fraudulent email messages are received and even block those email messages from ever reaching their recipients.
For example, you can say "I send emails from MailChimp and Convertkit. If you, dear mailserver, receive an email claiming to be from emailsherpa.com, and it is not from one of those senders, please put it into the spam folder immediately."
Why is DMARC needed?
A big problem inherent in email is the fact that a recipient cannot know if an email was actually sent from whoever claims to have sent it. All emails has a header telling the recipient who sent the email, but they can claim to be anyone.
It's a bit like you calling people on the phone, telling them you're the pope . The receiver only has your phone number and your guarantee that you are who you claim. It is up to them to evaluate if you're telling the truth. Luckily most people will catch your ruse, but email servers aren't that clever.
Control and visibility
DMARC provides a way for senders to specify how recipient servers should handle non-authenticated emails. In addition to this, it provides a reporting framework making it possible to get insights into what email servers actually recieve.
It builds on top of SPF and DKIM to prevent spoofing from their domains.
A big benefit of DMARC is the ability to roll it out gradually. You can start out just in monitor mode, where you're getting nothing but visibility into what emails are being sent from your domain.
When you're confident your legitimate messages are passing the authentication checks, you can request that failing messages get quarantined.
And finally, when you've been quarantining mails for a while without problems, you can start request them being rejected entirely.
What does a DMARC record look like
To opt in to DMARC for your domain, you have to add a DMARC DNS record to your domain. It's added as a TXT record on a subdomain called
So for example if your domain is emailsherpa.net, you'd add a TXT record for
_dmarc.emailsherpa.net to enable DMARC. The value for a simple DMARC record could look like this:
The above DMARC record consists of 3 parts:
v=DMARC1: This identifies the record as being DMARC version 1 (the only version that currently exists).
p=reject: Indicates the policy to use when an email doesn't pass DMARC verifications. In this case the policy is "reject", the strictest policy.
rua=mailto:firstname.lastname@example.org: Recipient email servers will collect reports of DMARC violations and deliver them to this email address.
- None: This is a passive monitor mode. It allows you to receive reports, but the recipient email servers take no extra action.
- Quarantine: When an email message is received that doesn't match the allowed sender for the domain, the message is quarantined. In most cases this means that it goes directly to the recipients spam folder.
- Reject: This is the strictest policy. Instead of placing unauthorized messages into the spam folder like "Quarantine" above, it lets the server outright reject and discard the message.
The reports you receive as part of the DMARC compliance process come in two different versions:
- Aggregate reports: Aggregate reports provide a high level overview of all emails received for a single email provider in a given time period, usually a day.
- Forensic reports: A forensic report contains details about a single email received by an email provider if it is determined that the email has failed the DMARC checks.
Common for both report types is the fact, that they are sent via email, are in XML format and very hard to read for normal human beings. Typically you'd want a service to help you parse and understand the reports.