DMARC setup for outbound: the fields that actually matter

DMARC is one of those deliverability topics where everyone has half the answer. Some people set up a p=none record, declare victory, and move on. Others set p=reject on day one, spike bounce rates overnight, and roll it back vowing never to touch DMARC again. A smaller number understand what DMARC actually does, tune it for cold outbound specifically, and treat the reports as an ongoing signal.

This playbook is the third version. The goal isn’t an exhaustive RFC walkthrough — plenty of those exist. The goal is: what exact record do I put on my outbound domains, why, and what do I do with the reports after.

If you operate cold outbound and have a DMARC record that reads v=DMARC1; p=none; and nothing else, this is for you.

What DMARC is actually for

Short version: DMARC tells inbox providers what to do when an email claims to be from your domain but doesn’t pass SPF or DKIM alignment. It’s anti-spoofing — it stops attackers sending phishing that looks like it came from you.

Why does this matter for outbound specifically? Two reasons:

Your outbound domain is a common spoofing target. Whenever anyone is running high-volume email from a domain, attackers take notice. Without DMARC enforcement, your legitimate outbound reputation gets dragged down by spoof attempts you don’t even know about.
Gmail and Yahoo now require DMARC for bulk senders. Since February 2024, sending more than 5,000 emails per day to Gmail/Yahoo without a DMARC record at minimum p=none gets you filtered hard. Over a year in, nobody should still be on no-DMARC — but they are.

DMARC is not going to dramatically lift your reply rate. It’s the table-stakes that lets everything else you do work properly.

The exact record I use on outbound domains

v=DMARC1; p=reject; rua=mailto:dmarc-rua@your-domain.com; ruf=mailto:dmarc-ruf@your-domain.com; fo=1; adkim=s; aspf=s; pct=100

Every field in that record is deliberate. Here’s why.

`v=DMARC1`

Mandatory. Version marker. Don’t change.

`p=reject`

The policy. Three options: none, quarantine, reject.

p=none — tell me about failures but deliver the mail anyway. Fine for the first 30 days of DMARC, useless long term.
p=quarantine — send failing mail to spam. Middle ground.
p=reject — refuse failing mail at the SMTP layer. Spoofing attempts bounce.

For outbound domains specifically, I use p=reject from day one if I can. Counter-intuitive advice — most guides say start at none, monitor for 30 days, step up. That’s correct for a company’s primary domain where legitimate mail flows through systems the admin doesn’t control (marketing platforms the CRO signed up for, HR tools, etc.).

For a dedicated outbound domain (e.g. gohello-acme.com that only sends cold outbound via Instantly), you built the domain this week. You know exactly what’s sending from it — your outbound tool, and nothing else. p=reject is safe and it’s the strongest posture.

Don’t confuse “dedicated outbound domain” with “company primary domain.” Never set p=reject on your company’s primary domain without a 60-day monitoring period first.

`rua=mailto:dmarc-rua@your-domain.com`

Aggregate reports. Inbox providers send you daily summaries of who’s sending mail that claims to be from your domain, whether they passed SPF/DKIM, and what DMARC action was taken.

Point this at a mailbox or a DMARC processing service (more on this below). If you point it at a raw mailbox you’ll get hundreds of XML files a day that humans can’t read — that’s why most operators use a processing service.

`ruf=mailto:dmarc-ruf@your-domain.com`

Forensic reports. Per-message failure notifications. Less universally supported than rua (many providers don’t send these), but when they come they contain the actual failing message headers — invaluable for debugging.

Some operators skip this. I include it because the signal when it does come is high.

`fo=1`

Failure option. Tells providers to send a forensic report if either SPF or DKIM fails. Default is 0, which only fires if both fail — which is rarely useful. fo=1 gives you a much better signal.

`adkim=s` and `aspf=s`

Alignment mode. Two options each: s (strict) or r (relaxed).

Strict: the domain in the DKIM signature / SPF envelope must match the From domain exactly.
Relaxed: subdomains are acceptable (e.g. mail.your-domain.com counts for your-domain.com).

For outbound domains I use s (strict). Again — counter-intuitive but correct here. On an outbound-only domain there’s no legitimate reason for a subdomain to be sending mail on your behalf. Strict alignment prevents a class of spoofing where attackers exploit relaxed alignment by registering mail.your-legit-domain.com.

On a primary domain with lots of services, use r (relaxed). Different context.

`pct=100`

Percentage of mail the policy applies to. 100 is the full rollout. During a staged rollout on a primary domain you’d ramp from pct=10 to pct=25 to pct=100 over a few weeks. For dedicated outbound domains starting fresh, pct=100 from day one.

The three mistakes I see in 90% of DMARC records

Mistake 1 — DMARC set but SPF/DKIM misaligned

DMARC depends entirely on SPF and DKIM. If your DKIM signing is broken or your SPF include is missing a sender, DMARC rejects the mail. You end up with the policy doing its job — refusing messages that don’t align — against your own legitimate sends.

Fix: always verify SPF and DKIM alignment before setting p=quarantine or p=reject. Send a test message to check-auth@verifier.port25.com (free service) and read the response. If SPF shows pass and the domain matches, DKIM shows pass and the domain matches, and “DMARC alignment” shows pass — you’re safe to enforce.

Mistake 2 — Over-inclusive SPF records

SPF has a 10-DNS-lookup limit. Every include: adds lookups. Every service you’ve ever connected to sending might be in there.

Typical bloated record:

v=spf1 include:_spf.google.com include:sendgrid.net include:mailchimp.com include:outlook.com include:mg.mail.com include:spf.constantcontact.com ~all

Six includes, each with sub-lookups. You’re probably over the 10-lookup limit, which means SPF permerrors, which means DMARC fails alignment, which means p=reject eats your outbound.

