DMARC, which stands for Domain-based Message Authentication, Reporting, and Conformance, is a DNS TXT record that can be published for a domain to control what happens if a message fails authentication (i.e., the recipient server can't verify that the message's sender is who they say they are). A published DMARC record basically serves two purposes:
- Tells the recipient server to either: Quarantine the message, Reject the message, or Allow the message to continue delivery
- Sends reports to an email address or addresses with data about all the messages seen from the domain
Those two benefits alone drive home the huge value of setting up DMARC! Once published, a DMARC record is used by receiving mail servers (think Gmail or Yahoo! Mail) to determine what to do with a failed message. The receiving mail server at Gmail looks at the DMARC record for the policy to follow from the following choices:
- Do nothing to the message
- Quarantine the message
- Reject the message
Action is taken by the recipient mail server on one of those three options above if the domain has published a DMARC record. If the domain has not published a DMARC record, the recipient server makes its own determination if the message should be delivered. With phishing, malware threats, and a variety of other security concerns, the direct value of being able to tell recipient mail servers to quarantine or reject messages that fail DMARC has now become the gold standard for sending legitimate email by blocking fraudsters.
Sample DMARC Record Explained
A DMARC record is essentially made up of a specified Host/Name (i.e., the record name - for example: _dmarc.mxtoolbox.com is the Host/Name for MxToolbox) and tag-value pairs. Tag-value pairs are pretty much what they sound like. You have a tag (e.g., policy is represented by "p=") and a value, such as "none", which are paired to tell the receiving mail server what actions to take.
You can see this by looking at the following example record, which contains three tag-value pairs:
- "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"
The three tags are: v, p, and rua; the three values are: DMARC1, none, and mailto:dmarc@yourdomain.com. The "v" tag is the version of DMARC, the "p" tag is the policy (meaning what action to take if the message fails DMARC), and the "rua" tag is the email address to send DMARC aggregate reports to. Below is an example of how a correctly formatted DMARC record should look when published at a DNS Host:
There is a total of 11 tags that can be applied to a DMARC policy. Of those 11, the "v" and "p" tags are required, and we also strongly recommend the "rua" tag in order to receive the reports. Below is a full list of tags that can be added to a DMARC record.
| Tag | Description | |
|---|---|---|
| Version (v) | The v tag is required and represents the protocol version. An example is v=DMARC1 |  More Info |
| Policy (p) | The required p tag demonstrates the policy for domain (or requested handling policy). It directs the receiver to report, quarantine, or reject emails that fail authentication checks. Policy options are: 1) None 2) Quarantine or 3) Reject. | More Info |
| Percentage (pct) | This DMARC tag specifies the percentage of email messages subjected to filtering. For example, pct=25 means a quarter of your company’s emails will be filtered by the recipient. | More Info |
| RUA Report Email Address(es) (rua): | This optional tag is designed for reporting URI(s) for aggregate data. An rua example is rua=mailto:CUSTOMER@for.example.com | More Info |
| RUF Report Email Address(es) (ruf) | Like the rua tag, the ruf designation is an optional tag. It directs addresses to which message-specific forensic information is to be reported (i.e., comma-separated plain-text list of URIs). An ruf example is ruf=mailto:CUSTOMER@for.example.com | More Info |
| Forensic Reporting Options (fo) | The fo tag pertains to how forensic reports are created and presented to DMARC users. | More Info |
| ASPF Tag (aspf) | The aspf tag represents alignment mode for SPF. An optional tag, aspf=r is a common example of its configuration. | More Info |
| ADKIM Tag (adkim) | Similar to aspf, the optional adkim tag is the alignment mode for the DKIM protocol. A sample tag is adkim=r | More Info |
| Report Format (rf) | Forensic reporting format(s) is declared by the DMARC rf tag. | More Info |
| Report Interval (ri) | The ri tag corresponds to the aggregate reporting interval and provides DMARC feedback for the outlined criteria. | More Info |
| Subdomain Policy (sp) | This tag represents the requested handling policy for subdomains. | More Info |
