Learn / What is DMARC

What is DMARC?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) builds on SPF and DKIM to enforce authentication alignment and gives you visibility into who is—and isn't—authorized to send mail on your domain.

What DMARC solves

SPF and DKIM alone have a problem: they authenticate the mail server or signing domain, but they don't tie that to the user-visible From address. An attacker could send mail from a server authorized by your SPF, signing with a DKIM key from a different domain, and SPF and DKIM would both pass—even though the From header is a complete lie.

DMARC fixes this by:

  1. Requiring that SPF or DKIM pass
  2. Requiring that the authenticated domain aligns with the user-visible From header
  3. Enforcing a policy: tell receivers what to do if alignment fails (monitor, quarantine, or reject)
  4. Delivering reports on which emails passed and failed—so you can track down issues and iterate toward enforcement

The DMARC record

DMARC policy is published in a TXT record at the special subdomain _dmarc.{domain}. Here's a minimal example: 

_dmarc.example.com
v=DMARC1; p=none; rua=mailto:rua@reports.uglydmarc.com

This says: "Version 1 of DMARC. Policy is monitor (none). Send daily aggregate reports to rua@reports.uglydmarc.com."

Core fields:

Field Purpose Example
v=DMARC1 Version (always 1) –
p={none|quarantine|reject} Policy for the domain p=reject
rua=mailto: Email address for aggregate reports rua=mailto:rua@reports.uglydmarc.com
ruf=mailto: Email address for forensic (individual email) reports ruf=mailto:forensics@example.com
adkim={r|s} DKIM alignment mode: relaxed or strict adkim=s
aspf={r|s} SPF alignment mode: relaxed or strict aspf=s
sp={none|quarantine|reject} Policy for subdomains sp=quarantine
pct=X Percentage of emails the policy applies to (for gradual rollout) pct=50

Alignment: strict vs. relaxed

Alignment checks whether the authenticated domain (from SPF or DKIM) matches the user-visible From domain. DMARC supports two modes:

Strict alignment

The authenticated domain must exactly match the From domain. Example:

  • From: alice@example.com and SPF authenticated domain example.com → aligned
  • From: alice@example.com and SPF authenticated domain mail.example.com → NOT aligned (subdomain mismatch)

Strict alignment is secure but requires careful coordination. Many organizations can't use it because their subdomains (e.g., mail.example.com, bounce.example.com) send mail but have different Return-Path domains.

Relaxed alignment (default)

The authenticated domain must share the same organizational domain (the registrable domain). Example:

  • From: alice@example.com and SPF authenticated domain mail.example.com → aligned (both under example.com)
  • From: alice@example.com and SPF authenticated domain other.com → NOT aligned

Relaxed alignment is more forgiving and the DMARC default. It still catches impersonation but allows legitimate mail from different subdomains.

Policies: none, quarantine, reject

p=none (Monitor)

The policy does nothing—it's purely informational. Receivers get reports on DMARC pass/fail status but don't reject or quarantine mail. Use this for 1–2 weeks when you first deploy DMARC, while you collect data and identify any legitimate mail that might fail alignment.

p=quarantine (Soft enforce)

Mail that fails DMARC (fails authentication or alignment) is sent to the receiver's spam/junk folder. The user can still see it (it's not deleted), but it's out of the inbox. Use this after you're confident that your legitimate senders are aligned, but before you're ready to reject outright.

p=reject (Hard enforce)

Mail that fails DMARC is rejected outright. The sender doesn't know the mail was rejected (unless they're watching bounce rates), but receivers never see the fake mail. This is the goal state: zero tolerance for misaligned or unauthenticated mail.

Most organizations start with p=none, move to p=quarantine after 1–2 weeks, then to p=reject after another 1–2 weeks. The gradual rollout prevents accidentally rejecting legitimate mail.

What p=reject does for you — in plain English

Think of p=reject as a standing instruction you give to every mail server on the internet: "Only deliver mail that's genuinely from me. If a message claims to be from my domain but I didn't actually send it, throw it away — don't even drop it in the spam folder."

Until you turn this on, anyone can put your domain in the "From" line of an email, and plenty of inboxes will still show it as if it came from you. With p=reject, those forgeries get refused before they ever reach the recipient.

Why that protects you

  • Scammers can't impersonate you. Phishing emails and fake invoices sent "from" your domain to your customers, staff, or partners are rejected — they never land in an inbox.
  • Your customers stay safe and your brand stays trusted. People don't receive scams dressed up to look like they came from you, so they keep trusting the messages that really do.
  • Your real email reaches the inbox more often. Once you enforce DMARC, mailbox providers (Gmail, Microsoft, Yahoo) treat your domain as a known, well-run sender — so your legitimate messages are less likely to get flagged as spam.
  • Less fraud risk. It shuts down a favorite tactic behind business-email-compromise and wire-fraud scams: pretending to be you.
  • It unlocks your logo in the inbox. Enforcing DMARC is the prerequisite for BIMI — showing your brand's logo next to your emails in inboxes that support it.

