How to Create a DMARC Record (Step by Step)

Since Google and Yahoo started requiring it from bulk senders in 2024, "set up DMARC" has gone from a security nicety to a deliverability requirement. Miss it and your mail to Gmail addresses can be throttled or refused. But DMARC has a sharper edge than SPF or DKIM: a record published too aggressively doesn't just fail open — it can instruct the whole internet to reject or quarantine messages you actually sent. That's why the safe way to build one is deliberately cautious.

This is a build guide. We'll go from no DMARC record to a published, reporting one, then through the slow ramp to enforcement that keeps you from blocking yourself. If you want the conceptual background first — what DMARC is and how it ties the other two checks together — our DMARC explainer covers the theory. Here we're assembling the record.

What a DMARC record is, in one paragraph#

DMARC — Domain-based Message Authentication, Reporting and Conformance — is a single TXT record that does two jobs at once. It tells receiving mail servers what to do with messages claiming to be from your domain that fail authentication, and it asks those servers to send you reports about the mail they see using your domain. You publish it at one specific hostname: _dmarc.example.com. Here's a complete, valid starter record:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

That's a real, working DMARC record. It says: this is DMARC version 1, take no action on failures yet (p=none), and send the aggregate reports to dmarc@example.com. Everything else is refinement. Let's build it up in the order that keeps you safe.

Step 1 — Get SPF or DKIM passing first#

DMARC isn't a standalone check. It sits on top of SPF and DKIM and asks one question: did at least one of them pass and line up with the domain in the visible From address? That second part is called alignment, and it's where most surprises hide.

A message can pass raw SPF while still failing DMARC. SPF checks the hidden Return-Path domain, not the From header your reader sees — so a mailing platform sending "from" your brand but with its own return path passes SPF and fails DMARC alignment. DKIM aligns when the signature's d= domain matches your From domain. DMARC needs at least one of the two to both pass and align.

The practical upshot: before you publish DMARC, make sure your real senders are SPF- or DKIM-authenticated under your own domain. If you haven't built SPF yet, our SPF build guide walks it end to end. Publishing DMARC over senders that don't align is exactly how you discover, at p=reject, that your invoicing tool was never aligned.

Step 2 — Always start at p=none#

The p tag is the policy — the instruction receivers act on. It has three values, and the order you adopt them matters more than anything else in this guide:

• p=none (monitor) — "take no action, just report." Nothing is blocked. You collect data about who sends as your domain and whether they align. This is where every domain should begin.
• p=quarantine — "treat failing mail as suspicious." Receivers typically route it to the spam folder. The middle step.
• p=reject — "refuse failing mail outright." The message never arrives. This is the protective end state, and the one that bites if a legitimate sender still isn't aligned.

Start at none every time, even if you're confident your authentication is clean. The monitoring period exists to surface the senders you forgot — the helpdesk, the calendar invites, the third-party tool someone in marketing signed up for two years ago. Jumping straight to reject turns those forgotten senders into bounced mail with no warning. Begin at none; you'll tighten it later from evidence, not hope.

Step 3 — Set up reporting so the record earns its keep#

A DMARC record at p=none with no reporting address does almost nothing useful. The reports are the value. There are two report tags:

• rua= — the address for aggregate reports. These are daily XML summaries from receivers: how many messages they saw from your domain, from which IP addresses, and whether each passed SPF, DKIM, and DMARC alignment. This is the tag that matters. Set it to a mailbox you'll actually read, e.g. rua=mailto:dmarc@example.com.
• ruf= — the address for failure (forensic) reports, which include redacted detail about individual failing messages. In practice almost no major receiver sends these anymore, for privacy reasons, so don't count on them — rua alone is enough to run a rollout.

The raw XML is hard to read by eye. Many teams point rua at a DMARC report-processing service that turns the files into a dashboard, but a dedicated mailbox works fine for a single domain — you can open the reports and see the sending IPs directly. To send reports to a domain you don't control (like a processor), that domain has to publish an authorization record, but for your own mailbox no extra setup is needed.

Step 4 — Know the optional tags (and skip most of them)#

DMARC has several more tags, and a generator will offer them. You can ignore most at the start, but it helps to recognize them:

• sp= — a separate policy for subdomains. If unset, subdomains inherit the main p value. Useful once you want strict control over mail.example.com versus example.com.
• adkim= and aspf= — alignment strictness, r (relaxed, the default) or s (strict). Relaxed lets a subdomain count as aligned with the parent; strict demands an exact match. Leave both relaxed unless you have a specific reason.
• pct= — the percentage of failing mail the policy applies to, 1–100. Some teams set pct=25 when first moving to quarantine, so only a quarter of failing mail is affected while they watch. Default is 100.
• fo= — failure-reporting options, only relevant if you rely on ruf.

For a first record you need exactly three things: v=DMARC1, a p, and an rua. The rest is tuning you reach for later.

Step 5 — Publish it at _dmarc#

The record is a TXT record, and the hostname is the part people get wrong. It does not go on the root of your domain like SPF — it goes on the _dmarc subdomain. In your DNS panel the host or name field is _dmarc (your provider appends the domain to make _dmarc.example.com), and the value is the full string starting with v=DMARC1.

As with SPF, a domain may have only one DMARC record. Two TXT records at _dmarc is an error and DMARC is treated as absent. After you save, the record has to propagate before receivers pick it up, which can take minutes to hours depending on your DNS propagation and TTL.

Step 6 — Read the reports, then ramp up#

Publishing at p=none is the start of the work, not the end. Over the next few weeks the aggregate reports build a picture of every source sending as your domain. Go through them and sort the senders into two piles: the legitimate ones (which need to pass SPF or DKIM with alignment) and the unauthorized ones (spoofers, or stale services you can ignore). For every legitimate sender that's failing alignment, fix it — add the missing SPF include, enable DKIM signing at that platform — until your reports show your real mail passing cleanly.

Only once that picture is clean do you tighten the policy: none → quarantine → reject, pausing at each step to watch the reports for collateral damage. Some teams use pct= to ease into quarantine on a fraction of traffic first. There's no fixed timeline; the reports tell you when it's safe to move. The destination is p=reject — that's the setting that actually stops someone from spoofing your domain — but you earn your way there from data.

Verify what you published#

Pasting a record into DNS isn't confirmation it's serving correctly. Run your domain through our DMARC checker: it fetches the live record at _dmarc, parses every tag, validates the reporting addresses, and grades the policy so you can confirm your enforcement level reads the way you intended. It's also where a stray second record, a typo'd rua, or a policy you thought was reject but published as none shows up — as a quick fix rather than a silent gap.

DMARC is the third leg of email authentication, and it only works when the first two are solid. SPF authorizes the sending server, DKIM signs the message, and DMARC ties them to your visible From domain and sets the policy. Once all three are live, a single domain health report shows them side by side — the fastest way to confirm the whole chain is intact.

DMARC's power and its danger are the same setting. Start at none, fix what the reports reveal, and ramp to reject only when the data says you can.