DMARC, explained: what the policy actually does

DMARC is the DNS record that ties SPF and DKIM together and finally lets you decide what happens when mail claiming to be from your domain fails both. Without it, receivers guess. With it, you set the consequence — and you get reports showing exactly who is sending as you, legitimately or not.

The one question DMARC answers

When a message arrives claiming to be from yourcompany.com, the receiver checks SPF and DKIM. DMARC adds the missing piece: alignment. The domain in the visible From address must match the domain that passed SPF or DKIM. A newsletter tool can pass SPF for its own domain all day — if the From header says your domain and nothing aligned to it passed, DMARC fails.

Your policy then tells the receiver what to do with that failure.

The three policies, honestly

p=none doesn't mean “no protection.” It means monitor: receivers send you reports and deliver failing mail normally. It's the mandatory first step — enforcing before you know what legitimate mail exists breaks real email.

p=quarantine puts failing mail in spam (or a quarantine). p=reject bounces it at the door. Most companies that finish a rollout sit at reject; banks and brands under active spoofing get there fastest.

The record, piece by piece

v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com; pct=100; adkim=s; aspf=r

• p — the policy: none, quarantine, or reject.
• rua — where aggregate reports go. This is the entire monitoring payoff; without an address you're flying blind.
• pct — what share of failing mail the policy applies to. pct=10 with quarantine means “spam-folder 10% of failures.” It exists for staged rollouts.
• adkim / aspf — alignment mode. s (strict) requires exact domain match; r (relaxed) allows subdomain alignment. Relaxed is the common default.

What the reports actually show you

Aggregate (rua) reports are XML, sent daily, listing every message that claimed to be you: source IP, how many, whether SPF/DKIM passed and aligned. Read them and you'll find three things: your real senders (including ones you forgot — the billing tool, the CRM), your own misconfigurations, and the spoofers. That inventory is the whole point of starting at p=none.

A safe rollout in four moves

1. Publish p=none with a rua address you actually read. Wait a couple of weeks.
2. Fix every legitimate source the reports surface — add missing SPF includes, DKIM-sign everything, align third-party senders.
3. Move to p=quarantine, optionally via pct=25 → 50 → 100. Watch spam complaints and your own test sends.
4. When reports show only spoofers failing, go p=reject. Keep monitoring — new SaaS tools love to start sending as your domain unannounced.

Where SuperMailOS fits

On SuperMailOS, DMARC is part of the setup, not a project: DNS records come from the mail server's own zone, DMARC reports flow into a central mailbox and are parsed into your deliverability dashboard, and the policy is branded per domain. You watch the rollout from a dashboard instead of an XML pile. If you want the full authentication picture first, read SPF, DKIM, and DMARC explained, and check any domain's current records free with the email deliverability checker.