What is DMARC?
DMARC, or “Domain-based Message Authentication, Reporting & Conformance,” is another type of email authentication. It adds linkage to the author From domain name, publishes policies for recipient handling of authentication failures, and reports from receivers to senders to improve and monitor the protection of the domain from fraudulent email.
Rather than thinking of DMARC as a service on the cloud, think of it more like a standard or policy that your domain is upholding. DMARC unifies the SPF and DKIM authentication mechanisms into a common framework and allows domain owners to declare how they would like an email from that domain to be handled if it fails an authorization test.
Your DMARC record is published alongside your DNS records, including:
Unlike SPF and DKIM, a properly configured DMARC policy can tell a receiving server whether or not to accept an email from a sender.
Note: Not all mail servers check DMARC before receiving a message, but all ISPs do.
How does DMARC work?
Our friends from Belkins have laid it out perfectly for you:
- You craft your email and hit send to your contacts.
- Your mail server adds a DKIM header, which looks for forged sender addresses.
- DKIM confirms that you are legit.
- Your email heads on over to your recipients’ mail server.
- The recipients’ email server checks for authentication.
- Once given the okay, DMARC jumps in to decide if your email should be passed, quarantined, or rejected.
- If passed, your message arrives in your recipients’ inbox to catch one final spam filter.
- You made it to the inbox!
Why is DMARC important?
Spam messages accounted for 53.95 percent of e-mail traffic in March 2020. During the most recently measured period. Despite its ubiquity, the global e-mail spam rate has actually been decreasing: the global annual spam e-mail rate in 2018 was 55 percent, down from 69 percent in 2012.
Spear phishing is effective: despite deploying traditional security solutions, 85% of organizations have suffered from phishing attacks. These attacks are everywhere, and most organizations will encounter them at one point or another. It’s also costly: Of those experiencing attacks over the last 12 months, 81% suffered some negative impact as a result, with an average financial cost of $1.6 million—and some losses in the tens of millions of dollars.
- Publishing a DMARC record protects your brand by preventing unauthorized parties from sending mail from your domain. In some cases, simply publishing a DMARC record can result in a positive reputation bump.
- Using DMARC reports increases visibility into your email campaigns by letting you know who is sending mail from your domain.
- DMARC helps the email community establish a consistent policy for dealing with messages that fail to authenticate. This helps the email community to be more secure and trustworthy as a whole.
- DMARC helps you stay out of your recipients’ spam folder.
- DMARC increases customers’ confidence in your brand. When they see that you take email security seriously, they know you care about their information's privacy.
DMARC was an important aspect of modern IT security hygiene in 2018, and U.S. government adoption will likely help spur wider adoption by enterprises worldwide.
How does DMARC affect email deliverability?
You can improve your email’s deliverability with DMARC by:
- Publishing a DMARC record
By placing a DMARC record, a domain owner requests ISP’s (who support DMARC) to send feedback on the emails which they receive for that domain. This indicates receivers that this domain is serious about improving their email authentication.
- Using the DMARC results to improve the authentication results
The DMARC reports show which sources and IPs send out emails on behalf of a domain and provide insight into the SPF and DKIM verification results. With these results, a domain owner can start to improve the SPF and DKIM verification. By improving their email authentication, a domain becomes more trustworthy and may lead to ISPs being more willing to place emails in the receiver's primary inbox.
- Enforcing the DMARC policy
The DMARC policy can be enforced in small steps to quarantine and eventually to a 100% reject policy. Enforcing the DMARC policy will reduce the impact of malicious emails sent on behalf of the domain. It also shows ISPs that the domain owner put a lot of effort into securing the email channel so receivers can rely on emails originating from their domain. This can lead to ISPs being more willing to place emails in the primary inbox and can help to improve domain reputation.
What does a DMARC record look like?
Here is an example of a DMARC record–this is SendGrid’s DMARC record:
v=DMARC1\;p=none\;rua=mailto:[email protected]\;ruf=mailto:[email protected]\;rf=afrf\;pct=100
What does the Folderly email test tool cover with regards to DMARC?
- dmarc_dkim_alignment – DMARC DKIM From/Domain Alignment
- dmarc_spf_alignment – DMARC SPF From/Domain Alignment
- no_dmarc_record – DMARC DNS Record Existence
- invalid_dmarc_version – Valid DMARC DNS Record version
- invalid_dmarc_policy – Valid DMARC DNS Record policy
- multiple_dmarc_records – Multiple DMARC DNS Record detection
- dmarc_none_policy – DMARC DNS Record using the ‘none’ policy
Let’s break it down
Version – This is the identifier that the receiving server looks for when it is scanning the DNS record for the domain it received the message from. If the domain does not have a txt record that begins with v=DMARC1, the receiving server will not run a DMARC check.
Policy – The policy you select in your DMARC record will tell the participating recipient email server what to do with mail that doesn’t pass SPF and DKIM, but claims to be from your domain. In this case, the policy is set to “none.” There are 3 types of policies you can set:
- p=none – Tell the receiver to perform no actions against unqualified mail, but still send email reports to the mailto: in the DMARC record for any infractions.
- p=quarantine – Tell the receiver to quarantine unqualified mail, which generally means “send this directly to the spam folder.
- ”p=reject – Tell the receiver to completely deny any unqualified mail for the domain. With this enabled, only mail that is verified as 100% being signed by your domain will even have a chance at the inbox. Any mail that does not pass is denied— not bounced—so there’s no way to catch false positives.
This part tells the receiving server where to send aggregate reports of DMARC failures. Aggregate reports are sent daily to the administrator of the domain that the DMARC record belongs to. They include high-level information about DMARC failures but do not provide granular detail about each incident. This can be any email address you choose.
This part tells the receiving server where to send forensic reports of DMARC failures. These forensic reports are sent in real-time to the administrator of the domain that the DMARC record belongs to and contain details about each individual failure. This email address must be from the domain that the DMARC record is published for.
Reporting format. This part tells the receiving server what kind of reporting the policyholder wants. In this case rf=afrf means aggregate failure reporting format.
Percent – This part tells the receiving server how much of their mail should be subjected to the DMARC policy’s specifications. You can choose any number from 1-100. In this case, if the p= was set to reject, 100% of the mail that fails DMARC would be rejected.
There are a number of other mechanisms that can be included in a DMARC record. A few notable ones include:
“sp=” This part would tell the receiving server whether or not to apply the DMARC policy to sub domains.
“adkim=” This sets the DKIM alignment. It can either be set to “s” for strict or “r” for relaxed. Strict means the DKIM portion of DMARC authentication will only pass if the d= field in the DKIM signature EXACTLY matches the from domain. If it is set to relaxed, messages will pass the DKIM portion of the DMARC authentication if the DKIM d= field matches the root domain of the from address.
“ri=” This sets the interval for how often you want to receive aggregate reports about DMARC failures.
Keep in mind that:
- DMARC is not a quick deliverability fix. Just deploying a DMARC policy is not just a quick email deliverability fix. By deploying and enforcing a DMARC policy, your deliverability can improve; however, this is not a guarantee.
- Immediately enforcing a reject policy is not a good idea. We strongly discourage enforcing a reject policy when starting. When companies encounter a phishing attack, they immediately lock down their email channel by placing a DMARC record and enforcing a 100% p=reject policy. This is effective in blocking phishing attacks. However, it will also lead to legitimate emails being lost. DMARC Analyzer advises to start with a p=none policy and monitor the results. This process can take 1-12 months.
- DMARC does not protect inbound email streams. DMARC is not designed to protect inbound emails.
- DMARC requires both SPF and DKIM to fail for it to act on a message.
- As DMARC implementation becomes more mainstream, so will DMARC failures. Some applications or websites have features that allow users to send an email to themselves or a friend. The website or application often sends these emails from the user’s own email address ([email protected]). Because of Yahoo’s DMARC policy, these messages will be rejected by any receiving server that does a DMARC check. This will also occur if an unauthorized user attempts to send mail for any domain that publishes a DMARC record with a p=”reject.”
DMARC is an important evolution of email authentication. This is just another great example of email senders and ISPs working together to protect the email channel. To learn more about DMARC, visit the organization’s website at dmarc.org.