Your DMARC policy tells email receivers what to do with unapproved (possibly fraudulent) emails, like whether to reject, quarantine, or accept them.
There are 3 DMARC policies:
In this post, we’ll briefly explain what DMARC is, how to set up your DMARC record, what the three types of DMARC policies are and what they do, which one you should use and when to use it, and how to diagnose and fix issues with DMARC.
Domain-Based Message Authentication, Reporting & Conformance (DMARC) is an email authentication protocol to prevent fraudsters from spoofing your domain. DMARC works with Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) to verify the authenticity of the email.
Specifically, DMARC helps email receiver systems recognize when an email isn’t coming from a specific organization’s approved domains, and tells receiver systems what to do with these unauthorized emails. These policies are published in a domain’s DNS as a TXT record.
For more information, here’s a great guide to understanding what is DMARC.
If you don’t have a DMARC policy set up, you can generate your DMARC record here or follow our step-by-step DMARC setup guide. Note that you’ll first need SPF and/or DKIM deployed a minimum of 48 hours before you can set up DMARC.
If you already have a DMARC record and want to update your policy, all you need to do is edit it in your DNS. You can look up your DMARC record here to see what policy is currently in place.
When you’re done, the DMARC record in your DNS should look something like this:
V=DMARC1; p=reject; rua=mailto:dmarc-feedback@
As you can see in this example, we have the policy set to “p=reject.” This means the DMARC policy is set to “reject.” What does that mean? We’ll explain “reject” and the other two DMARC policies.
There are three DMARC policies: “none” (monitor-only), “quarantine,” and “reject.”
Why Use One DMARC Policy Over Another?
You might be wondering which DMARC policy you should use. Or, you might be tempted to go straight to “reject” so absolutely no spam emails make it to your recipients.
Unfortunately, the “reject” policy blocks everything it doesn’t recognize. If you’ve forgotten to whitelist any of your email sending services, they could be marked as inauthentic and blocked. So be absolutely sure to whitelist every one of your email sending services before using “reject.”
Here are just a few things to check before using “reject:”
Instead of jumping straight to “reject,” it can be safer to first use “none” and then “quarantine” before escalating to “reject.”
First, the “none” policy doesn’t prevent any emails from making it to your recipients, but it begins monitoring emails sent from your domain and sending you reports. This will help you figure out which sources are authentic, and which might not be, without affecting deliverability.
Then you can escalate to the “quarantine” policy which sends unqualified emails to recipients’ spam or junk folders. This option means suspicious emails land in spam, but if any authentic emails are blocked, at least your recipients still get them (albeit in their spam folders).
Once you’re confident you’ve whitelisted all your email sending services, you can escalate to the “reject” policy which outright blocks unqualified emails from getting to recipients’ inboxes, but will also block any authentic emails from non-whitelisted email sending services.
If you have any legitimate internal emails that are being marked as unqualified by DMARC, there are some essential steps you can take to reduce the volume of false positives.
First, it’s critically important that you set up DMARC records to work in conjunction with both SPF and DKIM. DMARC resolves most issues by using both of these protocols.
You’ll also want to authorize services sending legitimate emails to employees on your behalf—including the third-party senders mentioned above, as well as services facilitating calendar invites, for example.
Conversely, if fraudulent emails spoofing your domains are still making it through to employee inboxes, the same essentials hold true. Failure to implement DMARC to work with both SPF and DKIM is likely to increase your false negative rate.
However, if you set up DMARC to leverage both SPF and DKIM, and you’re still seeing a high false negative rate, use our DMARC record generator to make sure the DMARC record has been set up correctly. If so, check the established enforcement level. If a DMARC policy is sent to p=none, for example, spoofed emails will be delivered without scrutiny.
For this reason, it’s also advisable to refrain from using an “sp” tag in your DMARC record, because it applies the same policy from a top-level domain to all those below it. If the top-level domain is set to p=none, p=quarantine, or p=reject, the same will be true of all domains underneath it—increasing the likelihood of false positives and false negatives depending on the settings. It’s best to implement DMARC across each individual domain separately.
Be aware that while DMARC is supported by major email providers like Google Gmail and Microsoft Office 365, not all receiving servers perform a DMARC check. In some cases, the receiving server may override a DMARC check and instead implement their local policy.
Once you’ve published your DMARC record, receiving ISPs will send you DMARC reports. A DMARC report contains information about the authentication status of emails sent on behalf of (or exploiting) a domain.
These reports are sent daily and provide visibility on domains used to send these emails, the sending IP, the amount of emails sent on a specific date, the SPF/DKIM authentication result, the DMARC result and more.
You will receive DMARC reports regardless of what policy you choose.
DMARC reports come in an XML format, and are delivered to the email address indicated in the DMARC record (the
Creating a DMARC record and setting a DMARC policy takes just a few minutes. But the complications mentioned here, as well as many others, grow exponentially worse when applied to an enterprise with hundreds or thousands of domains.
Large enterprises are advised to source solutions that can optimize and streamline this process across their entire email ecosystem. Using our own solution as an example, Agari Brand Protection™ automates and simplifies DMARC implementation, management, and reporting workflows—dramatically decreasing time to full DMARC policy enforcement.
Want to learn more? Here’s a full guide to getting started with DMARC. And for more information on email security, sign up for our email newsletter.