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.
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.
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.
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.
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:
Given the information above, the most basic DMARC record example could be: v=DMARC1; p=none.
Optional DMARC tags allow email senders to give more specific instructions on what to do with mail that does not authenticate.
The following optional tags have a default value that will be assumed if the tag is excluded:
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:
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.
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 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.”