Domain-based Message Authentication, Reporting and Conformance (DMARC)
Internet Security, Internet Standard. A domain-based policy for determining the authenticity of the person or service sending email on behalf of a domain. RFC 7489 defines this standard.
To minimize email spoofing, DMARC builds on top of existing authentication standards.
As DomainKeys Identified Mail (DKIM) and Sender Policy Framework (SPF) can't provide complete spoofing prevention, DMARC supplements them. DKIM and SPF handle the domain-based message authentication portion of DMARC.
- To verify the authenticity of the email message, DKIM cryptographically signs them.
- To verify the domain authorized the IP address that sent the email, SPF defines and maintains the IP addresses approved to send email on a domain.
To implement DMARC, you add a TXT DNS record to your domain. The policy consists of a list of tags.
The tags in this TXT record tell receiving email servers how to handle email that fails either or both DKIM and SPF checks. The DMARC record also tells receiving servers where to send reports about the failures. The ability to provide receiving email servers with failure handling instructions and the opportunity to receive failure reports is incredibly valuable for domain owners. The information can be used to track down the people and services sending email on behalf of your domain, which is a first step in understanding your sender reputation. This feedback loop is unique to the reporting and conformance mechanisms of DMARC.
An DMARC record resides as the value of a DNS TXT record that resemble the following:
v=DMARC1; p=(none|quarantine|reject); rua=mailto:<email address>;
The TXT record value must adhere to the following standards:
- It must follow RFC 1035 3.3.14 format for DNS records.
- It can't exceed 512 bytes.
- All DMARC record values start with
v=DMARC1;. This means that the value is an DMARC version 1 policy record. - The tag covers the policy applied to emails that fail the DMARC check.
| Tag | Meaning | Value | Accepted values | Default value |
|---|---|---|---|---|
v | DMARC protocol version | DMARC1 | DMARC1 | |
p | Policy for DMARC check failures | The policy to apply to emails that fail the DMARC check. To collect DMARC reports, set to none. | none, quarantine, reject | |
rua | Recipients of aggregate reports | A list of URIs expressed as email URIs of email service providers who should receive aggregate reports expressed as email URIs. | mailto URIs | |
ruf | Recipients of forensic reports | A list of URIs expressed as email URIs of ISPs who should receive forensic reports | mailto URIs | |
sp | Policy for | The policy to apply to email from a subdomain of this domain that fail the DMARC check. As a domain owner, use this tag to publish a wildcard policy for all subdomains. | ||
fo | Reason to generate forensic report | If both DKIM and SPF fail: 0If either DKIM or SPF fail, 1If only DKIM fail, dIf only SPF fail: s | 0, 1, d, s | |
rf | Forensic report format | Reporting format for forensic reports. | ||
pct | Percentage of failing emails | What percentage of failing email messages an ISPs should apply the DMARC policy. Requires p=q or p=r policy. | Integer from 0 to 100 | |
adkim | Alignment mode for DKIM signatures | Relaxed (r) mode passes authenticated DKIM signing domains (d=) that share an Organizational Domain with an emails From domain. Strict (s`) mode requires an exact match. | r, s | |
aspf | Alignment mode for SPF | Relaxed (r) mode passes authenticated SPF domains that share an Organizational Domain with an emails From domain. Strict (s`) mode requires an exact match. | r, s | |
ri | Reporting interval | How often aggregate XML reports should be sent. | Daily |
You can write out this policy or use a DMARC policy generator.