10 Common DMARC Misconceptions, Debunked

minute read

Post Image

When it comes to phishing, many brands make the mistake of relying on their customers or employees to identify and report attacks.

But this strategy is flawed. 97 percent of users around the globe cannot correctly identify a sophisticated phishing message.

Technology that blocks malicious messages before they reach the inbox must be the first line of defense against email fraud. And the DMARC (Domain-based Message Authentication Reporting and Conformance) standard does just that.

Building your DMARC record is pretty straightforward. But there are many common misconceptions about the DMARC implementation process which can throw a wrench in your efforts to identify and mitigate phishing attacks.

Since Return Path’s Managed Service team hears these DMARC misconceptions on a daily basis from the field, we thought it might be helpful to list—and debunk—the top ten here

1. DMARC reporting mechanisms contain sufficient data to deploy a DMARC “reject” policy successfully.
You actually need additional data to give the RUA and RUF context, or you end up relying on guesswork, which can be nerve-wracking.

2. It’s a good idea to list all the possible header fields in your DKIM signature because it’s “more secure.
Your goal with DKIM is to cryptographically validate that only you could have sent the message in question. Therefore, pick only a few fields to put in your “h:array,” none of which will be changed by forwarding (which would cause your signature to break).

3. You should add “include” statements to your SPF record instead of entering either individual IPs, or a CIDR (Classless Inter-Domain Routing) range.
Your SPF record needs to be a lean, mean speed machine—ideally, a clean, flat list of IPs. Keep include statements to an absolute minimum. Doing so adds speed and removes a potential point of failure

4. Add an 11th include statement to your SPF record.
The SPF protocol only allows for 10 include statements. Adding an 11th include statement breaks the record.

5. Emailing your DKIM private key to someone isn’t a big deal.
The second that your private key is anywhere other than the MTA which uses it, it’s no longer a private key and has to be replaced.

6. You should send all email from the organizational/top-level domain.
There are many reasons to note here why sending email from your top-level domain is a bad idea. Some are based on security and vendor management—your holiday booking system is happiest sending from [email protected] Others on sound deliverability grounds—you never want to mix a marketing and transactional email, for example. See this resource from Google for more detail.

7. A DMARC record in the organizational/top-level domain is all you need.
Implementing DMARC on your top-level domain is a good start, but it’s not enough to give you the control and the reporting fidelity that you need. All domains owned by your company (both sending and non-sending) should be protected with a DMARC policy.

8. Because you send the majority of your email from a certain subdomain, the bad guys will do that as well.
This is a common assumption, and it’s false—you need to lock down the entire domain (the main organizational domain and the subdomains). The highest value target is the organizational domain, not the subdomain you send the most volume from.

9. Previous infrastructure decisions were made rationally.
Don’t drive yourself mad trying to replicate the thought process of those who built your email infrastructure. Instead, use the new DMARC deployment as an opportunity to re-design and optimize your (and your third party) infrastructure and architecture.

10. Vendors in 2016 can all sign DKIM.
“Should” isn’t the same as “can.” The vendor landscape is highly varied. You need an expert who has detailed knowledge of how to overcome the various challenges you will face getting all of your infrastructure to authenticate correctly with DKIM, in particular when it comes to third party vendors.

Want to run your DMARC implementation process by an email expert at Return Path? Please reach out to us. We’d love to answer any questions you may have.



BriteVerify email verification ensures that an email address actually exists in real-time


The #1 global data quality tool used by thousands of Salesforce admins


Insights and deliverability guidance from the only all-in-one email marketing solution

GridBuddy Cloud

Transform how you interact with your data through the versatility of grids.

Return Path

World-class deliverability applications to optimize email marketing programs

Trust Assessments

A revolutionary new solution for assessing Salesforce data quality


Validity for Email

Increase inbox placement and maximize subscriber reach with clean and actionable data

Validity for Data Management

Simplify data management with solutions that improve data quality and increase CRM adoption

Validity for Sales Productivity

Give your sales team back hours per day with tools designed to increase productivity and mitigate pipeline risks in real-time

DemandTools Elements Features

DemandTools Features

GridBuddy Connect Features

Everest Features

Everest Features