Email Authentication Series
Part 1: Why Email Authentication Matters to Your Email Program
Part 2: Understanding SPF Authentication
Part 3: Understanding DKIM Authentication
> Part 4: Understanding DMARC Authentication
Part 5: Understanding BIMI
How DMARC helps to protect your domain from spoofing
It’s DMARC time. If you just got here, you might want to brush up on Parts 1-3 before you jump into DMARC. We covered SPF, DKIM and why email authentication is important and how the authentication protocols work together to protect your email program. These are an excellent precursor to understanding DMARC.
Now let’s get into what DMARC is, how it protects against spoofing, how it works, its gaps, and tips on DMARC implementation.
Spoofing is an attack where an entity deliberately uses your domain or a “fake” domain—eerily similiar to yours—to gain an email recipient’s confidence. In most cases, it’s to steal or phish sensitive information to gain access to systems or accounts.
What is DMARC and what does it protect?
DMARC, or Domain-based Message Authentication, Reporting, and Conformance, provides a way for domain owners to monitor who is sending mail using their domain. It also provides a way to tell receivers how to treat mail from them (or supposedly from them) when it doesn’t pass authentication and alignment checks.
The DMARC specification was published in 2012, but it wasn’t until 6 years later that it really started to accelerate in adoptions.
Throughout the series, we discussed how email has a lot of natural flexibility to allow for a number of sending needs, but this flexibility creates identity gaps. And these gaps have become abused.
SPF and DKIM were able to stop some domain spoofing, but they never addressed what was being displayed to the email recipient. In other words, the mail would pass authentication as the senders would legitimately declare their identity on the backend (with the servers), but what was shown to the end recipient was never verified.
DMARC compares the backend identity with the frontend identity. Based on the results, the receiver (or mailbox provider) then decides how they want to treat the mail. Although receivers may have been doing this already and using the results as a signal, DMARC provides a standardized way to do this.
DMARC also brought the sender into the decision-making. The DMARC records gives senders the ability to publish their preference around what should be approved or rejected when their domain is misused. In addition, it made abuse reporting more accessible. Now senders can receive reports on all messaging mailed with their domains, who is sending it, authentication, and disposition (acceptance/bulking) results.
We talked a lot about what authentication does in regard to protecting your domain. However, authentication is not a sealed box of protection. Phishing is complex and strategic. Although your domain is protected, an attacker can spin up a similar domain which may seem like a domain that belongs to you. However, in reality, it is owned and operated by someone else.
This is why authentication is an important signal. But it is by no means a guarantee of delivery or deliverability. However, when authentication is not in place, there will be delivery and deliverability issues.
Most spammers don’t authenticate. They want to blast emails and move on. Investment in formulating a secure and protected stream is not of interest. So when you don’t authenticate, it’s a negative signal to mailbox providers that you are amongst the company of spammers. Phishers, on the other hand, are deceptive and methodical. They want to blend in because when you don’t, you get caught.
As with DKIM, DMARC helps to identify what is authorized from a domain which can then be used to ‘fingerprint’ or identify other streams, both good and bad.
DMARC differs from SPF and DKIM in that it doesn’t have to sit with each individual sending subdomain. A DMARC record can be posted on the subdomain or the organizational domain.
DMARC records on the organizational level will flow down to all subdomains beneath it. DMARC can also be defined such that the organizational domain can have one policy and the subdomains can share a different policy. If you want unique policies per subdomain, you can move to publish unique DMARC records for each subdomain. It allows you to be selective about which subdomains have a more restrictive policy than others.
Before we move on, let’s quickly note that the word policy purely means a sender’s preference for how they want the mail to be treated by receivers. The word policy as it relates to DMARC doesn’t impact your security team’s policies or decisions around other areas of your business.
How does DMARC protect your brand’s identity?
When you put all three authentication protocols in place, they can be seen as a complete security solution for anti-spoofing. Within this framework, DMARC is your security team and alarm. It not only confirms all identities shared with the recipient match the actual delivery agent, it sends summary reports so you can flag issues.
We’ve talked a bit about the gaps in email and how SPF and DKIM fill them, but that is all on the backend. It’s all the good stuff that you don’t see as a typical email user who opens their inbox, selects messages to read and moves on. Most users aren’t heavily involved in reading headers to confirm authenticity. Most users don’t even go beyond the Friendly From Name to see the From Address.
The implementation of DMARC, however, does check that all identities shared between the servers are also shared to the end recipient. In other words, does your ID match the name you introduce yourself as in person?
There are three parts to DMARC:
- Verification that SPF or DKIM pass authentication checks and identities align
- Report verification results to the customer-facing domain in the From Address
- Consider domain-owner policies for DMARC failures
The reports highlight both spoofing issues and configuration issues that need to be addressed.
A typical DMARC record, which is stored in a TXT record, looks like this:
The record defines both the enforcement policy and who should receive the DMARC reports. The bolded sections should be defined for each domain. Now let’s define what these sections are. Note: there are a number of additional attributes that can be added to the record. For now, we’ll focus on the ones recommended at a minimum.
DMARC1: The v= field contains the DMARC specification version the DNS record and policy is following. As of today, the value can only be DMARC1. This is a required field.
As stated, receivers can and do check on identities and authentication results on their own. DMARC enables the sender to weigh in on what they want to happen to mail purporting to come from them. It gives them control over how they want to handle potentially spoofed mail. It also allows them to see what is happening to the mail, both with the disposition (final assessment) from the receiver and current authentication status (to make sure there are no infrastructure issues occurring).
So let’s walk you through what it looks like to pass DMARC. Keep in mind, the order in which a receiver actually runs through these checks may be different than the general workflow noted below.
The message is received
Look up DMARC policy in DNS for the From Address domain
SPF and DKIM authentication protocols are checked and reviewed for passage
The domain from the From Address is compared to the domains in the DKIM signature and/or SPF (return-path domain)
Alignment occurs when authentication passes AND the domains match
In this example, a misalignment, or DMARC failure, would result in a rejection if the sender policy is honored.
However, it’s important to note that if a policy exists, the receiver can deploy the policy posted in the DMARC record (optional) or employ their own decisioning. DMARC is not a guarantee that the policy will be honored.
If no policy exists and the domain in the From Address is a subdomain, look up the dmarc policy on the domain organizational level.
If no policy exists on the parent or organizational level, the receiver applies its own decision based on their filtering and acceptance criteria.
Aggregate and send reports to address in the rua record
In this example, the reports would be sent to email@example.com.
We reviewed an example that passed DMARC, but here’s a chart of the different possibilities and when DMARC would pass. The ideal setup is when everything passes and aligns.
DMARC brings the senders into the conversation about what should happen to a message, or its disposition, when authentication or identity alignment checks fail. It sends reports to ensure senders have the data they need to assess infrastructure gaps and domain threats. It prevents spoofing by ensuring a sender’s domain is only used if it is also used to authenticate the message.
How to set up your DMARC record
Of the three protocols, DMARC is probably the most time-intensive. All three require DNS entries, which employ the same teams and time to get published. However, because DMARC involves reporting and policy decisions, additional time is recommended to make sure all aspects of a program are thoroughly reviewed. It is not uncommon for a sender to set up DMARC and find old streams still running or authentication errors on new setups.
First up, before you begin publishing a DMARC record, you need to:
Publish SPF and/or DKIM records, make sure they are deployed in your messages, AND that they are passing
You can do a quick authentication check using kbxscore.com.
At least one of your authentication protocols is using the same domain as the domain in the From Address
We didn’t cover this in the DMARC attributes, but by default DMARC aligns using a ‘relaxed’ position meaning only the organizational domains have to match (From Domain of email.kickbox.com passes alignment with an Authentication Domain of kickbox.com).
However, if you deploy a ‘strict’ policy, then the domains in use must match exactly (From Domain of email.kickbox.com does not pass alignment with an Authentication Domain of kickbox.com; instead the Authentication domain must be email.kickbox.com or the From Domain needs to be updated to kickbox.com).
Once your prerequisites are in place, you can begin implementing DMARC and moving towards an enforcement policy, if desired.
Prepare your system to receive DMARC reports or utilize a third-party DMARC monitoring tool to aggregate the incoming reports
DMARC reports are sent when a domain specifies an address in the rua or ruf attribute. The reports are sent in XML format.
Although not required, a process or service that accepts and extracts the information into an aggregated and visualized way makes the XML reports easily consumable for any user (with or without XML knowledge).
Third-party DMARC monitoring tools like Kickbox allow you to monitor multiple domains 24/7 and aggregate incoming DMARC reports in one place.
Add DMARC to DNS starting with p=none
Starting at ‘none’ means you are not requesting any specific disposition to the mail. You are leaving the filtering decision in the hands of the receivers alone. However, a policy of ‘none’ still allows you to monitor current mail flows, their authentication status, and potential impact when a policy is enforced.
Look for streams that are outdated and need to be shut down. Look for past vendors that should no longer be mailing. Look for authentication results and alignment results to identify areas that need to be addressed before a policy is deployed. This may take at least 30 days to make sure you are going through the full cycle of communications.
Correct authentication and alignment failures
Before you deploy a change in your policy, make sure you address any issues and then monitor again to make sure they were deployed correctly.
Monitor reports, again
Make sure previously identified vulnerabilities are addressed and nothing is left outstanding. Again, you may need to monitor for at least 30 days to make sure all streams have had a chance to mail with the new settings.
Update DMARC to p=quarantine or p=reject
It’s recommended to start with ‘quarantine,’ monitor, and then move to ‘reject’ (if desired).
Monitor reports on an ongoing basis
Never stop monitoring DMARC even after your DMARC record is up. Reporting is a key component of DMARC to keep you alerted about what is happening with your mail at the receiver level. And reporting is not just for phishing and spoofing decisions, but it will identify which authentication protocols remain active and which ones may be experiencing an issue.
For example, DMARC reporting can identify when a DNS issue occurs and prevents DKIM from passing.
Although DMARC solves a lot of problems, there are a few more considerations to keep in mind when deploying DMARC and they may impact how restrictive you make your policy.
DMARC gaps and vulnerabilities
Anyone can authenticate
Phishers and spammers can authenticate their mail. They can purchase domains that look like yours. They can also mail content that looks like yours.
In these cases, DMARC alone isn’t enough to protect your domain reputation or your customers. The mail may not impact your deliverability directly, but it will impact your brand directly if customers are baited.
It’s important to set expectations, so your customers know what to look for to stay protected. You can also try to purchase domains that are most likely to be used to mimic your domain and ‘park’ them so no one else can use them.
DMARC is only as strong as SPF and DKIM
DMARC is limited to the protocols that support it. If you are an SPF-only sender, and your mail fails SPF due to a forwarding rule, DMARC won’t help. This is where ARC (Authenticated Received Chain) can be helpful. Although not all receivers incorporate ARC when the mail is passed along. And similarly with DKIM, if it is broken along the way, DMARC too will break. Cover your message streams with both SPF and DKIM to get the best performance out of DMARC.
DMARC implementation tips
There are a number of items to consider when publishing a DMARC record or thinking about how to implement it (RFC 7489). Here are 7 recommendations and best practices to keep in mind:
Monitor DMARC reports
One of the main features of DMARC is its ability to report authentication results and identify authentication issues. Monitoring DMARC reports helps you identify issues before they amplify into a deliverability issue impacting campaign performance. It also helps identify how often your domain is being misused to determine what level of protection you want to deploy for your domain.
Publish a DMARC record for the organizational domain
DMARC can be published for individual subdomains, but it’s a better practice to cover all domains by publishing on the organizational domain. Managing domains individually can lead to misses and lack consistency. Plus, if you want to implement BIMI (Brand Indicators for Message Identification), DMARC is required at the top of your organizational domain tree.
Although not covered in depth here, DMARC records on the organizational domain can be defined to identify a policy for their organizational domain as well as one for the subdomains (using sp=none/quarantine/reject). You can also opt to publish DMARC records for individual subdomains alone or in addition to a DMARC record on the organizational domain.
Publishing on the individual subdomain is helpful if you want unique policies for your subdomains or an individual subdomain to have a policy different from the general subdomain policy in the main record.
Perhaps you have a ‘reject’ policy on the organizational level, ‘quarantine’ on the subdomain, and one particular subdomain you want ‘none’ employed. Whatever policy is posted directly on the subdomain will override policies posted on the organizational level.
Note: a small set of mailbox providers may only check DMARC at the level of the domain seen in the message. Meaning the subdomain has to have a DMARC record too (regardless of what is posted on the organizational level).
Subdomain policies are also helpful when using multiple ESPs and you want them to monitor the reports for the subdomains mailing off their platform. However, in most cases, you’ll probably use a third-party DMARC reporting tool that can collect and report on all data and all subdomains for you.
Use CNAMES for delegation
For the same reasons discussed in our SPF and DKIM article, CNAME is a sure-fire way to quickly adapt to changes on the provider side. However, this should only be used with subdomains.
When moving the policy from ‘none’ to ‘reject,’ do it slowly
A wonderful feature of DMARC is the reporting. Not just to understand the impact of spoofing, but it often uncovers streams and settings going out that should have been deprecated or that were started up without proper configuration.
Before you move a policy from ‘none’ to ‘quarantine’ or ‘quarantine’ to ‘reject,’ we recommend you move through each one slowly (do not go directly from ‘none’ to ‘reject’).
First, monitor at p=none and see if there are any streams out there that are misconfigured. If so, fix them up before you move on. Once you feel comfortable all mail is properly authenticated (this could take 1-2 months), move to ‘quarantine.’
Again, monitor and see if the disposition of your mail is being affected, how, how much, and if it’s of concern. As we discussed throughout the series, there are gaps along the way that could break DMARC. So if you know the impact is minimal, moving to ‘reject’ would be your next step, or staying at ‘quarantine.’
When you are ready (again, likely 1-2 months), move to ‘reject.’ In some cases, senders want to remain at ‘quarantine’ because they would rather forwarded mail be placed in the bulk folder versus rejected, but the decision is a choice that has to be made uniquely for each business.
And some senders will remain at ‘none.’ But note that DMARC records that do impact deliverability positively are the ones that have a policy enforced (‘quarantine’ or ‘reject’). A policy of ‘none’ won’t harm a sender, but it won’t help either. A ‘none’ policy will keep the sender informed of what is happening if they decide a stricter policy is not for them.
Avoid relying on the percentage attribute
Along the way, you may hear a suggestion to try the percentage attribute to help ramp up to a stricter DMARC policy. We didn’t cover the percentage attribute (pct=), but it is the percentage of time you want a policy enforced. So if you selected 25, then 25% of the email that failed would have the policy enforced.
Originally this was a way to ease into a different policy and see what comes of the mail. But not all receivers honor the percentage tag and it may become deprecated in the future. So, although it’s still an option, it’s not one that has a lot of support.
This also applies for those that want to publish a policy for the ‘benefits’ but don’t want to enforce it. So if anyone is publishing p=reject with a percentage of 0, they may end up actually enforcing a ‘reject’ policy.
Use proper syntax
Some senders want to have reports sent to multiple addresses. This could include a third-party DMARC aggregator, an internal team, ESP, etc. If you have multiple recipients, make sure each email address is preceded by mailto: and followed by a comma. When the list is done, the last email should be followed by a semicolon._dmarc.email.kickbox.com IN TXT “v=DMARC1; p=reject; rua=mailto:firstname.lastname@example.org,mailto:email@example.com;”
And remember, DMARC should only have 1 TXT record per domain, so creating multiple DMARC records to allow for multiple recipients is not correct. They should all sit in the same record.
Verification records should be added to the DNS of all third-party aggregators
DMARC provides a way to verify external email addresses to prevent malicious actors from adding in email addresses they don’t own but want to spam or abuse with DMARC reports.
Any email address defined in the DMARC record as a receiver of aggregated or forensic reporting that does not share the same domain as the domain for the DMARC record, must add an verification record.
For example, if kickbox.com wants to send DMARC reports to reportdomain.com, reportdomain.com must first verify that they want to receive the reports. To verify that they want to receive DMARC records, they need to publish a reporting DNS DMARC record.
Here’s a simple example using DNS records.
DMARC Record_dmarc.email.kickbox.com IN TXT “v=DMARC1; p=reject; rua=mailto:firstname.lastname@example.org,mailto:email@example.com;”
Verification Record for external domainemail.kickbox.com._report._dmarc.reportdomain.com IN TXT “v=DMARC1;”
Use flat ” ” and not curly “ ”
Be careful with copy and paste in your DNS tools. Lookup and authentication issues can occur if non-ASCII characters are introduced.
DMARC’s goal is to prevent spoofing and get the marketer in on the conversation by allowing them to set their own acceptance and disposition preference.
DMARC is a strong signal that continues to grow and provides a basis for receivers to make decisions surrounding acceptance and placement. And when your DMARC record is enforced, you become eligible for (pause for dramatic effect) BIMI.
Up Next: The Marketer’s Reward, logos and brand impressions with BIMI. What is it and how to implement it?