The Domain-based Message Authentication, Reporting & Conformance (DMARC) standard is the best tool brands have to combat phishing attacks that target customers by spoofing their owned domains.
This is particularly important in 2021, when phishing attacks are increasing and becoming more sophisticated by the day.
But actually implementing DMARC can get confusing quickly. In this post, we’ll demystify the DMARC record by defining the DMARC tags that comprise it.
We’ll cover required and optional tags, and discuss strategies and use cases where lesser-known DMARC tags can afford your organization a greater level of email security.
How does DMARC work?
DMARC uses two other email authentication protocols (SPF and DKIM) to help receivers check the authenticity of an email and determine whether to deliver the message to the inbox, quarantine it in a spam or junk folder, or block the message entirely.
Used by themselves, SPF and DKIM can be vulnerable to spoofing or phishing. DMARC attempts to combine DKIM and SPF checks to the domain included in the “From” header. DMARC matches (or aligns) the domain in the From header with the “d=sender.domain” tag in DKIM, and checks for alignment between the SPF “envelope from” domain with the sender domain.
For a message to pass DMARC, it must pass SPF authentication and alignment and/or DKIM authentication and alignment.
What are DMARC tags?
DMARC tags are the language of the DMARC standard. They tell the email receiver to check for DMARC and what to do with messages that fail DMARC authentication.
Required DMARC tags
There are only two required DMARC tags: “v:” and “p:”
v: Version. This tag is used to identify the TXT record as a DMARC record, so email receivers can distinguish it from other TXT records. The v: tag must have the value of “DMARC1” and it must be listed as the first tag within the entire DMARC record. If the value doesn’t exactly match “DMARC1” or the v: tag is not listed first, the reciever will ignore the entire DMARC record.
Example: v=DMARC1
p: Requested Mail Receiver Policy. This tag tells mailbox providers how to handle messages that fail DMARC authentication and alignment checks.
This policy will apply to the domain queried and to all subdomains unless a separate subdomain policy is explicitly described (more on this later). There are three possible values for the p: tag:
- p=none: With DMARC policy none (p=none) the domain owner requests no specific action be taken on mail that fails DMARC authentication and alignment.
- p=quarantine: The domain owner instructs that mail failing the DMARC authentication and alignment checks be treated as suspicious by mail receivers. This can mean receivers place the email in the spam/junk folder, flag as it suspicious, or scrutinize this mail with extra intensity.
- p=reject: The domain owner requests that mail receivers reject the email that fails the DMARC authentication and alignment checks. Rejection should occur during the SMTP transaction. This is the strictest policy and offers the highest level of protection.
Given the information above, the most basic DMARC record example could be: v=DMARC1; p=none.
Optional DMARC tags
Optional DMARC tags allow email senders to give more specific instructions on what to do with mail that does not authenticate.
- rua: Indicates where aggregate DMARC reports should be sent. Senders designate the destination address in the following format: rua=mailto:[email protected].
- ruf: Indicates where forensic DMARC reports should be sent. Senders designate the destination address in the following format: ruf=mailto:[email protected].
Optional tags with an assumed default value
The following optional tags have a default value that will be assumed if the tag is excluded:
- adkim: Indicates strict or relaxed DKIM identifier alignment. “Relaxed” is the default.
- aspf: Indicates strict or relaxed SPF identifier alignment.“Relaxed” is the default.
- rf: Format for message failure reports. “Authentication Failure Reporting Format,” or “AFRF,” is the default.
- ri: The number of seconds elapsed between sending aggregate reports to the sender. The default value is 86,400 seconds, or one day.
- pct: Percentage of messages to which the DMARC policy will be applied. This parameter provides a way to gradually implement and test the impact of the policy.
- fo: Dictates what type of authentication and/or alignment vulnerabilities are reported back to the Domain Owner. There are four possible values for the fo: tag:
- 0: Generate a DMARC failure report if all underlying authentication mechanisms fail to produce an aligned “pass” result. (Default)
- 1: Generate a DMARC failure report if any underlying authentication mechanism produced something other than an aligned “pass” result.
- d: Generate a DKIM failure report if the message had a signature that failed evaluation, regardless of its alignment.
- s: Generate an SPF failure report if the message failed SPF evaluation, regardless of its alignment.
While the default is “fo=0,” Validity advises clients to use fo:1 to generate the most comprehensive failure reports, providing more granular visibility into the email channel.
Below is an example DMARC record. Based on what you have learned so far, try deciphering each tag:
v=DMARC1; p=reject; fo=1; rua=mailto:[email protected]; ruf=mailto:[email protected]; rf=afrf; pct=100
What about sub-domains?
The final tag we’ll discuss today is the sp: tag. This tag indicates a requested policy for all subdomains where mail fails the DMARC authentication and alignment checks.
This tag is only applicable to top-level domains (organizational level domains). It is most effective when a Domain Owner wants to specify different policy for the top-level domain and all subdomains.
For the following scenarios, we will use the top-level domain of “domain.com” and the sub-domain of “mail.domain.com” to illustrate the use cases.
- The Domain Owner wants to enforce a reject policy for “domain.com,” but a quarantine policy for “email.domain.com” (and all other subdomains). The DMARC record for “domain.com” would then include “v=DMARC1; p=reject; sp=quarantine.” This is an effective strategy if the organization needs to maintain separate DMARC policy for the top-level domain and all subdomains.
- Domain Owner wants to enforce a reject policy for “email.domain.com” (and all other subdomains) but not enforce a reject policy for “domain.com.” The DMARC record for “domain.com” would then include “v=DMARC1; p=none; sp=reject.” This would be an effective strategy to combat dictionary attacks in the event that the top-level domain isn’t ready to enforce a strict reject policy, but the fraudsters spoof subdomains like email.domain.com, abc.domain.com, 123.domain.com, xyz.domain.com, etc. Setting the sp: tag to “reject” will protect the organization from these dictionary attacks, targeting subdomains without impacting any mail sent from the top-level domain, “domain.com.”
Implementing DMARC
If senders are unsure how DMARC will affect email sent by their organization, it can be useful to test that DMARC is authenticating correctly. Achieve this by starting with a DMARC policy of p=”none” or p=”quarantine” with reporting mode on. Monitor the reports regularly to ensure that authentication works as expected.
Once you verify that SPF and DKIM are fully authenticated on your mail streams, it’s safe to change your policy to “reject.”
Now you understand the DNA of the DMARC record. For more tips to maximize your email performance, read Validity’s eBook: “Secrets of Best-in-Class Email Senders.”