Concept
DMARC ties SPF and DKIM together into an enforceable policy: it tells receiving mail servers what to do with mail that fails alignment (p=none — do nothing, just report; p=quarantine — send to spam; p=reject — refuse outright), and it requests aggregate reports (RUA) summarizing what mail claiming your domain is actually being seen across the internet — including mail you never sent, i.e. spoofing attempts. The pct= tag lets a policy apply to only a percentage of mail, enabling a gradual rollout rather than an all-at-once cutover.
Common Misconception
"The safest move is to jump straight to p=reject immediately, since that's the most secure setting." This is backwards in practice — going straight to reject without first spending time at p=none reviewing real RUA reports risks silently blocking your OWN legitimate mail from a forgotten sending source (a CRM, a support desk platform, an internal tool) that isn't properly aligned yet. The progression from none to quarantine to reject exists specifically to surface these gaps safely before they become a real outage where legitimate customer-facing email starts bouncing.
Hands-On Exercise
No lab environment needed for verification:
- marinadns.io/mailauth — checks your domain's current DMARC record and policy stage.
- marinadns.io/emailheader — inspect
Authentication-Results headers on real received mail to see how DMARC alignment was actually evaluated for that message.
- noda.marinadns.io — DMARC Record check (CAT-MAIL), Unconditional regardless of MX presence per NODA's own methodology.
For the full policy-progression exercise (deploying p=none, reading a real aggregate RUA report, then ramping via pct= toward p=reject), see Lesson 10 in the DNS Admin Course Lab Environment page — this genuinely needs real mail flow over 1–2 weeks, not something to simulate.
Commands to Run
# Read current DMARC record
dig _dmarc.yourdomain.com TXT +short
# Start at monitoring-only:
# v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
# After 1-2 weeks of real mail flow, inspect the RUA aggregate report (arrives as an XML attachment)
# Look for: source IPs you don't recognize, SPF/DKIM alignment failures on mail you DO recognize as legitimate
# Progress the policy once reports are clean:
# v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc-reports@yourdomain.com
# ... then eventually:
# v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com
# Verify each stage is live
dig _dmarc.yourdomain.com TXT +short
Use pct= to ramp gradually (e.g. 25/50/100) rather than flipping the whole domain to reject at once — this is the safest real-world rollout pattern.
Mastery Checkpoint
You should be able to explain, without looking anything up:
- Why jumping straight to
p=reject is riskier than a staged rollout, not safer.
- What an RUA aggregate report actually tells you, and why unrecognized source IPs in it matter.
- Why a domain that sends no mail still benefits from publishing a DMARC policy.
If you can answer all three without re-reading this lesson, move to Lesson 11.
← DNS Admin Course Lab Environment