Fix for outbound domains: one sending service per outbound domain. One include. No bloat.

v=spf1 include:spf.instantly.ai -all

Note the -all at the end (hard fail) vs. the common ~all (soft fail). For outbound-only domains, -all is the correct posture. Same logic as strict alignment — there’s no legitimate reason for any other system to be sending.

Mistake 3 — RUA pointed at a mailbox nobody reads

The default advice is “point RUA at an email address you control.” Most operators point it at dmarc@company.com, the reports arrive as XML, nobody can read them, nothing is ever checked.

The DMARC reports are valuable — they tell you every source attempting to send as your domain, and they catch things like SPF misconfigurations, forgotten services, and live spoof campaigns. But raw XML is unreadable without tooling.

Fix: use a DMARC processing service. Options:

Postmark DMARC Monitoring — free, lightweight, sends a weekly summary email.
DMARCian — more features, paid tier for higher volumes.
Valimail Monitor — enterprise-grade, overkill for a small operator but solid.

For outbound setups specifically, Postmark’s free tier is almost always enough. Sign up, they give you a mailto address to use in your RUA field, they parse the XML, they send you a readable weekly report.

This is the 10-minute setup step that 90% of operators skip and then don’t know why they aren’t getting value out of DMARC.

Rolling out DMARC on a domain you’re already sending from

The safe sequence:

Week 1 — Inventory

Before touching DMARC, confirm:

[ ] SPF record is valid and under 10 lookups.
[ ] DKIM is signing every message (check headers of a sent message).
[ ] Both SPF and DKIM align with the From domain (use the port25 verifier above).

If any of those fail, fix them before setting DMARC. DMARC on a broken foundation makes things worse.

Week 2 — Deploy at `p=none`

Set:

v=DMARC1; p=none; rua=mailto:[your-postmark-rua-address]; fo=1; adkim=s; aspf=s; pct=100

Nearly all your legitimate sends are aligned (> 95%).
The sending sources listed are all expected.
No mystery IPs or third parties sending as your domain.

Week 3 — Move to `p=quarantine`

Change p=none to p=quarantine. Leave it for 7–10 days. Watch bounce rates in your sequencer. If bounces spike, something is still misaligned — step back to p=none and investigate.

Week 4 — Move to `p=reject`

If quarantine looked clean, step up to p=reject. You’re done. Maintenance from here is checking the Postmark summary weekly.

For a brand-new dedicated outbound domain you can compress this to 3 days at p=none, confirm alignment, jump straight to p=reject. New domains have nothing to inventory.

What the DMARC reports tell you over time

Once you’re running DMARC with RUA feedback, here’s what I watch for in the weekly summary:

Alignment rate by source

Every sending source should be > 99% aligned. If your main outbound tool drops to 95%, something changed — usually a DKIM rotation that didn’t propagate, or a new sending IP not yet in the SPF record. Investigate.

Unknown sources

Any IP or domain sending as your domain that you don’t recognize is either:

A legitimate service you forgot about (common — marketing tools, ex-employee mailbox rules).
Third-party spoofing attempts (less common on obscure outbound domains; more common on well-known primary domains).

Either way, worth 10 minutes of diagnosis.

Volume patterns

If DMARC reports show you sending 40,000 mails/week and your sequencer says you sent 25,000, something is off. Usually a sequence that duplicated sends or a misconfigured warmup tool double-counting. Catch these before they hit reputation.

DMARC on lookalike domains

If you run outbound from lookalike domains (e.g. getacme.com alongside acme.com), every single one of them gets its own DMARC record, tuned the same way. Skipping DMARC on a subset of your outbound domains doesn’t just weaken spoofing protection on those specific domains — it degrades your overall sender reputation because inbox providers will see the “acme family” as inconsistent.

Treat each lookalike as a standalone outbound domain with its own full DMARC setup.

What DMARC doesn’t do

Worth being honest about:

DMARC doesn’t improve deliverability directly. It prevents spoofing. Your reply rate doesn’t jump because you turned on DMARC.
DMARC doesn’t catch compromised accounts. If someone stole your DKIM key and is sending from your infrastructure, DMARC will cheerfully pass them — from DMARC’s perspective, the message is legitimate.
DMARC doesn’t stop legitimate-but-annoying mail. If you forwarded your newsletter to someone and it ends up in spam, DMARC wasn’t the cause and won’t fix it.

DMARC is narrow and important. It’s the boring layer of deliverability that most operators skip and all deliverability consultants put on first.

The one-page DMARC checklist

Before I consider an outbound domain “DMARC-ready”:

[ ] SPF record valid, single sender include, under 10 lookups, ends in -all.
[ ] DKIM signing confirmed via message header inspection.
[ ] Port25 verifier returns pass on SPF, DKIM, and DMARC alignment.
[ ] DMARC record at p=reject with adkim=s, aspf=s, pct=100, fo=1.
[ ] RUA pointed at a DMARC processing service (Postmark or equivalent).
[ ] RUF pointed at an operator mailbox for forensic reports.
[ ] Weekly DMARC summary email is actually read by someone.
[ ] If you have lookalike domains: same setup on each one.

Every outbound domain that doesn’t clear this checklist is a risk. Fix it before you scale sending volume on that domain.

When DMARC is not your problem

If you have DMARC set up correctly and your deliverability is still poor, DMARC isn’t the issue. Look at Google Postmaster signals — domain reputation, IP reputation, complaint rate, authentication alignment. DMARC is a prerequisite for those signals being clean. It’s not a substitute.

The sequence most operators need:

Get DMARC right (this playbook).
Get Postmaster monitoring right (the audit playbook).
Keep warmup and volume discipline tight.
Only then worry about copy, offers, and conversion.

Out of order, you’re patching symptoms. In order, you have a deliverability foundation that scales.