Understanding DMARC Records and Their Components
A Domain-based Message Authentication, Reporting, and Conformance (DMARC) record is a DNS TXT record that allows domain administrators to specify how receiving mail servers should handle emails that fail SPF or DKIM checks. The record consists of a series of key-value pairs, known as tags, separated by semicolons.
The foundational tag of any DMARC record is the version tag, which must be the case-sensitive value v=DMARC1. This tag must appear first in the record. If this tag is missing, malformed, or placed elsewhere in the string, receiving mail servers will not recognize the record.
Analyzing these records before publishing them to your DNS zone ensures that mail receivers can parse your instructions correctly. A DMARC record must remain under 20,000 characters to be processed by this tool.
The Purpose and Impact of DMARC Policies
The core of a DMARC record is its policy tags, which dictate the actions a receiver should take when an email fails authentication. The primary policy tags are:
- Domain Policy (
p): The policy applied to the main domain. If noptag is present, the domain policy falls back tonone. - Subdomain Policy (
sp): The policy applied to subdomains. - Non-existent Subdomains Policy (
np): The policy applied specifically to non-existent subdomains.
These policies fall back in a hierarchical manner. When a more specific tag is absent, subdomain policies fall back from np to sp, and finally to p.
The three policy options behave as follows:
| Policy | Action and Impact |
|---|---|
none |
Requests reports but does not ask receivers to quarantine or reject failing mail. This is primarily used for monitoring. |
quarantine |
Asks receivers to treat failing emails as suspicious, typically delivering them to the spam or junk folder. |
reject |
Asks receivers to block failing emails entirely. |
During testing, the t=y tag can be used. This tag lowers the active policy's severity: a quarantine policy is lowered to none, and a reject policy is lowered to quarantine.
DMARC Alignment and Reporting Configurations
DMARC relies on identifier alignment to confirm that the domain in the "From" header matches the domains validated by SPF and DKIM. The tool reviews these alignment settings to show how strictly receivers will evaluate your messages.
Reporting is another critical component of DMARC, allowing domain owners to receive feedback on which servers are sending mail on their behalf.
- Aggregate Reports (
rua): These provide high-level XML reports containing statistical data about message volumes and authentication outcomes. If no validruaaddress is present, aggregate reports are not requested. - Failure Reports (
ruf): These provide detailed, redacted copies of individual messages that failed authentication. - Failure Options (
fo): This tag defines the conditions under which failure reports are generated. However, thefotag is ignored if no validruffailure-report address is present.
When configuring report URIs, some legacy records include a !size suffix to limit report sizes. This suffix is obsolete and should be ignored by current receiving systems.
Historic and Legacy DMARC Tags
As the DMARC standard has evolved, certain tags have been deprecated or designated as historic. While current receiving systems following the latest standard can ignore these tags, they often still appear in older DNS records.
- Legacy Percentage (
pct): Historically used to apply a policy to a specific percentage of messages. This tag is now considered historic and only limits policy coverage for receivers that still follow older DMARC specifications. - Historic Tags: Other tags such as
rfandriare also historic in the current DMARC standard. The tool identifies these tags to help you clean up and modernize your records.
Common Syntax Errors and Validation Rules
When parsing a DMARC record, several strict syntax rules apply. The tool evaluates the input against these rules and flags the following issues:
- Malformed Tags: Tags must be formatted as name-value pairs separated by semicolons.
- Duplicate Tags: A tag must not appear more than once in a single record.
- Empty Values: Every tag must have an associated value.
- Invalid Values: Values must conform to the allowed options for that specific tag.
- Invalid URIs: Reporting destinations in
ruaandrufmust be valid URIs. - Unregistered Tags: Any tag that is not registered in the DMARC specification will be flagged as unknown and ignored by receivers.
If you paste quoted DNS TXT chunks, the tool automatically joins them together before performing the analysis.
Local Browser Processing and Privacy
This tool processes your DMARC record entirely within your browser. The input is not uploaded to any external servers, is not saved, and is not written to browser storage. No network requests related to your record are sent out.
Frequently Asked Questions
What counts as a DMARC policy gap?
A p=none policy only monitors failures, while t=y asks receivers to apply a less strict policy during testing. Missing p is treated as none. Subdomain policies fall back from np to sp to p when a more specific tag is absent.
Why are pct, rf and ri marked as historic?
The current DMARC standard replaced or removed those tags. This checker still parses them to help review older records, but receiving systems following the current standard can ignore them.
Does a clean result prove that my DMARC setup works?
No. This page checks only the text you paste. It does not query DNS, verify where the record is published, test SPF or DKIM, or confirm that external report destinations authorize your domain.