Table of Contents
DMARC (Domain-based Message Authentication, Reporting and Conformance)
DMARC (Domain-based Message Authentication, Reporting and Conformance) is an email authentication standard that builds on SPF and DKIM.
DMARC allows a domain owner to:
- Tell receiving mail servers how to handle messages that fail authentication.
- Receive reports about emails claiming to come from the domain.
- Protect the domain against email spoofing and phishing.
Why Is DMARC Needed?
SPF and DKIM each solve part of the authentication problem.
However, without DMARC:
- Receiving servers decide for themselves how to treat authentication failures.
- Domain owners receive no visibility into spoofing attempts.
DMARC provides a consistent policy that tells receivers what action to take.
How DMARC Works
When an email arrives:
- The receiving server performs an SPF check.
- The receiving server performs a DKIM check.
- It verifies whether either authentication method is aligned with the visible From: domain.
- It reads the domain's DMARC DNS record.
- It follows the policy published by the domain owner.
Simplified Process
Incoming Email ↓ SPF Check ↓ DKIM Check ↓ Alignment Check ↓ Read DMARC Policy ↓ Accept / Quarantine / Reject
DMARC DNS Record
DMARC is published as a DNS TXT record.
Example:
_dmarc.example.com
Example record:
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
DMARC Policies
The most important DMARC setting is the policy (p).
| Policy | Meaning |
|---|---|
| none | Monitor only |
| quarantine | Treat suspicious messages as spam |
| reject | Reject unauthorized messages |
Example Policies
Monitoring only:
v=DMARC1; p=none
Quarantine suspicious mail:
v=DMARC1; p=quarantine
Reject spoofed mail:
v=DMARC1; p=reject
DMARC Alignment
DMARC requires domain alignment.
The domain used by SPF or DKIM must match the domain visible in the From: header.
Example:
From: support@example.com
If SPF authenticates:
mailer.example.com
the domains are aligned.
If SPF authenticates:
mailer.otherdomain.com
alignment fails.
DMARC Reports
DMARC supports two types of reports.
Aggregate Reports (RUA)
Sent periodically.
They summarize:
- Authentication results
- Sending IP addresses
- Message counts
Example:
rua=mailto:dmarc@example.com
Failure Reports (RUF)
Sent when individual messages fail authentication.
Example:
ruf=mailto:dmarc@example.com
Not all providers send failure reports.
Common DMARC Tags
| Tag | Purpose |
|---|---|
| v | Version |
| p | Policy |
| rua | Aggregate report address |
| ruf | Failure report address |
| pct | Percentage of messages to which the policy applies |
| adkim | DKIM alignment mode |
| aspf | SPF alignment mode |
DMARC Deployment Strategy
A common deployment process is:
- Start with p=none
- Review DMARC reports
- Fix SPF and DKIM issues
- Change to p=quarantine
- Eventually use p=reject
This minimizes the risk of rejecting legitimate email.
DMARC and Telenegar
The Telenegar Mail Check service can verify:
- Whether a DMARC record exists
- DMARC syntax
- Published policy
- Report destinations
- Alignment settings
- Common configuration errors
This helps improve both email security and deliverability.
SPF, DKIM and DMARC
These standards work together.
SPF ↓ "Was the sending server authorized?" DKIM ↓ "Was the message modified?" DMARC ↓ "What should the receiver do if SPF or DKIM fails?"
Common Misconceptions
- DMARC replaces SPF and DKIM.
- False. DMARC depends on SPF and DKIM.
- DMARC encrypts email.
- False. DMARC is an authentication policy.
- Using p=reject should be the first step.
- False. It is usually better to begin with p=none and review reports first.
Best Practices
- Publish SPF, DKIM and DMARC together.
- Begin with p=none.
- Monitor aggregate reports.
- Fix authentication problems before enforcing stricter policies.
- Move to p=quarantine and finally p=reject when ready.