The catch — and how UglyDMARC handles it

Only switch to p=reject once you're confident every one of your real senders passes — otherwise you could block your own mail. That's exactly what the reports are for: UglyDMARC shows you who is sending as your domain and whether they pass, so you can move to p=reject with confidence instead of crossing your fingers.

DMARC reporting

When you set rua=mailto:rua@reports.uglydmarc.com, receivers send you daily aggregate reports (RUA) summarizing how many emails passed, failed, and why. These reports are XML files that show:

  • How many emails your organization received claiming to be from your domain
  • How many passed SPF / DKIM / DMARC alignment
  • The source IPs of emails from your domain (legitimate and spoofed)
  • Which organizations received them (Gmail, Yahoo, Hotmail, etc.)

DMARC reporting is the single most valuable tool for understanding your authentication posture. Without reports, you're flying blind. With them, you can see exactly which senders are aligned and which are breaking your policy.

Tip

Parsing raw DMARC XML reports is tedious and error-prone. UglyDMARC ingests and formats reports automatically and gives you searchable dashboards, aggregated stats, and alerts.

Example DMARC records

Monitor mode (initial deployment)

_dmarc.example.com
v=DMARC1; p=none; rua=mailto:rua@reports.uglydmarc.com; aspf=r; adkim=r

This says: "Monitor only. Report to dmarc@example.com. Use relaxed alignment for both SPF and DKIM (default)." No mail is rejected or quarantined.

Quarantine mode (after 1–2 weeks)

_dmarc.example.com
v=DMARC1; p=quarantine; rua=mailto:rua@reports.uglydmarc.com; aspf=r; adkim=r

Misaligned or unauthenticated mail goes to spam, but it's not deleted.

Reject mode (after 2–4 weeks)

_dmarc.example.com
v=DMARC1; p=reject; rua=mailto:rua@reports.uglydmarc.com; aspf=r; adkim=r; pct=100

Misaligned or unauthenticated mail is rejected. pct=100 means the policy applies to 100% of traffic.

Strict DKIM, relaxed SPF

_dmarc.example.com
v=DMARC1; p=reject; rua=mailto:rua@reports.uglydmarc.com; adkim=s; aspf=r

This requires DKIM signatures to exactly match the From domain (strict) but allows SPF from subdomains (relaxed).

Subdomain policy

_dmarc.example.com
v=DMARC1; p=reject; rua=mailto:rua@reports.uglydmarc.com; sp=quarantine

The main domain uses p=reject, but subdomains (e.g., mail.example.com) use sp=quarantine for a softer enforcement.

Common DMARC mistakes

Publishing p=reject on day one

Jumping straight to enforcement without data is dangerous. You might reject legitimate mail from a vendor you forgot to add to SPF or DKIM. Always start with p=none and move up gradually.

Not setting a reporting address

If you don't set rua=, you get no reports and have no visibility into misalignment issues. Always enable reporting, even in p=none mode.

Strict alignment without perfect SPF/DKIM

Strict alignment (adkim=s; aspf=s) requires that your Return-Path and DKIM domain exactly match the From domain. This is often impossible if you use cloud services (Microsoft 365, Google Workspace) that bounce mail from different subdomains. Start with relaxed alignment.

Forgetting subdomains

If you have subdomains like mail.example.com or api.example.com that send mail, they need their own DMARC records or a permissive sp= policy on the parent. Otherwise, legitimate mail from subdomains might fail.

The staged rollout to rejection

A mature DMARC deployment typically follows this timeline:

  1. Week 1: Monitor (p=none)

    Publish DMARC with p=none. Monitor reports daily. Identify any legitimate vendors that are failing alignment.

  2. Week 2: Fix misalignment

    Update SPF and DKIM records to align all legitimate senders. Re-run reports and confirm improvements.

  3. Week 3: Quarantine (p=quarantine)

    Once aligned senders comprise >80% of traffic, move to p=quarantine. Watch for complaints or bounce spikes.

  4. Week 4+: Reject (p=reject)

    When quarantine reports show misaligned mail is minimal, move to p=reject. You're now actively blocking spoofing attacks on your domain.

Organizations with complex vendor ecosystems (many ESPs, marketing platforms, etc.) often take 4–8 weeks to reach p=reject. Organizations with simple mail flows (a single cloud provider) might do it in 2 weeks. DMARC reports guide every decision.

Going further

DMARC reports are invaluable, but raw XML is hard to parse. Learn how to read DMARC reports and understand the structure, or use a tool (like UglyDMARC) to aggregate reports across domains, search for issues, and track your progress toward enforcement.