How to Create a DMARC Record Step by Step (2026)

Introduction

Creating your first DMARC record is a 30-minute task if you do it right and a 30-day rollback if you don't. The technical mechanism is trivial — one TXT record at one DNS name. The judgement lives in choosing the right values and not skipping the verification.

This guide walks the full path: prerequisites, value choices, where to publish, how to confirm it's live, and what to do in the first week after.

Why this topic matters

The fastest way to break email at a company is to misconfigure DMARC. The second-fastest way is to leave DMARC unconfigured while your senders pile up. A correct first record sets up everything that follows — the monitoring phase, the progressive enforcement, and the steady-state operation.

This article assumes you've read what a DMARC record is and just need the practical creation steps. If you want the full beginner context first, the foundational guide is the right starting point.

Prerequisites

Before you create the record, you need three things in place. Skipping any of them turns a 30-minute task into a multi-week incident:

SPF must already be published. A valid SPF record listing every legitimate sending IP. If you don't have one, fix that first — DMARC depends on SPF and DKIM, not the other way around.
DKIM should be configured for at least your primary sender. DKIM signing on your main sending platform (Microsoft 365, Google Workspace, your ESP) means most legitimate mail will already pass DMARC's alignment check on day one.
Access to your DNS provider's control panel. Cloudflare, AWS Route 53, GoDaddy, Namecheap — wherever your authoritative DNS lives. You need to add a TXT record.

If any of the above is missing, stop and address it before continuing.

Step-by-step approach to creating the record

Step 1: Pick the policy

For a first record, the answer is almost always p=none. The monitoring-only policy lets you watch what's happening without affecting delivery. Going straight to p=quarantine or p=reject without monitoring is how teams quarantine their own invoices.

Exception: a non-sending domain (a domain that never sends mail) can publish p=reject immediately — there's nothing to break.

Step 2: Decide where reports go

Add a rua= destination. Two patterns work:

Internal mailbox forwarded to a DMARC platform. rua=mailto:[email protected] with the mailbox routed to your platform's ingestion address.
Platform mailbox directly. rua=mailto:[email protected].

Either way, you need a system that parses the XML — reading raw aggregate reports by hand is unsustainable past a few dozen senders.

Step 3: Set the subdomain policy

Always set sp= explicitly. For a first record at p=none, use sp=none too — there's no reason to enforce subdomains while you're monitoring. When you move the parent policy up later, you can update both together. See DMARC for subdomains for the subtleties.

Step 4: Compose the record

For a typical first record:

“text v=DMARC1; p=none; sp=none; rua=mailto:[email protected] “

That's it. You don't need pct=, ruf=, adkim=, or aspf= for the monitoring phase. Add them later if and when you need them.

Step 5: Publish at the right DNS name

The record lives at _dmarc.yourdomain.com. Critically:

The underscore is required.
The record type is TXT (not CNAME, not DMARC — TXT).
TTL of 3600 (one hour) is a reasonable default. Lower TTL while you're iterating; raise it once stable.

In most DNS control panels, you create a new TXT record with:

Name / Host: _dmarc
Type: TXT
Value / Content: the full DMARC string (quotes optional)
TTL: 3600

Step 6: Verify the record is live

Wait a minute, then check from a terminal:

“bash dig +short TXT _dmarc.yourdomain.com “

You should see exactly your DMARC string. If you see nothing, the record hasn't propagated yet or wasn't saved correctly — wait another minute and retry. If you see two records, delete one immediately — multiple DMARC records cause receivers to ignore all of them.

Step 7: Validate the syntax

Use any DMARC record checker. Confirm:

Valid syntax (no typos in tag names or values)
The rua= destination is authorized (if cross-domain, the receiving domain needs a _report._dmarc TXT confirmation)
No conflicting records

The DMARC AI validator does this in one click and flags common mistakes.

Step 8: Confirm reports arrive

Within 24-72 hours of publication, you should receive your first XML aggregate reports. Major mailbox providers (Gmail, Outlook, Yahoo) send daily; smaller providers send less frequently. If no reports arrive within a week, the rua= address is wrong or the mailbox is rejecting them.

Best practices

Don't try to skip monitoring. The temptation to publish p=reject immediately is real for security-conscious teams. Resist it. The monitoring phase exists to surface the senders you didn't know about.
Use a dedicated mailbox. dmarc@, reports@, or postmaster@ work well. Don't route reports to a personal inbox — they'll drown you.
Document the record's intent. Add an internal note explaining why each tag is set. The next engineer reading it should be able to understand the choices.
Set a calendar reminder. Two weeks after publishing, check the aggregate-report dashboard. The remediation work usually starts here.
Plan the next policy move from day one. Set a date for moving to p=quarantine pct=10 and another for p=reject pct=100. The calendar should drive the rollout, not vibes.

What happens after you publish

Three things happen in sequence:

Days 1-3. Mailbox providers start sending aggregate reports. Your DMARC platform begins building a per-sender view of who's sending as your domain.
Weeks 1-2. You discover senders you didn't know about. Marketing tools, billing systems, that one developer running a cron job. Each gets cataloged and either authenticated (if legitimate) or noted (if not).
Weeks 2-8. The remediation phase — adding SPF includes, enabling DKIM, fixing alignment. The goal is 100% pass for legitimate mail.

Then you move to p=quarantine, then p=reject. The full path is detailed in how to move from monitoring to enforcement safely.

Recommended next step

Publish your record now if you haven't. The monitoring phase has to start somewhere; the day you publish is the day the clock starts on understanding your sending posture. The DMARC AI dashboard begins parsing reports the same day they arrive.

If you'd rather have someone do this for you, a DMARC-focused MSP typically delivers the audit, publication, and first-month monitoring as a productized engagement.

FAQ

What if my domain already has a TXT record at `_dmarc`?

You have an existing DMARC record. Read it first (here's how) before changing anything. If it's correctly published at p=none, you may already be in the monitoring phase — check whether reports are flowing.

Can I publish DMARC for a subdomain only?

Yes — publish at _dmarc.subdomain.yourdomain.com. This is sometimes useful for piloting on a low-stakes subdomain before doing the main domain. But note that the parent domain's policy applies unless the subdomain has its own published record.

What if I make a typo in the record?

Receivers will ignore the record entirely (invalid syntax) or interpret unknown tags as missing (silent fallback). Validate with a checker before relying on the record. Common DMARC errors covers the typical typos.

Do I need to publish DMARC for every subdomain?

Not necessarily. The parent domain's sp= tag controls subdomain behaviour by default. Publishing per-subdomain records lets you have different policies — useful if one subdomain has different senders than another.

How fast does the record take effect?

DNS-level: within minutes (TTL-dependent). Practical-level: mailbox providers start applying the policy on the next message they receive after the record propagates. Aggregate reports of that activity arrive the next day.

Final thoughts

A correctly-created first DMARC record is the easiest 30 minutes you'll spend on email security all year — and the foundation for every authentication improvement that follows. Get this step right and the next steps unfold naturally; get it wrong and you'll be debugging delivery issues for weeks.

The pattern that works: prerequisites in place, conservative starting policy, dedicated reporting address, validated syntax, monitored from day one. Everything else is execution.