19 DMARC myths debunked by the experts

We live in an age of innovation, where automation, artificial intelligence, machine learning, and other technologies enhance our lives in ways our ancestors could only imagine. But unfortunately, we also live in an age of misinformation, meaning there’s a real danger of myths and falsehoods sabotaging our ability to utilize these for the better.

I’ve worked in the DMARC space since the beginning, and in this blog I’ve delved deep to debunk 19 DMARC misconceptions and downright myths, meaning you can get to the bottom of DMARC, and understand why it’s essential for your business.

Myth #1: I’ve done SPF and DKIM, so I don’t need DMARC

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the modern email authentication standard used by all major email servers (Office 365, Google Workspace, and commercial secure email gateways) to authenticate outbound and inbound email. 

None of the gateways mentioned above will only look at SPF and/or DKIM when making delivery decisions because they don’t provide enough information. They will instead look at a number of factors like DMARC, engagement rate, and so on. 

Myth #2: I can’t start using DMARC because I don’t use SPF/DKIM

False! DMARC reports will give you the insight you need into SPF and DKIM to fix authentication issues. Implementing a DMARC record in monitoring mode (p=none) is the first step in any DMARC project and will give visibility into authentication issues with authorized mail streams as well as any shadow IT and/or spoofing activity. 

Myth #3: I use Office 365 or Google Workspace, they say they support DMARC so I already have it

O365 and Google Workspace will check inbound mail for DMARC authentication, but do not provide DMARC visibility and will not help you get your own domains to DMARC enforcement, nor can they authenticate other cloud or on-prem services that send mail on your behalf.

There is a key difference between supporting DMARC and implementing DMARC. Your email gateway provides the former function, and Red Sift’s OnDMARC provides the latter by hosting your SPF, DKIM, DMARC, and BIMI records – a capability that is not provided by O365, Google Workspace, or other DMARC vendors. 

Myth #4: I can’t implement DMARC because of my mail setup

DMARC is interoperable with any email gateway, whether it is on-prem or cloud-based. DMARC is separate from the mail flow itself and is a distinct entry in DNS from MX records. Red Sift has successfully implemented DMARC for customers using Exchange, O365, Google Workspace, and all commercial email gateways (e.g. Proofpoint, Mimecast, Ironport, MessageLabs, Barracuda, Sophos, etc). 

Myth #5: DMARC will stop my email marketing from working

Wrong again, in fact, DMARC will actually give your marketing mail the best chance at delivery once it’s authenticated properly. The challenge is that if you implement DMARC without first identifying and authenticating all marketing mail, it can be inadvertently quarantined or rejected if you move to a DMARC enforcement policy. 

The best way to protect yourself from this potential outcome is to use OnDMARC, which clearly identifies all sources of marketing email and allows you to authenticate them with just one click. 

Myth #6: DMARC is only for the large mail senders

This is absolutely not the case, DMARC is relevant to every type of company, regardless of size! Every company needs to authenticate its legitimate email and block unauthorized spoofing and impersonation of its domains, both of which can be accomplished by implementing DMARC at enforcement. OnDMARC has pricing and packages available to any sized company in any vertical market. 

Myth #7: DMARC is solely a security project

DMARC is actually a cross-functional project, and it’s most efficiently and productively accomplished when there’s a collaborative effort between IT, Security, Compliance, and Marketing (yes, Marketing!). DMARC will indeed stop malicious spoofing and phishing that leverage trusted domains, but it will also identify shadow IT, improve the delivery of legitimate email, and increase brand impressions with BIMI!

Myth #8: DMARC at p=none is significantly better than no DMARC at all 

It’s true that all DMARC projects should start at p=none. This is to get the visibility required to make authentication changes to reach DMARC enforcement. But some users mistakenly believe that their security posture is improved by having a DMARC policy of none. This is simply not the case – if your DMARC policy is ‘none’ you can be spoofed just as if you didn’t have a DMARC record at all (you’ll just have visibility of it when looking at your reports!).

Don’t be lulled into a false sense of complacency that you are ‘good with DMARC’ with a policy of none. The DMARC journey is simply not complete unless you reach DMARC enforcement, which is a policy of at least quarantine (ideally reject) on all your organizational domains and subdomains, at a pct=100.

