DMARC stands for “Domain-based Message Authentication, Reporting & Conformance.” DMARC is protocol that uses SPF and DKIM to determine the authenticity of an email message. DMARC requires both SPF and DKIM to fail in order for it to act on a message.
Your DMARC record is published alongside your domain’s other DNS records (SPF, A record, CNAME, DKIM, etc.). Unlike SPF and DKIM, a properly configured DMARC policy can tell a receiving server whether or not to accept an email from a particular sender. It is important to note that not all receiving servers will perform a DMARC check before accepting a message, but all the major ISPs do and its implementation is growing.
Benefits of DMARC
- Publishing a DMARC record protects your brand by preventing unauthenticated parties from sending mail from your domain. In some cases, simply publishing a DMARC record can result in a positive reputation bump.
- Consuming DMARC reports increases visibility into your email program 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 ecosystem as a whole become more secure and more trustworthy.
What does a DMARC record look like?
You can see what a DMARC record looks like by typing < dig txt _dmarc.<your domain> > in your terminal.
You can also go to https://dmarcian.com/dmarc-inspector/ to view the DMARC record for any domain if they have one published.
Here is an example of DMARC record– this is MassMailer's DMARC record:
_dmarc.massmailer.io. 14400 IN TXT
"v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected]; sp=none; aspf=r;"
Please note that in some of the DNS servers you don't eed to enter the full hostname such as '_dmarc.massmailer.io' but just '_dmarc' which also works fine. Please check with your DNS hosting server support team or support guide on the correct syntax for DNS settings host name.
Let’s break down a DMARC record
“v=DMARC1” 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.
“p=quarantine” This part tells the receiving server what to do with messages that fail DMARC. In this case, the policy is set to “quarantine.” This means that the receiving server will quarantine the email message if that message fails DMARC. This can still be valuable for a sender because DMARC sends reports that alert the domain administrator of any DMARC failures.
“p=quarantine” is generally recommended to implementing a policy that will quarantine unauthorized mail. Most people are surprised to find out how many different people/groups/organizations are sending mail (legitimate or otherwise) on behalf of their domain. Other options for the p= field are “none” and “reject.” “none” will take no action; in most cases, this means it will be sent to the spam folder. “Reject” will stop the messages outright.
“rua=mailto:<emailaddress>” This part tells the receiving server where to send aggregate reports of DMARC failures. These 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.
“ruf=mailto:<emailaddress>” 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. These forensic reports contain details about each individual failure. This email address must be from the domain that the DMARC record is published for.
“rf=afrf” This part tells the receiving server what kind of reporting the policyholder wants. rf stands for reporting format. In this case, rf=afrf means aggregate failure reporting format.
“pct=100” This part tells the receiving server how much of their mail should be subjected to the DMARC policy’s specifications. 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 subdomains.
“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 a domain. If it is set to relax, 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.
Other Notes
As DMARC implementation becomes more ubiquitous, so too will DMARC failures. A good example of this is frequently showing up with many of our high volume clients. Some applications and/or websites have features that allow a user to send an email to themselves or to a friend. Oftentimes, the website or application 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. The same DMARC failure will occur if an unauthorized user attempts to send mail for any domain that publishes a DMARC record with a p=”reject.”