How to Set Up a DMARC Record

Setting up DMARC is not a single switch you flip — it is a controlled ramp that starts by watching your mail and ends by rejecting spoofed messages. Done in the right order, you reach p=reject without ever blocking a legitimate email. This guide walks through publishing your first record, reading the reports it generates, and tightening the policy stage by stage. It assumes you already have SPF and DKIM in place, since DMARC builds on both; if you are new to the concepts, start with what is DMARC.

Step 1: Publish a monitoring record at p=none

The DMARC record is a single DNS TXT record. Create it at the host _dmarc under your domain — for example _dmarc.example.com — with a value that starts with v=DMARC1. Begin in monitoring mode so nothing is blocked while you learn what your domain actually sends:

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

The p=none policy tells receivers to take no action on failing mail, while the rua tag tells them where to send aggregate reports. That is the entire minimum viable record. Publish exactly one DMARC TXT record at this name — publishing more than one invalidates DMARC processing entirely, which is one of the most common errors. After it propagates, confirm it with our DMARC record checker.

One operational note about rua: if you send reports to an address on a different domain than the one publishing the record, the receiving domain must publish a small authorization record, or reporters will ignore the destination.

Step 2: Read your aggregate reports

Within a day or two, XML aggregate reports begin arriving at your rua address — typically one per mailbox provider, per day. Each lists the IP addresses sending mail as your domain, the message counts, whether SPF and DKIM passed, whether they aligned, and what policy was applied. Sort every sending source into three buckets:

• Aligned and passing — healthy mail. Leave it alone.
• Legitimate but failing — usually a vendor (CRM, helpdesk, billing platform, newsletter tool) sending with its own Return-Path or signing with its own DKIM domain. Fix this by configuring a custom return-path or delegated DKIM keys with that vendor so its mail aligns to your domain.
• Unknown sources — either innocent forwarding or active spoofing. These are what your eventual p=reject policy will shut down.

Raw XML becomes unmanageable quickly for any domain with real volume, so most teams feed reports into a parsing and monitoring service rather than reading files by hand. Do not rely on forensic (ruf) reports for this work — most major providers do not send them, so aggregate reports are your real data source.

Step 3: Fix your legitimate senders

This is the step that actually takes time. Work through every legitimate source that is failing alignment and bring it into line. The most common fix is alignment, not authentication: a vendor's SPF often passes for the vendor's own domain but does not align with your From domain. Enabling a custom return path and delegated DKIM signing with that vendor solves it. Stay at p=none until your reports show every legitimate sending source passing with alignment. There is no fixed calendar — a simple domain may take a few weeks, a large organization with many vendors longer. The mistake to avoid is staying at p=none indefinitely, because monitoring mode blocks nothing.

Step 4: Ramp to quarantine

Once reports show your legitimate mail consistently passing, raise the policy to quarantine. Failing mail now gets routed to spam rather than the inbox:

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

Keep watching the reports. Quarantine is the stage where any sender you missed surfaces as a complaint, and because mail is going to spam rather than being rejected, you have room to catch and fix it. If you want to signal a cautious rollout, DMARCbis (RFC 9989, May 2026) provides the t=y test-mode flag, which tells receivers the policy is being trialed. Note that the old pct percentage-rollout tag was removed in that revision and is ignored by receivers — do not reach for it.

Step 5: Move to reject

When quarantine has run cleanly and your reports stay clean, move to full enforcement. This is the setting that actually stops spoofed mail from reaching inboxes:

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

Reaching p=reject is also the prerequisite for displaying your logo through BIMI, since BIMI requires DMARC at enforcement (quarantine or reject).

Step 6: Set your subdomain policy

By default, subdomains inherit the main p value. Two extra tags give you finer control. The sp tag sets a separate policy for subdomains — useful early, when you can hold the main domain at p=none but set sp=reject to cut off spoofers inventing plausible names like secure.example.com. The np tag covers non-existent subdomains, those with no A, AAAA, or MX records; since nothing legitimate can originate there, np=reject is safe to apply immediately. A hardened record bringing it all together looks like this:

v=DMARC1; p=reject; sp=reject; np=reject; adkim=r; aspf=r; rua=mailto:dmarc@example.com

Here adkim=r and aspf=r set relaxed alignment for both methods — these are the defaults, so listing them is optional, but being explicit makes the record easier to audit. If your domain never sends email at all, park it defensively instead: publish v=DMARC1; p=reject at _dmarc, an SPF record of v=spf1 -all, and no DKIM keys, so any mail claiming to come from it is treated as forged.

Once published, validate the final record with the DMARC record checker to confirm the syntax is clean and no legacy tags remain. For a deeper look at how alignment and reporting work under the hood, see what is DMARC.