The DMARC (Domain-based Message Authentication, Reporting & Conformance) standard is the best tool brands have to combat phishing attacks that target customers by spoofing their owned domains. But implementing DMARC can get confusing very quickly.
In this post, we will demystify the DMARC record by defining the DMARC tags that make it up. We will cover both required and optional tags, plus discuss some strategies and use cases where lesser-known DMARC tags can afford your organization a greater level of email security.
What are DMARC tags?
DMARC tags are the language of the DMARC standard. They tell the email receiver to (1) check for DMARC and (2) 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 entire DMARC record will be ignored by the receiver.
Example: v=DMARC1
p: Requested Mail Receiver Policy. This tag indicates the policy to be enacted by the receiver for messages that fail DMARC authentication and alignment checks, as specified by the domain owner. This policy will apply to the domain queried and to all subdomains unless a separate subdomain policy is explicitly described (we will cover this later in the post). There are three possible values for the p: tag
p=none: The domain owner requests no specific action be taken on mail that fails DMARC authentication and alignment.
p=quarantine: The domain owner wishes 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 most strict 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
The optional DMARC tags below allow email senders to give more specific instructions on what to do with mail that does not authenticate, removing the guesswork for receivers. These optional tags have a default value that will be assumed if the tag is excluded. The list of tags with an assumed default value are:
rua: Indicates where aggregate DMARC reports should be sent to. Senders designate the destination address in the following format: rua=mailto:domain@example.com.
ruf: Indicates where forensic DMARC reports should be sent to. Senders designate the destination address in the following format: ruf=mailto:domain@example.com.
adkim: Indicates strict or relaxed DKIM identifier alignment. The default is relaxed.
aspf: Indicates strict or relaxed SPF identifier alignment. The default is relaxed.
rf: Format for message failure reports. The default is Authentication Failure Reporting Format, or “AFRF.”
ri: The number of seconds elapsed between sending aggregate reports to the sender. The default value is 86,400 seconds or a day.
pct: Percentage of messages to which the DMARC policy is to 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 values to the latter 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,” Return Path advises clients to use fo:1 to generate the most comprehensive failure reports, providing that much 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:domain@example.com; ruf=mailto:domain@example.com; rf=afrf; pct=100
What about sub-domains?
The final DMARC tag we will discuss today is the sp: tag, which is used to indicate a requested policy for all subdomains where mail is failing 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 “mail.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 “mail.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 policy, but the fraudsters are spoofing subdomains like mail.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 of the mail sent from the top-level domain, “domain.com”
Now that you understand the DNA of the DMARC record, learn more about what kinds of attacks it blocks and what kinds of attacks is does not in The Email Threat Intelligence Report.