How to Create a DMARC Record, the Safe Way

Why "Just Publish p=reject" Is the Wrong First Move

The single most damaging mistake in DMARC adoption is treating it like any other DNS record: write it, publish it, done. DMARC is fundamentally different because it changes what happens to mail that fails authentication — and until you've actually observed which of your sending sources pass and fail, you don't know what "failing" mail even includes. It might be spoofed phishing attempts you want blocked. It might also be your own marketing platform, your helpdesk tool, or an internal system nobody remembers configuring SPF for. Publishing an enforcing policy before you know the difference risks blocking your own legitimate mail on day one, which is precisely the outcome a careful rollout avoids.

The correct sequence starts with observation, not enforcement, and every step in this guide builds toward earning enforcement rather than assuming it's safe from the start.

Step 1: Confirm SPF and DKIM First

DMARC doesn't independently authenticate anything — it evaluates whether SPF or DKIM passed and whether either one is aligned with your visible From: domain. A DMARC record with neither SPF nor DKIM correctly configured has nothing to build enforcement on. Use SPF Lookup and DKIM Lookup to confirm both are published and passing for every sending source before moving forward.

Step 2: Publish a Monitor-Only Record

Step 3: Read Your Aggregate Reports

Aggregate reports arrive as structured XML from receiving mail providers, typically daily, and show every source IP that sent mail as your domain along with pass/fail results for SPF and DKIM alignment. Cross-reference every source against your sending inventory from step 1 — anything unrecognized deserves investigation before you tighten policy, since it's either a legitimate source you forgot about or, less commonly, evidence someone else is sending as your domain.

Step 4: Move to Quarantine Gradually

Once reports show clean alignment across every known source, move to quarantine — ideally starting with a reduced pct= value so any remaining unknown issue only affects a fraction of mail rather than all of it. Increase pct= over subsequent weeks as reports continue to confirm cleanliness.

Step 5: Reach Reject

Reject is the end state: mail failing alignment is blocked outright. Reaching it confidently means every legitimate source has been identified, fixed if needed, and confirmed passing consistently — not guessed at.

Common Mistakes During Rollout

Building the Sending Source Inventory in Practice

The inventory step sounds simple in the abstract but is where most rollouts actually stumble, because "every system that sends mail as your domain" is a broader category than most people's first mental list. Start with the obvious: your primary business email platform, any transactional email API used by your product, and your main marketing tool. Then go looking for what's easy to forget: internal monitoring or alerting scripts that email a status report, a CRM's automated follow-up sequences, an old newsletter tool nobody's touched in a year but that's still technically active, a support ticketing system that sends confirmation emails, and any one-off scripts a developer wrote years ago that still run on a cron job somewhere. Asking other teams directly — not just checking what IT knows about — is often how the most surprising entries on this list get discovered, since marketing and sales frequently adopt SaaS tools that send mail on the company's behalf without ever looping in whoever manages DNS.

A Realistic Worked Timeline

This is a realistic, moderately conservative timeline for an organization of average sending complexity — a domain with very few sending sources can move faster, while one with dozens of independently-managed tools across many teams should expect longer, since each newly-discovered source restarts the confidence-building process for that specific source.

What to Do When Reports Show an Unexpected Source

Finding a source you don't recognize in aggregate reports is not itself a crisis, but it does require a specific investigation sequence rather than either ignoring it or immediately assuming malicious spoofing. First, check whether the sending IP resolves to infrastructure belonging to a known SaaS vendor — many report analysis tools will flag this automatically, and a reverse lookup or ASN check can confirm it manually. If it traces to a legitimate vendor, the next step is determining whether your organization has an actual relationship with that vendor (a forgotten tool) or whether it's unrelated (worth flagging to the vendor or investigating further). If it doesn't trace to any identifiable legitimate infrastructure and the volume or pattern looks like phishing or spoofing, this is exactly the signal DMARC monitoring exists to surface, and it's reasonable evidence supporting an accelerated move toward enforcement rather than a reason to delay it.

Handling Multi-Domain Organizations

Organizations managing several domains — a primary brand domain, regional variants, acquired company domains still in use, defensive registrations — face a choice about whether to run this rollout process independently per domain or coordinate it centrally. Independent rollouts give each domain team full control over pacing but risk inconsistent policies and duplicated inventory effort across teams that might actually share some sending infrastructure. A centrally coordinated rollout, tracking all domains against the same checklist with a shared inventory of cross-domain sending tools, tends to surface shared infrastructure faster (the same marketing platform sending on behalf of three different brand domains, for instance) and avoids each domain team independently rediscovering the same vendors. Neither approach is universally correct; the right choice depends on how centralized your organization's email infrastructure actually is versus how independently each domain's teams currently operate.

Communicating the Rollout Plan Before You Start

Before publishing even a monitor-only record, it's worth sending a brief note to whoever owns each sending platform in your inventory, explaining that a DMARC rollout is beginning, what it means for them (nothing yet, at the monitoring stage), and when they might expect to hear from you again as enforcement approaches. This costs little time and pays off considerably later: when you do eventually need to ask marketing to check their platform's SPF configuration because reports flagged an issue, they already have context for why you're asking rather than receiving a confusing, out-of-nowhere request.

What Success Looks Like Along the Way, Not Just at the End

It helps to define intermediate markers of success rather than treating "reached p=reject" as the only meaningful milestone. Successfully identifying and fixing a forgotten sending source during the monitoring phase is a win, even though it happens before any enforcement. A clean report cycle at pct=25 quarantine is evidence the harder, riskier stages ahead are more likely to go smoothly, not just a checkbox on the way to 100%. Recognizing and crediting this incremental progress keeps a multi-week rollout from feeling like an all-or-nothing effort that only counts once fully complete, which matters for maintaining organizational patience and support through a process that, done correctly, takes real time.

Related Reading in This Series

For what every individual tag means in depth, see DMARC Tags Explained. For a full pre-launch checklist, read DMARC Deployment Checklist. For choosing between report types, see rua vs ruf. To build your record, open DMARC Record Generator.