Brand and Editorial Lead
DMARC is an email security standard that allows domain owners to monitor who’s sending email using their domain and instructs email receivers (like Gmail) to approve, quarantine, or reject emails that aren’t sent from an authenticated source.
DMARC (which stands for Domain-based Message Authentication, Reporting & Conformance) is designed to prevent spammers from impersonating a domain, known as spoofing*, and tricking message recipients into taking actions that will benefit the spammers. On top of helping email senders and receivers determine if a message is legitimate, DMARC is used to signal to inbox providers (e.g. AOL or Gmail) what to do if they get an email that looks legit but doesn’t conform with email authentication standards.
* A typical example is PayPal spoofing, when phishing scammers send emails pretending they are from PayPal.com in an effort to obtain someone’s account information. DMARC is there to make sure these fraudulent emails get blocked before recipients ever see them in their inboxes.
We wrote everything you need to know about DMARC below—but before you get started, how about a 5-minute video about DMARC featuring a raft of very authentication-focused ducklings?
Do I need DMARC? #
If you care about your email deliverability, then yes: you need DMARC.
Spoofing and phishing attacks can damage your reputation with both customers and email receivers; plus, when recipients mark spoofed emails as spam, this hurts your domain reputation and leads to legitimate email no longer reaching your customers.
How does DMARC work? #
DMARC is built on two email authentication technologies:
- DKIM (DomainKeys Identified Mail) which verifies that a message wasn’t altered in transit
- SPF (Sender Policy Framework) which verifies that the message came from an approved server
DMARC essentially tells an inbox provider that as long as one of these two authentications passes, it should consider the message as legitimate. If they both fail or are not present, the provider should consider the message as suspicious and act according to that domain’s DMARC policy.
3 DMARC policies: none, quarantine, reject
#
A DMARC policy tells an email receiver (e.g. AOL or Gmail) what to do if a message fails the DMARC check. There are 3 DMARC policies: approve, quarantine, and reject:
1. Approve or monitor policy (p=none): the receiver is to behave normally and deliver the email to the inbox or other relevant folder even if the email fails DMARC
2. Quarantine policy (p=quarantine): the receiver is to treat the message as suspicious and deliver it to the recipient’s spam folder
3. Reject policy (p=reject): the receiver is to drop the message and not deliver it to the user at all
How to set up DMARC #
Assuming you already have SPF and DKIM in place, setting up DMARC starts with inserting a DNS record on your domain, which could look something like this:
v=DMARC1\; p=none\; sp=reject\; pct=100\; rua=mailto:dmarc-reports@domain.com\;
Where:
- v= indicates the the DMARC version
- p= specifies the domain policy (none, quarantine, reject)
- sp= specifies the subdomain policy (none, quarantine, reject)
- pct= dictates the percentage of messages that the policy applies to
- rua= is the address that aggregate reports should be sent to
This may look simple on the surface, but it’s actually a multi-step process that takes time, attention, and its own separate DMARC setup and implementation guide that breaks the process down into several steps.
That’s because there are some risks associated with implementing DMARC wrong. For example, if you set a DMARC policy without knowing all of your email sources (e.g. mailboxes, email marketing, CRM, transactional email, server alerts, etc.), you could potentially be telling email receivers to reject legitimate email—and you’d never know your messages didn’t make it to your recipients’ inboxes.
How to read a DMARC report (...or not) #
Once you’ve set up a DMARC policy for your domains, inbox providers like Google and Yahoo will send daily reports in XML format that list the emails they received from your domains and whether or not they align with your DMARC policy.
The problem with these reports is that XML logs are both difficult and time-consuming to read; they’re also not particularly helpful, because they don’t present aggregated stats. For example, here is what a typical DMARC report looks like:
Luckily for us all, a bunch of dedicated DMARC tools take this data and make it easy for a human to read 😅 For example, here is our own DMARC Digests in action: same data as the table before, but much easier to parse and take action from.
A solitary but frequently asked question about DMARC
#
...because sometimes it’s easy to get the acronyms mixed up:
What is the difference between DMARC and DKIM? #
DMARC is an acronym for Domain-based Message Authentication, Reporting & Conformance); it’s an email standard designed to prevent spammers from using a domain to send email without the domain owner’s permission.
DKIM (DomainKeys Identified Mail) is one of the two email authentication methods used by DMARC to verify the legitimacy of an email.
DKIM is not required by DMARC, but setting it up will help minimize false negatives in DMARC.
