If you’ve spent any time in the email space, you’ve likely seen the word DMARC tossed around. What is DMARC? How does DMARC work, and is it something you should be concerned about?
We’ve got you covered. Below, we’ll walk you through everything you need to know about DMARC, including what it is, how it works, and why you need it:
- What is DMARC?
- Why do you need DMARC for email?
- What is DMARC enforcement?
- How does DMARC work?
- What is a DMARC record?
- How to use DMARC reports
- Implementing email authentication with DMARC (and its challenges)
- DMARC limitations
- Get started with DMARC
What is DMARC?
Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a widely-accepted email authentication policy and reporting protocol. It ensures – when implemented at an enforcement policy – that authorized use of the domain in the From: field can be verified by the receiving domain and action can be taken if the use is not authorized.
DMARC includes a reporting mechanism. Email receivers tell the domain whether or not the email they received passed or failed authentication. The domain owner’s DMARC record can specify where 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 you 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 in the From field of an email message.
Neither SPF nor DKIM authenticates the sender against the “From:” field that users see. The policy specified in a DMARC record ensures “alignment” between the visible From: address and the DKIM signing domain or the SPF-verified sender, meaning that they’re identical or at least part of the same DNS namespace.
This prevents phishers from using a false domain in the “From:” address while signing the message with an unrelated domain they control. This simple check provides an enormous amount of protection that never previously existed for email.
With a DMARC record in place, spammers can’t “free ride” on a protected domain. As your reputation as a legitimate sender increases, your deliverability could improve as well.
What is DMARC enforcement?
When your domain is configured for DMARC and set to an enforcement policy, email recipients will be aware of your domain’s wishes to have any unauthorized messages rejected (blocked from delivery) or quarantined (moved to a spam folder), and will use that information when making message disposition decisions.
The three policies that can be set in a DMARC record are:
- p=none
- p=quarantine
- p=reject
A none policy indicates that the domain owner wishes no specific action to be taken on unauthenticated email messages. But, if the DMARC record includes a reporting address, the domain owner can use the data returned from email receivers to understand who is sending the email using that domain.
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. 5.3 billion mailboxes worldwide—almost 80% 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 and the ability to protect themselves from phishing and email impersonation.
Here’s the step-by-step process for how DMARC works:
- Email is received for delivery.
- The receiver checks for an existing DMARC policy for the From: domain of the message.
- The receiver checks the 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
- The receiver validates DMARC alignment for the message:
- If SPF authentication passes, and the domain checked aligns with the domain in the visible From, then DMARC passes and/or
- If DKIM authentication passes, and the domain checked aligns with 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, the receiver sends a report to the DMARC domain owner listing the authentication status for all senders using that domain.
What is a DMARC record?
DMARC records are stored in your domain’s Domain Name System (DNS). This makes them instantly accessible to any mail server on the Internet.
A DMARC record is inserted as a TXT record alongside your other DNS records, with a name beginning with “_dmarc” followed by the domain to which the policy applies. For example, the DMARC record for “example.com” would be published at “_dmarc.example.com”.
DMARC record example:
_dmarc.example.com IN TXT “v=DMARC1; p=none; rua=mailto:dmarc-rua@example.comDMARC tags
Here’s an overview of all the DMARC tags available 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 required in order 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:
- v
- p
- rua
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:
1. “v=DMARC1” (DMARC version)
Identifier of a DMARC record. “I’m a DMARC record, and you can use me to discover policy.”
2. “p=” (policy)
The “policy” tag indicates the domain owner’s preference for handling a message that fails DMARC authentication. There are three values.
- “p=none” – receiver takes no action
- “p=quarantine” – the domain owner wishes the message to be treated as suspicious and delivered to the spam/junk folder.
- “p=reject” – the domain owner wishes the message to be rejected.
Optional — but recommended — DMARC tags
3. “rua=mailto:address@company.com”
Tells the receiver where to send the DMARC Aggregate reports.
Aggregate reports provide the most valuable information provided by DMARC. They contain daily summaries of all the senders worldwide using your domain and their authentication status.
Note: 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. The remaining tags can be ignored in most cases but can be helpful in some situations:
- sp
- adkim
- aspf
- pct
- fo
- rf
- ri
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: Percentage of messages to which the DMARC policy is to be applied
The default value for DMARC PCT is 100, so all messages are subject to the policy.
Changing the percentage to anything less than 100 allows imposters 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 failure reports.
Failure 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. If a 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.
How to use DMARC reports
DMARC provides global visibility into senders using your domain and their authentication status. It also allows domain owners to express a preference for what mail servers should do with unauthorized emails.
We recommend only using aggregate reports, which are XML documents containing IP addresses, domain names, and authentication information for emails 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 using 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. Ensure the record includes a reporting address to collect aggregate reports from all DMARC-compliant receiving domains. Mail receivers worldwide—such as Google, Microsoft, and 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 authenticated.
Note that there are several 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
DMARC limitations
A small percentage of messages will still fail authentication after being forwarded or passed through a mailing list. This problem is addressed by the forwarding server or the mailing list server implementing the Authenticated Received Chain Protocol (ARC).
Get started with DMARC
Ready to take care of all your DMARC needs? Get started with Valimail. We’ll automate your DMARC records to enforcement without any DNS updates.
Create a free account to start monitoring your DMARC visibility.
