What is Domain-based Message Authentication, Reporting and Conformance (DMARC)?
The Domain-based Message Authentication, Reporting and Conformance (DMARC) protocol is one leg of the tripod of internet protocols that support email authentication methods. DMARC provides a mechanism for mail-sending organizations to advertise guidelines for mail-receiving organizations on how to handle inbound email that has failed the sender's email validation processes. DMARC authentication techniques help servers receiving email to improve their email security by differentiating legitimate email from fraudulent email, such as business email compromise and phishing emails.
Along with DomainKeys Identified Mail (DKIM) and Sender Policy Framework (SPF), DMARC helps email service providers, enterprises and other email-sending entities to validate email. Validation and authentication with SPF and DKIM help prevent email domains from being hijacked and used for phishing scams, email spoofing and other email-based attacks.
DMARC policies are published by the domain owner in the domain name system, and those records are accessible to any email recipient through DNS queries.
DMARC is an email authentication protocol, specified in RFC 7489: Domain-based Message Authentication, Reporting and Conformance (DMARC). The protocol details how organizations sending email can publish their policy preferences regarding what email receivers should do when a message is deemed suspicious based on the following:
- Source of email. The SPF protocol enables mail-sending organizations to identify email servers authorized to originate email for the organization's domain.
- Authentication of email messages. The DKIM protocol enables mail senders to add a cryptographic signature to the header of email messages. The DKIM signature links the holder of the public key to the message and provides a level of assurance that the message is not being spoofed.
Implementing DMARC is done by publishing policies in a DNS TXT record. Email receivers can then query DNS to retrieve the DMARC DNS TXT record associated with the domain protected by DMARC. That query returns the DMARC policies set by the sender and enables the recipient to take the actions desired by the sender.
How does DMARC work?
A DMARC DNS record is a domain name record that mail-originating organizations use to publish their policies regarding how to respond to unauthenticated email sent from domains owned by the organization. DMARC records are used in conjunction with SPF and DKIM to specify the actions a receiver should take when the following occurs:
- An email is received from a domain, IP address or server not listed by the sending domain owner's SPF record.
- An email is received that cannot be authenticated using the sending domain's public key published in its DKIM record.
SPF enables the organization to specify which IP addresses are linked with authorized email servers. DKIM enables mail-originating organizations to attach cryptographic signatures to email headers. Mail-receiving organizations can authenticate these signatures with the sending organization's public key.
What are DMARC policies?
DMARC policies determine the next action for the receiving email server. Valid policies include the following:
- None. No action is necessary. This policy enables the sending server to log information about how often the policy was invoked. This policy is usually used for testing.
- Quarantine. The message may be suspicious, and the message should be delivered but routed to an appropriate folder -- e.g., the recipient's junk or spam folder.
- Reject. The message must not be delivered.
Typically, implementers start by setting their policies for failed messages to none and testing to make sure their DMARC records are working properly. If testing shows that few legitimate messages will fail to authenticate, the policy can be set to quarantine. Typically, if testing and monitoring of the DMARC function continues to show a low false-positive rate, the policy can be set to reject.
What is a DMARC record?
A DMARC record is the DNS TXT record that contains DMARC policies. DMARC record names take the following form:
_dmarc.example.com
The prefix _dmarc. is added to the domain or subdomain in the DNS record.
The record itself usually consists of one or more lines with at least two tags or parameters. The DMARC protocol version and DMARC policy tags are required; other tags are optional.
The table below shows the original set of DMARC tags, as defined by the Internet Engineering Task Force DMARC working group on the website DMARC.org.
| Tag | Required? | Tag name and purpose | Example |
| adkim |
OPTIONAL |
DKIM alignment indicates whether the DKIM authenticating domain must be an exact match with the sending domain or whether a subdomain can be accepted. Valid values are r (for relaxed) and s (for strict). |
adkim=r |
| aspf |
OPTIONAL |
SPF alignment indicates whether the SPF authenticated domains must be strictly matched or whether subdomains can be accepted. Valid values are r (for relaxed) and s (for strict). |
aspf=s |
| p |
REQUIRED |
Policy specifies the policy for handling email from the domain if it fails authentication. Valid values are none, quarantine and reject. |
p=reject |
| pct |
OPTIONAL |
Percentage of messages received from the sending domain that the DMARC policies should be applied to. Applying policies to less than 100% of email received from a domain means the sending domain administrators can gradually roll out the use of DMARC policies. |
pct=20 |
| rf |
OPTIONAL |
Report format for forensic reports that are sent out after a message fails. Two current options are AFRF (Authentication Failure Reporting Using the Abuse Reporting Format) and IODEF (Incident Object Description Exchange Format), which are two message format standards for sending forensic abuse or incident information. |
rf=afrf |
| ri |
OPTIONAL |
Report interval sets the time frame for aggregate reporting. This value is a 32-bit integer representing the number of seconds between reports. The default value is 86400, or 24 hours. |
ri=86400 |
| rua |
OPTIONAL |
Reporting URIs for aggregate reports lists Uniform Resource Identifiers that contain the email addresses to which aggregate reports are to be sent. Aggregate reporting is turned on when this tag is included in the DMARC record. |
rua=mailto:[email protected] |
| ruf |
OPTIONAL |
Reporting URIs for forensic reports lists URIs that contain the email addresses to which forensic reports are to be sent. Forensic reporting is turned on when this tag is included in the DMARC record. |
rua=mailto:[email protected] |
| sp |
OPTIONAL |
Subdomain policy specifies the DMARC policy for mail received from subdomains. The format and options for this tag are the same as for the p tag. |
p=quarantine |
| v |
REQUIRED |
Protocol version identifies the version of DMARC in use. The current version is DMARC1. |
v=DMARC1 |
This is an example of a DMARC record:
v=DMARC1; p=quarantine; rua=mailto:[email protected]
The first tag in this example, v=DMARC1, identifies the DMARC record as complying with DMARC version 1 protocol.
The second tag in this example, p=quarantine, specifies the DMARC policy of quarantining messages that fail to authenticate.
The final tag in this example, rua=mailto:[email protected], indicates that aggregate reports are to be sent to the email address in the included URI. The URI is used in DMARC records instead of a raw email address.
Since no reporting interval is set in this example, email receivers are expected to submit reports every 24 hours to the domain owner's specified address.
What is a DMARC check?
When an email message fails to authenticate as coming from an SPF-listed source or when the message header DKIM signature fails to authenticate, the email receiver must do a DMARC check to determine how to respond.
The DMARC check involves retrieving the DMARC DNS TXT record and reviewing policies listed for the email sender. Many organizations roll out implementations of DKIM and SPF gradually, so in the early stages, the sending organization may not actually require that it be notified when individual emails fail to authenticate.
What is a DMARC report?
DMARC participation may require email receivers to generate forensic reports on individual emails that fail DKIM and SPF authentication, as well as aggregate reports, sent periodically by receivers to the domain owner to summarize all email sent from that domain.
DMARC forensic reports
Forensic reports contain information about how the message failed and about the message itself. This includes the following:
- how the message failed authentication;
- the sender's IP address; and
- the email addresses in the To: and From: headers.
Forensic reports are requested in the DMARC DNS TXT record, using the tag rua along with one or more URIs that contain email addresses to which the reports should be sent. To request forensic reports from email receivers, the ruf tag in a DMARC record would look similar to this:
ruf=mailto:[email protected]
At least one URI is required, but the tag can include a comma-separated list of multiple email URIs.
DMARC aggregate reports
Aggregate reports include information about the entity that originated the email, including the domain and contact information, the domain under which the policy was published and the time period covered by the report. Aggregate reports include information about messages that failed SPF and DKIM authentication:
- source IP address for the failed message;
- the domain from which the email originated, taken from the email From: header;
- the policy or policies that were applied because of the failure; and
- whether the message failed authenticating with SPF, DKIM or both.
To support DMARC, email receivers must be able to generate daily aggregate reports and should be able to generate the reports hourly.
When an email sender adds the rua tag to its DMARC records, it means all receiving email servers are requested to send aggregate reports to the senders.
The URI is used instead of a raw email address, which is not permitted. To request aggregate reports from email receivers, the rua tag in a DMARC record would look like this:
rua=mailto:[email protected]
At least one URI is required, but the tag can include a comma-separated list of multiple email URIs.
Benefits of DMARC
DMARC, in conjunction with SPF and DKIM, provides the following benefits:
- enables email senders and receivers to identify, authenticate and report potentially malicious email;
- reduces flow of malicious email that spammers and other attackers use to distribute spam, malware and phishing messages; and
- provides protection in real time to help reduce impact on email deliverability when active attacks are being carried out.
DMARC, SPF and DKIM provide an excellent foundation for protecting against attacks on the email channel. Find out about some of the other important email security protocols.
