Why You Need a Strong DMARC Policy for Email Authentication
A sending domain’s DMARC policy may be the most misunderstood and underused aspect of email authentication. But it’s also a powerful tool for fighting email spoofing that ultimately protects your subscribers and your brand’s reputation.
The problem is, adoption of this specification has been slow, and too many DMARC policies have lenient settings, which means brands aren’t taking advantage of its biggest benefits.
Let’s dive in and demystify DMARC so you can better understand how to get the most out of it.
The basics of DMARC
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. Its primary purpose is to check for the alignment of SPF (Sender Policy Framework) and DKIM (Domainkeys Identified Mail). The DMARC policy tells receiving mail servers whether or not to deliver the messages and how to filter them properly.
To explain 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 domain’s DNS.
Both these protocols help validate messages and prevent forged emails from reaching the inbox. A DMARC policy sits on top of SPF and DKIM, combining the two for stronger authentication.
Imagine DMARC as the bouncer at an exclusive party: SPF is like the list of approved guests and DKIM is a VIP pass. If you aren’t on the list or don’t have the pass, you don’t get into the inbox.
The benefits of DMARC
For mailbox providers … DMARC provides information about how to filter messages that fail authentication. This is your domain’s DMARC policy. When mailbox providers are unclear how to handle unauthenticated messages, they may lean towards delivering them. That’s because recipients are often more upset about not receiving real emails than dealing with spam.
For email recipients … DMARC makes the inbox a safer place because it prevents malicious phishing emails from getting delivered. Specifically, it stops emails with forged information in the “from” field of an email header.
For senders … DMARC also provides valuable reports on the IP addresses that are sending mail on behalf of your domain. This lets you monitor for brand 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. These reports are critical to successfully using DMARC to protect your email reputation. They tell you every source sending emails on your behalf and allow you to separate unauthorized sources from legitimate ones.
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.
What is a DMARC policy?
Your company’s DMARC policy is the most critical part of your DMARC record. Like SPF and DKIM, it is a TXT entry found in the DNS settings of your hosting provider.
When it comes to configuring your DMARC policy in the record, you’ll have one of three options which are reflected in the “p=” value.
- p=none: This tells mailbox providers to take no action on emails that fail authentication. They will most likely be delivered.
- 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.
So why would a sender have a policy of “p=none”? It seems to defeat the primary purpose of implementing DMARC in the first place.
The reason is pretty simple. It’s possible that valid messages will fail DMARC and get rejected if there are issues with DKIM and/or SPF alignment. Of course, every email marketer wants every email they send to get delivered to as many people as possible. For that reason, even some major brands have lax DMARC policies.
Senders with a “p=none” policy still receive DMARC reports, but they won’t be using the specification to stop email forgery and spoofing. Generally, it’s recommended that the “p=none” policy is only used during DMARC setup and testing.
Unfortunately, that’s not the way things have worked out. Too often, senders set their DMARC policy to none and it stays that way. However, a new email standard that’s directly connected to DMARC is encouraging brands to adopt stronger email authentication practices.
Your DMARC policy and BIMI logos
BIMI (Brand Indicators for Message Identification) is an emerging email standard that provides a visual cue that an email has passed authentication. When you implement BIMI correctly, supporting mailbox providers may show a logo at the list and message level.
BIMI helps standardize the way mailbox providers source logos for inbox display. Previously, email clients used proprietary methods. For example, at one point Gmail used Google+ to pull in company logos. BIMI makes it easier to avoid showing the wrong logo because it gives brands control over what mailbox providers use.
BIMI is also convincing brands to reconsider how they use DMARC. That’s because BIMI compliance requires a DMARC policy of either “p=quarantine” or “p=reject”. The idea is, the chance to have an email experience with better branding will convince more organizations to implement stronger DMARC enforcement policies.
Email authentication can be technical and complex. BIMI serves as a reward for brands that put forth the effort to get things in working order. If you need to convince stakeholders in your organization of DMARC’s importance, the opportunity BIMI logos provide may be just the ticket!
But first — you’ll need to create and publish a DMARC record to your DNS.
Download our free BIMI report!
What does a DMARC record look like?
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:
|v=||The version of DMARC used (DMARC1).|
|p=||The DMARC enforcement policy: none, quarantine, or reject.|
|rua=||A list of email addresses where DMARC aggregate reports are sent.|
|pct=||The percentage of messages that are subject to the enforcement policy. Default is pct=100.|
|aspf=||Defines the alignment mode for SPF, which could be strict or relaxed with pass/fail scenarios.|
|adkim=||Defines the alignment mode for DKIM, which could be strict or relaxed with pass/fail scenarios.|
|sp=||Represents different enforcement policies for subdomains.|
|ruf=||Lists email addresses for sending DMARC failure/forensic reports, which are more detailed than aggregate reports.|
|fo=||Indicates the options for creating a DMARC failure/forensic report.|
|rf=||Declares the forensic reporting format for message-specific failure reports.|
|ri=||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=none; 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.
Publishing 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.
Remember, if you start with a policy value of none during initial implementation and testing, you should eventually update it to quarantine or reject. BIMI compliance requires this.
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.
What’s in a DMARC report?
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 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.
Concerned about email deliverability?
Check out our email deliverability guide! Learn the ins and outs of how to stay out of spam folders make sure your campaigns make it into your subscribers’ inboxes.
DMARC and email deliverability
While some email marketers hesitate to enforce strict DMARC policies due to fears it may hurt deliverability, the opposite may be true. Better email authentication leads to improved deliverability.
There are different opinions on DMARC’s direct impact on deliverability. A strong DMARC policy is not a cure-all for email deliverability by any means. However, it’s a strong signal to mailbox providers that you are doing everything in your power to take email authentication seriously.
If you’ve taken the time to authenticate your sending services properly, major mailbox providers will take notice. Fake emails that try to use your domain for malicious purposes will not negatively impact your sender score. DMARC also supports a stronger domain reputation.
Of course, there’s much more to deliverability than email authentication. You still need to make sure that your domain isn’t blocklisted, that your emails aren’t getting caught in spam filters, and that you follow list hygiene best practices to avoid spam traps.
Email on Acid deliverability features help you catch some of these issues before you hit send. Plus, Pathwire’s deliverability solutions provide email validation and valuable insights through Inbox Placement. Together, our solutions can help email marketers gain control of deliverability.
Author: The Email on Acid Team
The Email on Acid content team is made up of digital marketers, content creators, and straight-up email geeks. Connect with us on LinkedIn, follow us on Facebook, and tweet at @EmailonAcid on Twitter for more sweet stuff and great convos on email marketing.