Myth #9 DMARC is a tedious, manual project that will take months to complete

There are generally 2 main reasons companies abandon their DMARC projects:

  1. Making manual authentication record changes in the DNS can be time-consuming, especially if you have to go through change control each time. Manual SPF flattening and maintenance can also be complex with no guarantee of success.
  2. Being uncertain that all legitimate mail has been identified and authenticated, and won’t be affected with a DMARC policy of quarantine or reject. (Essentially, not being sure they’ve implemented DMARC correctly, and are concerned about legitimate emails they send not reaching the user inbox).

It’s true that without the right tools, DMARC can be a difficult beast. But with a tool like OnDMARC, you’re guaranteed a minimum policy of p=quarantine 100% within 6-8 weeks, and you can be confident that it’s configured correctly.

Myth #10 It’s easy to implement DMARC on my own

DMARC is indeed a public specification that anyone can implement at no cost. Red Sift scans millions of DMARC records every day, where we see that most DIY DMARC projects stay at p=none and fail to reach DMARC enforcement. This means these companies are left unprotected from impersonation, spoofing, and phishing attacks. 

While the current DMARC specification has not changed substantially since it was originally released in 2012 (we are still on version 1), there are improvements and innovations available to companies who want to leverage automation as best possible to authenticate their mail and get to full DMARC enforcement. 

OnDMARC builds on the public DMARC specification and adds intelligence that is not available in a DIY implementation. For example, in OnDMARC our Dynamic DMARC feature enables companies to host their SPF, DKIM, DMARC, and BIMI records in our console after making a one-time change to DNS. From that point forward, all authentication changes are made in OnDMARC, and not in DNS. 

We also source non-public forensics data and layer in insightful threat intelligence from multiple vendors, which makes OnDMARC much more valuable than manually parsing DMARC reports and trying to drive insights from them. 

Myth #11: I will never understand the confusing DMARC XML reports

This won’t be a surprise, but DMARC reports are not designed to be human readable! In fact, you need to parse the DMARC reports in some fashion to make sense of them, and then add reporting, alerting, and interpretation. 

Frankly, in today’s world, it doesn’t make sense to try and implement DMARC on your own – you need a modern solution like OnDMARC to handle the heavy lifting of DMARC implementation and enforcement with a fully automated solution to get your domain to protect quickly, easily, safely, and cost-effectively. 

Myth #12: DMARC forensic data contains personal information

DMARC forensic reports are incredibly useful to troubleshoot authentication issues with legitimate mail streams, as well as to identify malicious sources of email. But any personally identifiable information should be redacted from the report by the originating mailbox provider, and OnDMARC will perform a second redaction to ensure that no private data is ever revealed. 

Myth #13: There is very little difference between DMARC vendors 

DMARC monitoring and visibility is indeed a commodity these days, as there are many vendors that can process DMARC reports on behalf of a domain in a GUI interface. What is not a commodity is a repeatable, safe, easy, and efficient process to get a domain to DMARC enforcement using the latest innovations in hosted email authentication and private data channels, which is a specialty unique to OnDMARC. 

Myth #14: SPF is impossible to manage and keep up to date

It is certainly a challenge to manage and keep an SPF record up to date manually in today’s cloud email service world. But it’s made significantly easier with the right tools at hand. OnDMARC has a few key qualities that make this process much easier to handle:

  • Clear identification of all email sources, so users never have to worry that they’ve missed a legitimate service used for email, and all sources are clearly labeled and recognizable with our unique sender intelligence.  
  • Once senders have been identified, authorized sources can be authenticated with one click using Dynamic SPF. Old services that are no longer used can be removed and the record can be easily managed moving forward. 
  • The SPF 10 lookup limit can also be avoided with Dynamic SPF, as the SPF record is dynamically flattened and always syntactically correct.

Myth #15: Exceeding 10 SPF lookups won’t impact my mail flow

While most modern email gateways use DMARC as the standard for email authentication, there is a long tail of legacy systems that still use SPF as a primary determinant for mail filtering. 

