The Domain-based Message Authentication, Reporting, and Compliance (DMARC) standard was launched in 2015 by the Internet Engineering Task Force (IETF) in RFC 7489. However, the first DMARC standard was first published in 2012 to prevent email abuse.
The goal of this standard is to protect email from spoofing by making it difficult to masquerade as a legitimate sender. It puts in place obligations on organizations that use email as part of their business operations.
These will result in less spam and phishing emails being sent out, as well as making it harder for people who are trying to impersonate other users or businesses.
In this blog, we'll take an in-depth look at just how important it is to have your company implement DMARC. We’ll explore the risks and potential benefits associated with adopting the standard, along with detailed tips on how you can successfully implement DMARC.
DMARC was originally developed to combat email spoofing and phishing. It is a standard that provides a framework for email authentication, which means it creates the guarantees of who sent an email. With DMARC enabled, users can be assured that the emails they are receiving are actually from the verified senders they are expecting.
The benefits of implementing DMARC include:
Preventing businesses from being impersonated or spammed
Preventing phishing attacks
Reducing the amount of spam sent out
Protecting against identity theft
DMARC works by putting in place an anti-spoofing mechanism that verifies the authenticity of messages. If a message is not authenticated using DMARC, it will be tagged as spam and ignored. This helps to reduce the risks associated with phishing and spoofing.
Additionally, if a legitimate email address is being impersonated, the recipient may be notified of this.
The standard requires any organization that sends emails to verify their identity using Domain Keys Identified Mail (DKIM). This is done by introducing a _dmarc txt record in your domain's DNS. This record is pulled every time an email is received by any MX server (Mail server) around the world, that's sent by this domain. This record specifies either SPF or DKIM check should pass or both of them have to pass for the DMARC record to succeed.
The most common setting for DMARC records is to let either SPF or DKIM protocols pass. It's a known fact that SPF protocol can fail, if you use old-school email forwarding, as they invoke SRS protocol instead. Thus, setting DMARC on either DKIM or SPF ensures the email is genuine.
You can also set the action which will be performed, in case an email from your domain fails the DMARC check. Options being none, quarantine, reject.
Businesses need to understand with increased cyber security attacks DMARC is a must-have, to prevent phishing/spoofing attacks against your business.
DMARC authentication result use following syntax:
dmarc=<pass|fail|bestguesspass|none> action= permerror|temperror|oreject|pct.quarantine|pct.reject> header.from=
As you can see, bestguesspass is the authentication result of a DMARC check. But interestingly, this result is shown, if DKIM and SPF records exist for a domain, but DMARC is missing.
The first explanation of this result was done by Microsoft, which states, that in case a DMARC record exists for the domain, a DMARC check would have passed for this email. However, the DMARC records don't exist and hence, the result is bestguesspass instead of pass.
We strongly advise you to add SPF, DKIM, and DMARC records to your domain as the first step toward preventing email spoofing for your domain.
DMARC works by adding a DNS record to your domain. This _dmarc record is pulled for every email from your domain.
There are two actual options available: quarantine or reject that can be taken by the recipient mail server when a DMARC failure happens for any email sent on behalf of your domain.
When you quarantine, the email is sent to an inbox that is separate from your primary inbox, usually, it will be the spam or junk section of the recipient's email id. Some of the recipient email id providers, also additionally denote a warning when these failed emails are opened, denoting that the email has failed the DMARC check.
Reject means the email is not delivered at all. The recipient email server will decline the delivery of an email altogether upon DMARC failure.
The decision between these options usually comes down to what level of security you are looking for vs convenience. If you’re unsure which option would be better for your company, consider using the quarantine option, as if your email sending system is not configured properly, even legitimate emails can be rejected.
The none action for a DMARC record is intended to be used only for testing purposes. The difference between the two is that the first stage is where you choose to not use DMARC, and the second one is when you start to enact all of the features of DMARC and quarantine messages.
The decision of whether or not to implement DMARC has to do with your company’s risk tolerance and goals. If you want to protect your company from phishing email attacks, then implementing a quarantine type of policy might be more appropriate for your needs. You can go a step further and even implement reject action instead of quarantine if need be.
We strongly recommend that you implement Quarantine instead of None as it will increase the number of spoofed/phishing email messages that get blocked by DMARC.
The answer is no. You cannot have multiple entries in your DNS record for DMARC.
A domain should not have more than one DMARC records, else DMARC processing fails to function on that domain. It will be treated as if DMARC records did not exist for the domain at all.
The Domain-based Message Authentication, Reporting, and Compliance (DMARC) standard were launched in 2015 by the Internet Engineering Task Force (IETF). The goal of this standard is to provide a means of authenticating email messages.
As DMARC records are added as TXT records with the name "_dmarc", they are indeed TXT records.
DMARC is a standard that is compatible with both DKIM and SPF. You have the option of either enforcing both SPF and DKIM to succeed or either one of them.
DKIM is used the sign the content of your email. Any alteration of email content leads to DKIM failure.
Some businesses have felt that they are required to implement DMARC in conjunction with DKIM to send messages out. However, there is no such enforcement for DMARC on its own.
If you think your company is vulnerable, what do you do? You take action.
Similarly, if your company doesn't have a DMARC policy set up, it's time to implement one. The best option is to create a policy that states what action should be taken by the recipient email server if emails on behalf of your domain fail the DMARC record check.
You can reject all emails coming from unknown senders on your domain. To find these unknown sending IPs on behalf of your domain, Mutant Mail offers a free DMARC report service.
The first step to successfully implementing DMARC is to understand what it does and how it works.
DMARC in nutshell works on top of DKIM and SPF protocol to supervise what action should be taken in case of failure. It is also responsible for sending aggregated reporting emails to figure out, in case anyone is trying to spoof emails on behalf of your domain.
Before you do anything else, carefully consider which type of implementation best suits your company’s needs. What kind of action do you want recipient email ids to take in case of failure etc.
Most common implementation of DMARC record is below.
host / name / key : _dmarc
Value : v=DMARC1; p=quarantine; adkim=s
The main goal of DMARC is to protect users from spoofing, which is essentially when a fraudulent sender sends out emails that appear as if they are coming from a legitimate source within your domain.
We advise that before implementing DMARC on your subdomain you should ensure your main domain is protected with DMARC already.
DMARC, SPF, and DKIM are only needed for the subdomain if you are sending emails via your subdomain as well. As each subdomain has its reputation, routing, and credibility, some companies choose to use their subdomain for sending emails for various reasons.
Most common implementation of DMARC record on subdomain is below.
host / name / key : _dmarc.subdomain
Value : v=DMARC1; p=quarantine; adkim=s
It's also possible to implement action on the subdomain via the DMARC record of your main domain using the sp parameter.
The goal of DMARC is to protect email from spoofing. DMARC reports will enable you to see how well your email messages are authenticated.
DMARC reports are defined in DNS records managed by your domain registrar. When an email message is sent that is not authenticated with DMARC, the receiver can send a report back to the Email ID specified in the DNS record indicating that there was an issue with the delivery of that message.
This can be used for various purposes, such as informing the domain owner that one of their sending servers is failing authentication or that someone might be attempting to spoof emails to come on behalf of your domain. The domain owner receives the DMARC report as an email with the report as an attachment. The email id used for sending the DMARC report is controlled by the "rua" attribute in your DMARC record. They can then decide whether they would like to take any action based on the results of the DMARC report.