Is Your DMARC Policy Strong Enough to Provide Protection?
They say honesty is the best policy. But when it comes to Domain-based Message Authentication Reporting & Conformance (DMARC), that’s not exactly an option.
Even though there’s no right/wrong or honest/dishonest way to set up a DMARC policy, some policies are more effective at helping mailbox providers stop brand spoofing and filter potentially malicious messages. That’s because some policies are stronger than others.
**Spoiler alert** Too many organizations are using a weak DMARC policy and need to change it.
As an email sender, the power of DMARC is in your hands. And the strength of your DMARC policy is totally up to you. To help you choose the right DMARC policy, let’s start with some basics.
What is DMARC?
DMARC is a technical specification used in email authentication. Its purpose is to protect sending domains from unauthorized use. By that we specifically mean it helps prevent phishing, business email compromises (BECs), and other email scams.
DMARC does this by checking for alignment of two important email authentication protocols: Sender Policy Framework (SPF) and Domain-keys Identified Mail (DKIM). Essentially, DMARC helps email senders leverage the power of both SPF and DKIM.
To explain these email authentication protocols briefly:
- SPF is a list of hostnames and IP addresses published on your DNS that are approved to send mail for your domain.
- DKIM involves an encrypted digital signature or private key that matches a public key on a sending domain’s DNS.
Both SPF record and DKIM keys are DNS txt records. A DMARC record also gets published on a sending domain’s DNS server, and mailbox providers will check that record for the DMARC policy before deciding what to do with email messages that appear to come from that domain. Deliver it to the inbox? Send it to the junk folder? Or block the message?
The benefits of DMARC
For mailbox providers… DMARC provides information about how to filter messages that fail authentication. This is what your domain’s DMARC policy does. When mailbox providers are unclear about how to handle unauthenticated messages, they may lean toward delivering them. That’s because recipients will be more upset about not receiving real emails than dealing with spam. This is how potentially dangerous emails sneak through.
All major mailbox providers support DMARC. That includes Gmail, Outlook, Yahoo, Apple Mail, and AOL. In fact, implementing DMARC is a signal to these providers that you’re a responsible and reputable sender they can trust.
For email recipients… DMARC makes the inbox a safer place because it prevents malicious phishing attempts and brand spoofing emails from getting delivered. Specifically, it stops emails with forged information in the “from” field of an email header.
For email senders … DMARC helps protect brand reputation and also provides valuable reports on the IP addresses that are sending mail on behalf of your domain. This lets you monitor for email spoofing and find out if legitimate emails are encountering authentication issues that impact deliverability.
You can set up DMARC so that you get daily reports from servers receiving any emails claiming to be from you.
The BIMI bonus
Another potential benefit of a strong DMARC policy is eligibility for having a certified logo show up on your marketing and transactional emails. This is made possible through a specification known as Brand Indicators for Message Idenfitication (BIMI).
BIMI adds more branding to the inbox experience and there’s evidence it could help increase engagement metrics such as open rates. It could also serve as a sign that the email can be trusted.
That’s because any email that displays a BIMI logo has also been authenticated using DMARC. However, mailbox providers won’t show a BIMI logo unless you’re using a strong enough DMARC policy. So, what’s that all about?
DMARC policies explained
When implementing DMARC, email senders have three policy options:
p=none: This tells mailbox providers to take no specific action on emails that fail authentication. They will most likely be delivered unless it is very obviously spam. A p=none DMARC policy leaves the decision up to mailbox providers.
p=quarantine: This policy informs mailbox providers to send emails that fail authentication to spam or junk folders. These messages may also be blocked.
p=reject: This is the strongest DMARC policy value. It ensures all malicious email is stopped dead in its tracks. If a message fails DMARC when set to “reject” will not be delivered at all.
How DMARC policies work
Here’s a flowchart that visualizes how DMARC works:
As you can see, when DMARC is implemented. the receiving mail server checks for both SPF and DKIM. If the message fails either of these authentication protocols, the receiving server then checks for and applies the DMARC policy published in the DNS txt record. Plus, it also provides information on email traffic, which is delivered to the domain owner in DMARC reports.
If there is no DMARC record, or if the policy is set to p=none, the mailbox provider will apply its own filters to the message.
Why your p=none DMARC policy must go
According to DMARC.org, adoption of this email specification has seen some healthy growth in recent years. In fact, it was up 84% at the end of 2021. But that’s not the full story…
The site also states that nearly 66% of those DNS records have a DMARC policy that’s set to p=none. And that’s a problem.
A DMARC policy of p=none means you are essentially doing nothing to help mailbox providers stop phishing attacks and protect recipients (aka your subscribers). A p=none policy is weak because you are passing all the responsibility off to mailbox providers.
Using p=quarantine or p=reject reflects the true intent of DMARC. The p=none policy should really only be used when you are setting up and testing whether DMARC is working properly. But, as the numbers show, many senders keep the p=none policy in place.
The email industry actually introduced BIMI to motivate senders to enforce strong DMARC policies. That’s why you must use either p=reject or p=quarantine to qualify for a BIMI logo. But that shouldn’t be your only reason for enforcing DMARC. Without enforcing quarantine or reject, you continue to leave subscribers vulnerable to phishing and your brand vulnerable to a damaged reputation.
So, if you’re ready to implement DMARC or want to update your policy you’ll need to make sure you’ve got a strong enough policy listed in your DMARC record.
What does a DMARC record look like?
There’s more to a DMARC record than just the policy. Let’s take a closer look at the txt record you’ll need to publish on your DNS server.
When you set up your DMARC policy and create a DNS record, there are up to 11 tags you may use. Only two of those are required: the v tag (version) and the p tag (policy). But you also want to use the “rua=” tag, because it defines the email addresses where receiving mail servers should send DMARC reports.
Here’s a quick explanation of all DMARC tags:
|The version of DMARC used (DMARC1).
|The DMARC enforcement policy: none, quarantine, or reject.
|A list of email addresses where DMARC aggregate reports are sent.
|The percentage of messages that are subject to the enforcement policy. Default is pct=100.
|Defines the alignment mode for SPF, which could be strict or relaxed with pass/fail scenarios.
|Defines the alignment mode for DKIM, which could be strict or relaxed with pass/fail scenarios.
|Represents different enforcement policies for subdomains.
|Lists email addresses for sending DMARC failure/forensic reports, which are more detailed than aggregate reports.
|Indicates the options for creating a DMARC failure/forensic report.
|Declares the forensic reporting format for message-specific failure reports.
|Sets the interval for sending DMARC reports, which is defined in seconds but is usually 24 hours or more.
A DMARC record with only the basics will look something like this:
v=DMARC1; p=reject; rua=mailto:firstname.lastname@example.org
The v and p tags must appear first. All other tags can appear in any order.
A somewhat more complex DMARC record might look like this:
v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:email@example.com;
pct=100; aspf=s; adkim=s
If you’re pursuing BIMI implementation, it’s important to know about the values required for a couple of optional tags. As with your main DMARC policy, subdomain policies cannot be set to none (sp=none). Furthermore, the percentage tag must have a value of 100 (pct=100), which means all emails are subject to your DMARC policy.
How to publish a DMARC record
First, set up SPF and DKIM, if you haven’t done so already. Those should be running for at least 48 hours before you set up DMARC.
Then, go to your DNS hosting provider, and follow these steps:
- Add your DMARC record to your DNS by creating a new record.
- Use the TXT record type — this will likely be in a dropdown menu.
- Enter _DMARC in the Name or Host field.
- Enter the required tag value pairs (v= and p=) as well as any optional tag values needed.
- Save, or create, the DMARC record.
- Validate that the DMARC record has been set up correctly by running a DMARC Record Check.
If you start with a policy value of p=none during initial implementation and testing, you should eventually update it to p=quarantine or p=reject.
Setting up DMARC seems pretty simple on the surface, but it can get very technical. So, you may need to ask your IT department for help. There are also vendors that specialize in DMARC implementation.
For example, Red Sift is a cybersecurity company that offers OnDMARC, which is a service that helps out with many factors of email authentication, including BIMI as well as DKIM and SPF configuration. Other vendors who can help with DMARC include dmarcian and PowerDMARC.
What’s in a DMARC report?
The aggregate DMARC reports show up in XML format. These can be tough to analyze. You may need a tool that can interpret these reports and present them in a readable way. Here’s a list of some tools that read DMARC reports.
The aggregate DMARC report will arrive daily (unless otherwise specified) in the email addresses listed in your rua tag. You may want to create a special email address just for this purpose, so it doesn’t clutter up your inbox.
DMARC reports will show:
- All domains sending emails using your domain in their From field
- The sending IP for each of these
- The number of emails being sent each day
- Results from SPF and DKIM authentication
- DMARC results
- Emails that failed authentication and were quarantined (if you used p=quarantine)
- Emails that never got delivered (if you used p=reject)
- Forensic/failure reports (if you use the ruf tag)
The information in DMARC reports gives you incredible insights into how messages are moving through the email ecosystem as well as how often bad actors are trying to forge emails and impersonate your brand.
What’s the difference between ruf and rua reports?
There are two different types of DMARC reports: aggregate (rua) and forensic (ruf).
|Aggregate DMARC Reports
|Forensic DMARC Reports
|Combines data on groups of emails.
|Sends data for individual messages.
|Delivered daily by default
|Delivered in real-time by default
|Contains no personally identifiable information (PII)
|May contain personally identifiable information (PII)
|Reports are in XML format
|Reports are in plain text
Only certain mailbox providers will send forensic reports, but since they are for every email you send, it can become a lot to reiew. Get more information on rua vs ruf DMARC reports from dmarcian.
DMARC reports can be very useful for security and compliance concerns. You only need a DMARC policy of p=none to receive reports. However, reporting shouldn’t be your only reason for using this email specification. DMARC is meant to improve email security and make the inbox a safe place for your subscribers.
Stronger authentication = better deliverability
We’ve already explained how DMARC helps mailbox providers filter fake emails, protects your subscribers from phishing, and helps you avoid brand reputation damage. But there’s one more potential benefit of a strong DMARC policy… deliverability.
Some senders hesitate to enforce strict DMARC policies due to fears it may hurt email deliverability. While an incorrectly configured DMARC record or other authentication issues may cause deliverability problems, the truth is that email authentication can lead to better deliverability.
The use of email authentication is a strong signal to mailbox providers that you are a responsible and reliable sender When you’ve got a good email reputation, you are less likely to get blocklisted, less likely to get filtered into the junk folder, and more likely to land in the inbox.
Enforcing a strong DMARC policy is a clear signal that you are working to do the right thing. It protects your reputation as an email sender because it makes it easier for mailbox providers to identify your messages as legitimate and messages from spammers and scammers as malicious.
Of course, email deliverability can be just as complicated as email authentication, and both are directly linked to your success as an email marketer. That’s why we’re happy to offer Mailgun Optimize – a complete email deliverability suite.
Use Mailgun Optimize for a variety of purposes, including:
- List cleaning as well as real-time email verifications
- Predicting where emails will land with Inbox Placement reports
- Blocklist and spam trap monitoring
- Detailed email deliverability reports
When you combine Mailgun Optimize’s deliverability tools with Email on Acid’s testing and optimization tools, you’ve got yourself quite the pair. Use these platforms together to perfect every campaign and constantly improve email deliverability.