Google and Yahoo’s new sender requirement announcements in October 2023 for bulk senders had a seismic effect on the email community, with senders and their ESPs scrambling to make sure they would be able to comply.
The DMARC requirement has led to three common errors related to DMARC. Let’s take a look at the actual requirements, and then we’ll dive into the three DMARC mistakes that you should avoid.
The DMARC Requirement
Google’s email sender guidelines for bulk senders contain the following language:
- Set up DMARC email authentication for your sending domain. Your DMARC enforcement policy can be set to none.
Yahoo’s sender best practices says:
- Publish a valid DMARC policy with at least p=none (DMARC must pass)
While you might assume your sending domain must have a DMARC record in DNS, that’s not exactly true, because that’s not how DMARC works. We believe that it is a lack of understanding of how DMARC works and/or a misinterpretation of these two statements that has led to some DMARC issues.
DMARC and Policy Inheritance
Before we dive into these mistakes, you first need to understand how DMARC policies and inheritance work. Domain-based Message Authentication, Reporting, and Conformance (DMARC) relies on the concept of the organizational domain, which is typically the domain that an entity registers when it wants to establish a presence on the public Internet. For example, Valimail’s organizational domain is valimail.com.
The DMARC policy in a record published for the organizational domain (e.g., _dmarc.valimail.com) is automatically inherited by any subdomain of that organizational domain unless the subdomain has explicitly published its own record. Continuing with our example, the domain mktg.valimail.com would inherit the DMARC policy published at _dmarc.valimail.com unless there is a DMARC record published at _dmarc.mktg.valimail.com.
1. Using a DMARC Record When You Only Need a Policy
The fact that DMARC policies can be inherited by subdomains means that an organization sending with a subdomain will meet the DMARC requirements so long as there is already a policy in place for the organizational domain. This doesn’t mean that subdomains never need their own DMARC policy records in DNS.
It’s not uncommon for a domain owner to want a subdomain to deploy a different policy value than the organizational domain (e.g., p=reject vs. p=none), and in that case, the subdomain must publish its own policy record. However, for the general case of just having a policy in place to meet the Google and Yahoo requirements, a subdomain can inherit a policy from the organizational domain.
Use our free domain checker to determine if your DMARC policy is set up correctly.
Uncover Email Security and Deliverability Issues
2. Having Duplicated DMARC Records
The DMARC spec includes instructions for the discovery of a DMARC policy by the receiving domain, describing the type of DNS queries to issue, the logic for determining the names in the queries to issue, and how to parse the results. Included in those instructions is this text:
“If the remaining set contains multiple records or no records, policy discovery terminates and DMARC processing is not applied to this message.”
We highlight multiple records here because we have seen some reports of ESP tools incorrectly advising their customers to publish a basic DMARC record (e.g., “v=DMARC1; p=none;”) for a given domain when a record already existed.
In some cases, this has led to customers replacing their existing DMARC records with one that is perhaps less strict in its authentication requirements; this is not ideal, but not terrible. However, there have been cases where domain owners have just followed the guidance they were given and added a second DMARC record, resulting in their DMARC records looking something like this:
_dmarc.example.com TXT “v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com”
_dmarc.example.com TXT “v=DMARC1; p=none; rua=mailto:dmac@esp.com”This can have devastating consequences for the domain owner. The second part of that sentence from the DMARC specification – “policy discovery terminates and DMARC processing is not applied to this message” effectively means “There is no DMARC policy existing for this message.”
Any message sent using a domain with two DMARC records in place will be treated as if there is no DMARC policy in place; it will not comply with the Google and Yahoo requirements, and it can be rejected for that reason.
3. Sending DMARC Aggregate Reports to the Wrong Place
A properly formatted DMARC DNS record consists of a number of key/value pairs, many of which are optional and/or have default values. The only two DMARC tags that are required for properly functioning DMARC are the:
- v= tag, specifying the DMARC version (it’s always v=DMARC1)
- p= tag, specifying the policy the domain owner would like to have applied to messages that fail authentication checks (valid settings are “p=none”, “p=quarantine”, and “p=reject”).
At Valimail, we strongly recommend that a third tag/value pair appear in the record: rua. The rua tag is expressed as “rua=mailto:emailaddress@example.com” (with multiple different email addresses allowed if desired). This tag is referenced for the collection of DMARC aggregate reports, which are sent daily by mailbox providers who participate in DMARC. These reports contain statistical data about authentication verdicts for email using the domain in question, as seen by the mailbox provider that sent the report.
DMARC aggregate reports are intended to allow domain owners to identify mail streams that might lack proper authentication and address any shortcomings in their processes. More importantly, they are XML documents, and they’re meant to be machine-parsed, rather than read by humans. This makes it vital that the domain owner point their reports at a mailbox that is designed to receive and parse them, rather than one used for normal communications.
Unfortunately, as with the double DMARC records mentioned above, some senders have received bad advice, and we’ve heard anecdotes that some domain owners with new DMARC records have a “normal” mailbox in their rua tag. This has led to confusion on the part of the domain owner and complaints of abuse directed at the mailbox providers sending the reports.
At Valimail, we have patented technology that combs through these aggregate reports and presents the data in an understandable and actionable way. If you want to save yourself time and headaches, sign up for a free account on Valimail Monitor.
Get DMARC Compliant
These are easy DMARC mistakes to make, especially with conflicting information circulating from various sources. We want to ensure that domain owners avoid these mistakes and have the best information about their domain.
To summarize:
- If sending using a subdomain, check to see if there is already a DMARC record published for your organizational domain. If there is, and it’s sufficient for your needs, you don’t have to publish a separate record for your subdomain, as your mail already has DMARC authentication in place.
- If a third-party tool recommends that you publish a DMARC record for any domain, make sure first that one hasn’t already been published for that domain, because having two is the same as having no DMARC in place at all.
- Make sure that the rua tag is there in any DMARC record you publish, and make sure it points to a mailbox that can receive and properly parse the XML documents that make up the aggregate reports.
Some users have started receiving temporary error messages because their domains aren’t meeting some of these new standards. These messages are designed to tell users what’s wrong with their domain so they can fix it before mail starts getting affected in April. If you’ve made one of these DMARC mistakes, these codes will help you pinpoint the problem.
Avoid these issues with the help of Valimail Align. As these requirements evolve, Align ensures domain compliance across your services, using the Valimail Automation Suite.