What is DMARC?
DMARC (Domain-based Message Authentication, Reporting and Conformance) is a widely-accepted email authentication policy and reporting protocol that ensures — when implemented at an enforcement policy — that only authorized senders can send email using domain in the From: field of their email messages.
DMARC also includes a reporting mechanism: Email receivers can tell the domain about whether or not the email they received passed or failed authentication. The domain owner’s DMARC record can specify where and how often receivers should send reports. These reports let the domain owner or their DMARC vendor see who is using the domain to send email. Domain owners can use the information in these reports to fine-tune their email authentication policy to permit only trusted senders to send email on behalf of the domain.
Why do we need DMARC for email?
DMARC addresses shortcomings in the earlier email authentication protocols SPF and DKIM. The biggest issue for both is that they have nothing to say about the address that appears in the From field of an email message.
Neither SPF or DKIM authenticate the sender against the “From:” field that users see. The policy specified in a DMARC record can ensure that there is “alignment” (i.e. a match) between the visible From: address and either the DKIM key’s domain or the SPF verified sender
This prevents phishers from using a bogus domain in the “From:” address while signing the message with an unrelated domain that they control. This simple check provides an enormous amount of protection that never previously existed for email.
DMARC increases email deliverability, because without authentication, spammers can use an organization’s domain to send unwanted email, which will hurt the domain’s reputation among spam filters. With a DMARC record in place, spammers can’t “free ride” on a protected domain, so its reputation increases — improving deliverability. Valimail’s customers typically find the deliverability rates of their marketing messages increase by 10% or more after implementing DMARC.
What is DMARC Enforcement?
When your domain is configured for DMARC and set to an enforcement policy, email recipients will reject (block from delivery) or quarantine (move to a spam folder) any messages from senders not authorized by your enforcement policy.
The three policies that can be set in a DMARC record are p=none, p=quarantine, or p=reject. A none policy indicates no action will be taken on unauthenticated email messages. But, if the DMARC record includes a reporting address, the domain owner can use the data returned back from email receivers to understand who is sending email out using that domain. See “p=” (policy) below.
Learn more about DMARC policies and why DMARC enforcement is so important.
How Does DMARC Work?
For DMARC to work, the sending domain needs a DMARC record and the receiving server needs to check for that record and see if the sender is authorized. (DMARC records are stored as text records in the Domain Name System, or DNS.)
Fortunately, billions of email inboxes worldwide now accept the DMARC standard, including 100% of those hosted by major email service providers such as Google, Microsoft, Yahoo, and AOL. In all, 5.3 billion mailboxes worldwide — almost 80 percent of the global total — will enforce a DMARC policy if the sending domain has published one.
On the sending side, DMARC adoption is growing exponentially. Over 850,000 domains now publish a DMARC record, giving those domains visibility as well as the ability to protect themselves from phishing and email impersonation.
- Email is received for delivery.
- Receiver checks authentication of the message using both SPF and DKIM, by:
- checking the sending IP of the message against the SPF record and/or
- validating the message using the sender’s published DKIM key
- Receiver validates DMARC alignment for the message:
- if SPF authentication passed, and the domain checked matches the domain in the visible From, then DMARC passes and/or
- if DKIM authentication passed, and the domain checked matches the domain in the visible From, then DMARC passes
- Otherwise, DMARC fails
- If the email fails DMARC, receivers take action based on the policy specified in the domain owner’s DMARC record:
- do nothing
- send it to spam
- reject it (delete it)
- Once a day, receiver sends a report to DMARC domain owner listing the authentication status for all senders using that domain
What is a DMARC Record?
DMARC records are stored in the Domain Name System (DNS) for your domain. This makes them instantly accessible to any mail server on the Internet: As long as it has access to DNS, a system can retrieve the DMARC record for any domain and use it to determine if an email is authenticated or not.
A DMARC record is typically inserted as a TXT record alongside your other DNS records.
DMARC record example:
_dmarc.example.com IN TXT “v=DMARC1; p=none; rua=mailto:dmarc-rua@example.comDMARC Tags
Here’s an overview, in visual form, of all the DMARC tags available for use in a DMARC record.
It looks complicated, but we can easily boil it down to the essential DMARC tags you need:
- Only three tags are needed to effectively use DMARC (‘v=’, ‘p=’, and ‘rua=’)
- Only the ‘v=DMARC1’ tag is case sensitive
- Tags ‘v=’ and ‘p=’ must be set as the first and second position
- All other tags are optional and can be placed in any order
- Primary domain policies apply to subdomains unless a subdomain policy is explicitly defined
- You may have one and only one DMARC TXT record on a domain or subdomain; multiple records are treated as if there is no DMARC record at all.
Required DMARC Tags
In most cases, a well-formed DMARC record only needs to include three basic tags. Get these three tags right, and you’ll be able to take advantage of the visibility, control, and anti-phishing benefits that DMARC has to offer. The remaining DMARC tags you can ignore, unless you have specific needs. These are the essential ones:
“v=DMARC1” (DMARC version)
Identifier of a DMARC record. “I’m a DMARC record and you can use me to discover policy.”
“p=” (policy)
The “policy” tag tells the receiver what to do with a message that fails DMARC authentication. There are three values.
- “p=none” – receiver takes no action
- “p=quarantine” – receiver will treat the email as suspicious and send it to spam/junk folder
- “p=reject” – receiver rejects the email (does not deliver it)
Optional — but Recommended — DMARC Tags
“rua=mailto:address@company.com”
Tells the receiver where to send the DMARC Aggregate reports.
Aggregate reports provide most valuable information provided by DMARC. They contain daily summaries of all the senders worldwide using your domain, and their authentication status.
Note: In order to get DMARC’s visibility benefit, you must define a reporting address. A p=none record with no reporting is the same as no record at all.
Completely optional DMARC Tags
In most cases, a well-formed DMARC record only needs the three required tags mentioned above, plus the recommended rua tag. The remaining tags can be ignored in most cases, but can be helpful in some situations. Here’s what the optional DMARC tags do:
sp: defines the policy for subdomains
Subdomains will inherit the parent policy by default.
In general, you want your domains and subdomains to be covered by the same policy, so this tag isn’t needed unless you have subdomains that need different policies than the parent domain.
adkim: Indicates strict or relaxed DKIM identifier alignment.
The default is relaxed. With a relaxed policy, DMARC alignment will pass if the organizational domains in the visible From and what is authenticated by DKIM. With strict alignment, a message that authenticates as email.example.com would fail DMARC alignment if the visible From was @example.com instead of @email.example.com.
aspf: Indicates strict or relaxed SPF identifier alignment.
The default is relaxed. With a relaxed policy, DMARC alignment will pass if only the organizational domains in the visible From and what is authenticated by SPF match. With strict alignment, the subdomains also need to match: For example, a message that authenticates as email.example.com would fail DMARC alignment if the visible From was @example.com instead of @email.example.com.
pct: The percentage of messages to which the DMARC policy is to be applied.
The default value is 100 so all messages are subject to the policy.
Changing the percentage to anything less than 100 gives imposters the opportunity to bypass your specified policy. For instance, at 80 percent, you’ll have no control over which 80 percent of the messages will be subject to the policy.
ruf=mailto:address@company.com
Tells receivers where to send DMARC failure reports.
If not specified, receivers will not send forensic reports.
Failure reports, aka forensic reports, are generated each time a message fails authentication. They may include the full contents of the failing email, and therefore may include personally identifiable information (PII). Because of the risk of PII exposure, none of the major mailbox providers (e.g. Google, Microsoft, Yahoo, etc.) generate these reports anymore.
Fo
Failure reporting options: specifies which failed messages will trigger a failure report
By default, failure reports are generated if all underlying authentication mechanisms fail.
None of the major mailbox providers (e.g. Google, Microsoft, Yahoo, etc.) generate these reports.
rf
Format for message failure reports.
Currently, only one format is available: AFRF
None of the major mailbox providers (e.g. Google, Microsoft, Yahoo, etc.) generate these reports. And if an ruf address is specified, failure reports will be sent in the AFRF format.
ri
The number of seconds elapsed between sending aggregate reports.
The default value is 86400 seconds, which means reports are sent once per day.
Most receivers can’t support sending reports more than once a day so there is no need to change this value.
Using DMARC reports
DMARC provides global visibility into senders using your domain and their authentication status. It also allows domain owners to set a policy for what mail servers should do with unauthorized emails.
We recommend only using aggregate reports, which are XML documents that contain IP addresses, domain names and authentication information for emails that the receiver has seen sending as that domain. These XML reports can be thousands or hundreds of thousands of lines long depending on how many email messages are sent as that domain around the world. Aggregate reports contain no direct information about the service that sent the email (e.g. Salesforce, MailChimp, ADP), so it is up to the domain owner to figure this out for themselves.
Implementing Email Authentication with DMARC (and its challenges)
Working towards DMARC enforcement should be the end goal of any organization that sets a DMARC record in DNS. The journey to enforcement is a multi-step process that involves four main tasks:
- Set a DMARC record with a monitoring only policy of p=none. Make sure the record includes a reporting address to collect aggregate reports from all DMARC-compliant receiving domains. Mail receivers worldwide — such as Google, Microsoft, Yahoo! — support DMARC, and will send DMARC aggregate reports to the domain owners who have configured it.
- Collect and analyze the reports over time.
- Start cataloging email sending services that are sending email that fails authentication.
- Determine which sending services your organization supports, and get them authenticating.
Note that there are a number of challenges in implementing DMARC:.
- Identifying all sending services and incorporating them into the SPF record without exceeding the 10 DNS lookup limit.
- Discovering all unknown cloud sending services
- Updating SPF, DKIM and DNS
- Mitigating the risks of blocking good email
To understand these risks and how to solve them, read our Executive summary: The guaranteed path to DMARC enforcement.
DMARC Limitations
There is a small percentage of messages that will still fail authentication after being forwarded or passed through a mailing list. This problem is addressed by implementing the Authenticated Received Chain Protocol (ARC).
