In this post, we’ll briefly explain what a DMARC policy is, how to set up your DMARC email record, what the three types of DMARC policies are and when to implement each one, and how to diagnose and fix any issues associated with it. Basically, your DMARC policy tells email receivers what to do with illegitimate or possibly fraudulent emails—whether to reject, quarantine, or accept them. Overall, there are 3 DMARC policies you can implement:
- Monitor (p=none) allows unqualified emails to go to the recipient’s inbox or other folders.
- Quarantine (p=quarantine) directs unqualified emails to go to the recipient’s junk or spam folder.
- Reject (p=reject) blocks unqualified emails from getting to the recipient.
What Is DMARC?
DMARC is an email authentication protocol to prevent fraudsters from spoofing your domain that works with SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) 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 your DMARC policy options.
How to Set Up Your DMARC Record
If you don’t have a DMARC policy set up, you can generate your DMARC record 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 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." What does this really mean?
What Are the 3 DMARC Policy Options?
There are three DMARC policy options: “p=none”, “p=quarantine”, and “p=reject".
- The “none” policy, sometimes referred to as the “monitor” policy, tells the recipient’s email provider to not take any action if an email fails DMARC.
- The “quarantine” policy moves suspicious emails into a different folder, like your recipient’s spam folder, instead of the inbox.
- The “reject” policy tells the provider to block any email that fails DMARC, so the email never even makes it to your recipient.
You are likely still left wondering which DMARC policy you should implement, or you may be tempted to go straight to “reject” so absolutely no spam emails make it to your recipients. Unfortunately, this policy blocks everything it doesn’t recognize. So if you’ve forgotten to whitelist any of your email-sending services, they could be marked as inauthentic and blocked. Thus, you must be absolutely sure to whitelist every one of your email-sending services before going to “p=reject.” And there are more things to check before using instituting "p=reject" too:
- Your corporate email system (e.g. Office 365, Microsoft Exchange or Google Workspace)
- Email marketing platforms (e.g. Mailchimp)
- Marketing automation platforms (e.g. Marketo)
- Sales/CRM platforms (e.g. Salesforce)
- Customer Support platforms (e.g. Outpost)
- HR and other employee SaaS platforms (e.g. Workday)
- Anything else that sends emails
Instead of jumping straight to “p=reject,” it can be safer to first use “p=none” and then move up to “p=quarantine”. This is because a policy of “none” doesn’t prevent any emails from making it to your recipients, but instead 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 a policy of “quarantine”, 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 of your email-sending services, you can escalate to a policy of “reject”, which blocks unqualified emails from getting to recipients’ inboxes outright but will also block any authentic emails from non-whitelisted email-sending services. Watch our webinar on accelerating your DMARC journey.
Common Problems and Troubleshooting with DMARC Policies
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. We have also debunked some DMARC myths for you. 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 third-party senders, 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 Gmail and Outlook, 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. Watch our video on the 5 keys for success when implementing DMARC.
How to Read DMARC Aggregate Reports
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, including:
- If you choose a policy of "p=none”, you will receive a report of DMARC authentication results to the email address in the policy you implemented. You will also see the source of the email and maybe also the IP address.
- With a “p=quarantine” policy, your DMARC report will include the same data, but emails that fail DMARC authentication will also be quarantined in a spam or similar folder.
- Lastly, with a “p=reject” policy, your DMARC report will also include data about emails that have been prevented from landing in an inbox. Some mailbox providers will also include detailed “failure samples,” also called forensic reports, for emails that do not pass DMARC authentication.
DMARC reports come in an XML format, and are delivered to the email address indicated in the DMARC record (the @ portion of the DMARC example above). These XML records are not easy to interpret manually, so you probably will want to use a DMARC report aggregator and analyzer to clean up the DMARC report and help you read and understand them. These reports will help you diagnose which fraudulent emails haven’t been blocked and which legitimate emails were blocked.
From Here to an Eternity of Enforcement
Creating a DMARC record and setting a DMARC policy takes just a few minutes. But the complications associated with DMARC 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 Agari DMARC Protection automates and simplifies DMARC implementation, management, and reporting workflows—dramatically decreasing time to full DMARC policy enforcement.