Exceeding the 10 lookup limit means that your record is technically broken when a receiving mailbox performs the SPF check. In addition, if your DMARC record is at enforcement (quarantine or reject) you will be at risk of blocking mail that also doesn’t sign with DKIM. Your legitimate email will have the best chance of being delivered if it authenticates properly with both SPF and DKIM, and where the SPF record does not exceed 10 lookups.

Myth #16: I’ve already ‘turned on’ DMARC

There is a big difference between a DMARC policy of ‘none’ (the least-secure setting that plagues most domains and leaves them unprotected) and a DMARC record at enforcement (a policy of quarantine or reject). The simple act of ‘turning on’ DMARC with a policy of ‘none’ is a needed first step, but doesn’t improve your security posture in any way nor does it protect your domain from being impersonated (there are no awards for just showing up in this manner!). 

To complete your DMARC journey, you must achieve a policy of quarantine or reject at a pct=100. Otherwise, you are still leaving your domain wide open for spoofing and phishing.

Myth #17: I have so many domains that need securing, won’t my DMARC setup be too complex?

Red Sift has customers with thousands of domains that are monitored and protected in OnDMARC. Just because you have an extensive domain portfolio you shouldn’t be deterred from starting a DMARC project. In fact, having more domains that are unprotected means you are a soft target if you don’t utilize DMARC at enforcement, so simply trying to ignore the issue because you have many domains isn’t the answer. *domain discover*

Myth #18 DMARC is too expensive

OnDMARC has a price and package suitable for any sized commercial business, government agency, or nonprofit. In fact, you can buy directly from our website if you have fewer than 50 employees. We use automation to the greatest extent possible which allows our customers to reap the benefits of our efficiencies and economies of scale.

Myth #19: I don’t send emails from my domain so I don’t need DMARC

Non-sending domains can be spoofed just like sending domains, and are especially attractive lures if they leverage well-known brands, websites, people, and companies to send phishing and impersonation emails. The recipients of malicious email from a non-sending domain won’t necessarily realize or understand that the from domain isn’t configured to send email, they will simply think it’s you if the email is compelling enough and looks legitimate, putting your entire brand and reputation at risk.

Why not give OnDMARC a try today?

So there you have it, a rundown of all the DMARC myths and legends around fully debunked. But don’t just take our word for it, why not give OnDMARC a try? Sign up for your free trial today!

PUBLISHED BY

Brian Westnedge

22 Sep. 2021

SHARE ARTICLE:

Categories

Recent Posts

VIEW ALL
News

Winter wins: Red Sift OnDMARC wraps up 2024 as a G2 DMARC…

Francesca Rünger-Field

The season of giving has brought us another reason to celebrate! Red Sift OnDMARC continues its winning streak in G2’s Winter 2025 report, earning Leader status in the DMARC category for another consecutive season. This recognition reflects our strong market presence and the unwavering satisfaction of our customers. Cheers to wrapping up 2024 on…

Read more
AI

Text classification in the age of LLMs

Phong Nguyen

As natural language processing (NLP) advances, text classification remains a foundational task with applications in spam detection, sentiment analysis, topic categorization, and more. Traditionally, this task depended on rule-based systems and classical machine learning algorithms. However, the emergence of deep learning, transformer architectures, and Large Language Models (LLMs) has transformed text classification, allowing for…

Read more
Security

How to drive cybersecurity as a top business priority

Jack Lilley

Everyone has a role to play in protecting the enterprise. Whether you’re shaping strategy or implementing solutions, aligning efforts to mitigate critical risks ensures a stronger, more resilient enterprise. If you missed Red Sift’s recent webinar on “From Data to Buy-In: Driving Cybersecurity as a Top Business Priority” we’ve got you covered. The session…

Read more
DMARC

BreakSPF: How to mitigate the attack

Red Sift

BreakSPF is a newly identified attack framework that exploits misconfigurations in the Sender Policy Framework (SPF) a widely used email authentication protocol. A common misconfiguration involves overly permissive IP ranges, where SPF records allow large blocks of IP addresses to send emails on behalf of a domain. These ranges often include shared infrastructures like…

Read more