What is DMARC?
Domain-based Message Authentication, Reporting and Conformance (DMARC) ties SPF and DKIM together, telling receiving servers what to do when authentication fails and giving you visibility into who is sending email as your domain.
What is DMARC?
DMARC (Domain-based Message Authentication, Reporting and Conformance) is an email authentication protocol that builds on top of SPF and DKIM. It solves two problems that SPF and DKIM alone cannot: it tells receiving servers what to do when authentication fails, and it gives domain owners reports on who is sending email using their domain.
Without DMARC, a receiving server that sees an SPF or DKIM failure has no guidance from the domain owner. It might deliver the message, quarantine it, or reject it — the decision is entirely up to the receiver. DMARC lets you publish a policy that says "if my emails fail authentication, here's what I want you to do."
DMARC is defined in RFC 7489 and has become a requirement for bulk email senders at Google, Yahoo, and Microsoft. It is the third pillar of email authentication, alongside SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail).
Why DMARC matters
Stops domain spoofing
DMARC prevents attackers from sending phishing emails that appear to come from your domain. With a reject policy, spoofed emails never reach recipients.
Provides visibility
DMARC reporting shows you every server sending email as your domain. You'll discover unauthorized senders, misconfigured services, and forwarding issues.
Ties SPF and DKIM together
SPF and DKIM work independently. DMARC bridges the gap by requiring that at least one of them aligns with the visible "From:" address recipients see.
Required for deliverability
Google, Yahoo, and Microsoft now require DMARC for bulk senders. Without it, your emails are more likely to land in spam or be rejected.
How DMARC works
Here's what happens when an email is received and evaluated against DMARC:
Receiver looks up the DMARC record
When an email arrives, the receiving server extracts the domain from the "From:" header and queries DNS for a TXT record at _dmarc.example.com.
SPF and DKIM are checked
The server runs standard SPF and DKIM checks on the email. DMARC doesn't replace these — it uses their results.
Alignment is evaluated
DMARC checks that the domain that passed SPF or DKIM aligns with the "From:" domain. At least one must align for DMARC to pass.
Policy is applied
If DMARC fails (no aligned pass), the receiver applies the domain's DMARC policy: none (monitor), quarantine (spam folder), or reject (block).
Reports are sent
The receiver generates an aggregate report about all emails it received from that domain and sends it to the address specified in the DMARC record's rua tag.
SPF and DKIM alignment
Alignment is the core concept that makes DMARC work. It ensures that the domain authenticated by SPF or DKIM matches the domain in the visible "From:" header.
How SPF alignment works
SPF authenticates the Return-Path (envelope sender) domain. For SPF alignment,
the Return-Path domain must match the "From:" header domain. For example, if
the "From:" header says [email protected], the Return-Path must also
be under example.com.
How DKIM alignment works
DKIM authenticates the signing domain (the d= tag in the DKIM-Signature header).
For DKIM alignment, this signing domain must match the "From:" header domain.
Relaxed vs. strict alignment
| Mode | DMARC tag | What matches | Example |
|---|---|---|---|
| Relaxed (default) | aspf=r / adkim=r |
Organizational domain match (parent domain) | mail.example.com aligns with example.com |
| Strict | aspf=s / adkim=s |
Exact domain match only | mail.example.com does not align with example.com |
DMARC policies explained
The p tag in your DMARC record tells receivers what to do when an
email fails DMARC authentication. There are three policy levels:
Take no action on failing emails. Deliver them normally. Use this during initial deployment to collect reports and understand your email ecosystem before enforcing.
Treat failing emails as suspicious. Typically moves them to the spam or junk folder. A good intermediate step before full enforcement.
Block failing emails entirely. The strongest protection — spoofed emails are never delivered. This is the ultimate goal for every domain.
The pct tag: gradual rollout
The pct tag lets you apply your DMARC policy to only a percentage
of failing emails. This is useful for gradually increasing enforcement without
risking a sudden disruption to legitimate email.
v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]
This record says: "Quarantine 25% of failing emails; let the other 75% through."
You can increase pct over time (25 → 50 → 75 → 100) as you
gain confidence.
Subdomain policy (sp)
The sp tag sets a separate policy for subdomains. If omitted, subdomains
inherit the parent domain's p policy. This is useful when you want to
reject spoofed email from subdomains you don't use for sending.
v=DMARC1; p=quarantine; sp=reject; rua=mailto:[email protected]
DMARC record format
A DMARC record is a DNS TXT record published at _dmarc.example.com.
It contains your policy, reporting addresses, and alignment preferences.
Example DMARC record
v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=r; aspf=r; pct=100
| Tag | Required? | What it means | Example |
|---|---|---|---|
v |
Required | Version (must be DMARC1) |
v=DMARC1 |
p |
Required | Policy for the domain: none, quarantine, or reject |
p=reject |
sp |
Optional | Policy for subdomains. Defaults to the p value if omitted. |
sp=reject |
rua |
Optional | Address for aggregate reports (daily XML summaries). Highly recommended. | rua=mailto:[email protected] |
ruf |
Optional | Address for forensic (failure) reports. Sent per-failure. Not widely supported. | ruf=mailto:[email protected] |
adkim |
Optional | DKIM alignment mode: r (relaxed, default) or s (strict) |
adkim=r |
aspf |
Optional | SPF alignment mode: r (relaxed, default) or s (strict) |
aspf=r |
pct |
Optional | Percentage of failing messages the policy applies to (1–100, default 100) | pct=50 |
fo |
Optional | Failure reporting options: 0 (both fail), 1 (either fails), d (DKIM fails), s (SPF fails) |
fo=1 |
ri |
Optional | Reporting interval in seconds (default 86400 = 24 hours) | ri=86400 |
DMARC reporting
One of DMARC's most valuable features is reporting. It gives you visibility into every server sending email that claims to be from your domain.
Aggregate reports (rua)
Aggregate reports are XML files sent daily by receiving servers. They contain summary data about all emails received from your domain, including:
Source IP addresses
Which servers sent email as your domain, so you can identify legitimate services and unauthorized senders.
Authentication results
SPF and DKIM pass/fail results for each source, showing which emails would be affected by policy enforcement.
Message counts
How many messages each source sent, helping you prioritize which sources to investigate or fix.
Policy applied
What action the receiver took (none, quarantine, reject), showing how your policy is being enforced in practice.
Forensic reports (ruf)
Forensic reports (also called failure reports) are sent for individual messages that fail DMARC. They contain detailed information about the failing email, including headers. However, many receivers don't send forensic reports due to privacy concerns, so don't rely on them as your primary data source.
Cross-domain reporting
If you want reports sent to an address at a different domain (e.g., your DMARC service provider), the receiving domain must publish a DNS record authorizing it:
example.com._report._dmarc.reportingdomain.com TXT "v=DMARC1"
Without this authorization record, receivers will not send reports to the external address.
Step-by-step rollout guide
Rolling out DMARC correctly is a process, not a single change. Rushing to
p=reject without preparation can block legitimate email. Follow
these steps:
Set up SPF and DKIM first
DMARC depends on SPF and DKIM. Make sure both are properly configured for all services that send email on behalf of your domain. Set up SPF and set up DKIM.
Publish a p=none record with reporting
Start with a monitoring-only policy. This collects data without affecting email delivery.
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
Analyze reports for 2–4 weeks
Review aggregate reports to identify all legitimate sending sources. Fix SPF/DKIM for any that are failing. Look for unauthorized senders.
Move to p=quarantine gradually
Once legitimate sources pass authentication, move to quarantine with a low percentage and increase over time.
v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]
Advance to p=reject
After confirming no legitimate email is being quarantined, move to full rejection. This is the strongest protection against domain spoofing.
v=DMARC1; p=reject; rua=mailto:[email protected]
p=reject without first collecting and analyzing reports is the
most common DMARC mistake. You may block legitimate email from marketing
platforms, CRM systems, or other services you've forgotten about.
Common mistakes
Jumping straight to p=reject
Deploying a reject policy without monitoring first can block legitimate email from services you've forgotten about — marketing platforms, invoicing systems, helpdesk tools, or even forwarded emails from mailing lists.
Fix: Always start with p=none and monitor reports for at least 2–4 weeks before enforcing. Use the pct tag for gradual rollout.
Not setting up reporting (rua)
A DMARC record without a rua address gives you policy enforcement
but no visibility. You won't know if legitimate emails are failing or if
attackers are spoofing your domain.
Fix: Always include a rua address. Use a dedicated DMARC reporting service to parse and visualize the XML reports.
Forgetting about third-party senders
Many organizations use services like Mailchimp, HubSpot, Salesforce, or Zendesk that send email on their behalf. If these services aren't configured for proper SPF/DKIM alignment with your domain, DMARC will flag their emails as failures.
Fix: Audit all third-party email senders before enforcing DMARC. Configure custom DKIM signing and SPF includes for each service.
Ignoring the subdomain policy
If you only set p=reject without an sp tag, subdomains
inherit the parent policy by default. But if you haven't configured SPF/DKIM for
subdomains that send email (like marketing.example.com), those
legitimate emails will be rejected.
Fix: Explicitly set sp=none or sp=quarantine for subdomains if they aren't fully configured, or set sp=reject for subdomains you know don't send email.
Staying on p=none forever
A monitoring-only policy provides no protection. Attackers can still spoof your
domain freely. Some organizations deploy p=none and never progress
to enforcement.
Fix: Treat p=none as a temporary phase. Set a timeline to move to quarantine and then reject within a few months.
Best practices
Start with monitoring, end with reject
Begin with p=none to collect data. Move to quarantine with gradual pct increases. Finish at p=reject; pct=100 for full protection.
Always enable aggregate reporting
Include a rua address in your DMARC record. Use a DMARC reporting service to parse XML reports into actionable dashboards.
Audit all sending sources
Before enforcing, identify every service that sends email as your domain. Configure SPF includes and DKIM signing for each one. Check DMARC reports for sources you may have missed.
Use relaxed alignment
Keep the default relaxed alignment (adkim=r; aspf=r) unless you have a specific reason for strict mode. Relaxed alignment allows subdomains to pass, which works better with most email services.
Protect non-sending domains too
Domains that don't send email should still have DMARC. Publish v=DMARC1; p=reject along with v=spf1 -all to prevent attackers from spoofing unused domains.
Review reports regularly
Don't set and forget. Review DMARC reports periodically to catch new unauthorized senders, broken configurations, or services that need SPF/DKIM updates.
Check your domain's DMARC configuration
Domain Guarddog monitors your SPF, DKIM, and DMARC configuration and alerts you to issues.
Get Started Free