What is DMARC?
DMARC (Domain-based Message Authentication, Reporting & Conformance) is an email authentication protocol that checks whether an SPF- or DKIM-authenticated domain aligns with the domain in a message's From address. A domain owner can publish a requested handling preference for messages that fail DMARC validation and request aggregate or message-specific failure reports.
Why DMARC is essential
SPF and DKIM authenticate sending identifiers. On their own, they do not check whether an authenticated identifier aligns with the domain in the From address or state the domain owner's handling preference for failed messages.
DMARC solves this by:
- Stating a handling preference: None, quarantine, or reject for messages that fail DMARC
- Checking alignment: At least one authenticated SPF or DKIM identifier must align with the From domain
- Requesting reports: Aggregate and message-specific failure reports provide insight into observed authentication results
How DMARC works
1. Sender publishes DMARC policy in DNS (TXT record at _dmarc.domain.com)
2. Email is sent with From: [email protected]
3. Receiver checks SPF and DKIM
4. Receiver checks alignment: Does authenticated domain match From header?
5. Handling decision: The receiver considers the requested policy and other signals
6. Reports may be sent: Participating receivers may send requested aggregate or message-specific failure reports
DMARC alignment
DMARC requires alignment: the domain in the From header must align with at least one authenticated identifier under the record's relaxed or strict mode:
- SPF alignment: The SPF-validated MAIL FROM domain, or the HELO domain when MAIL FROM is null
- DKIM alignment: The d= domain in a valid DKIM signature
Without alignment, SPF or DKIM can pass while DMARC fails. DMARC directly addresses specific forms of spoofing that use the exact From domain. It does not detect visually similar domains or misuse of the sender's display name.
DMARC record format
DMARC records are TXT records at _dmarc.yourdomain.com:
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"
DMARC tags
| Tag | Required | Description | Example |
|---|---|---|---|
| v | Yes | Version | v=DMARC1 |
| p | Recommended (optional) | Requested handling preference for mail that fails DMARC validation | p=none/quarantine/reject |
| rua | No | Aggregate report URI | rua=mailto:[email protected] |
| ruf | No | Message-specific failure report URI | ruf=mailto:[email protected] |
| t | No | Policy test mode | t=y or t=n |
| sp | No | Requested policy for existing subdomains | sp=reject |
| np | No | Requested policy for non-existent subdomains | np=reject |
| adkim | No | DKIM alignment mode | adkim=s (strict) or adkim=r (relaxed) |
| aspf | No | SPF alignment mode | aspf=s or aspf=r |
The pct tag is historic. The current DMARC standard no longer uses it to apply a policy to a percentage of failing messages. The p tag is recommended but optional; an otherwise valid record without it is treated as p=none.
DMARC policies
p=none: Express no handling preference for failed messages. Domain owners commonly use it while reviewing reports.v=DMARC1; p=none; rua=mailto:[email protected]
p=quarantine: Request that receivers treat DMARC-failing messages as suspicious.
v=DMARC1; p=quarantine; rua=mailto:[email protected]
p=reject: Request that receivers reject DMARC-failing messages. Receivers consider this preference with other signals, so it does not guarantee rejection.
v=DMARC1; p=reject; rua=mailto:[email protected]
DMARC implementation path
Phase 1: Monitor (p=none)
Start with monitoring to understand your email ecosystem:
v=DMARC1; p=none; rua=mailto:[email protected]
Analyze reports to identify:
- Legitimate sending services missing SPF/DKIM
- Unauthorized senders (spoofing)
- Alignment issues
Phase 2: Quarantine (p=quarantine)
Once legitimate sources are authenticated:
v=DMARC1; p=quarantine; rua=mailto:[email protected]
Review reports and confirm legitimate mail is authenticated before choosing a stricter policy. The current DMARC standard does not define a percentage rollout.
Phase 3: Reject (p=reject)
Request rejection for DMARC-failing messages:
v=DMARC1; p=reject; rua=mailto:[email protected]
DMARC reports
Aggregate reports (rua)
Receivers are recommended to send aggregate XML reports daily or more often. Reports summarize observed message streams, so availability and coverage depend on the reporting receivers:
- Volume of email
- Pass/fail rates for SPF, DKIM, DMARC
- Sending IP addresses
- Recipient organizations
Failure reports (ruf)
Message-specific reports may include message headers or content. Not all receivers send them, often because of privacy concerns:
- Authentication failure details
Report processing
Aggregate DMARC reports are XML and can be hard to read. Use services like:
- DMARC Analyzer
- Dmarcian
- Valimail
- Postmark DMARC
Checking DMARC
The authenticated DomScan Email Authentication API costs 3 credits per domain and returns the DMARC record and parsed tags.
dig _dmarc.example.com TXT
curl -H "X-API-Key: $DOMSCAN_API_KEY" "https://domscan.net/v1/email-auth?domain=example.com"
# Check dmarc.record and dmarc.tags in the JSON response
Common DMARC issues
No reports received: Ensure rua address can receive large emails; some providers filter. Legitimate email failing: Check SPF/DKIM configuration for all sending services; verify alignment. Third-party services failing: Many services require custom DKIM setup for DMARC alignment.DMARC adds alignment, a requested handling preference, and reporting to SPF and DKIM. Review your sending sources and reports before requesting stricter handling.