How to set up DMARC: the safe, step-by-step rollout

Setting up DMARC is one DNS record and one discipline: publish it in monitoring mode first, read the reports it sends back, fix whatever isn't authenticating, and only then tell receivers to enforce. Rush straight to enforcement and you can send your own legitimate mail to spam. Here is the safe, ordered way to do it.

The short answer#

DMARC lives in a single TXT record at _dmarc.yourdomain.com. The value starts with v=DMARC1, sets a policy (p=none, p=quarantine, or p=reject), and points to a mailbox that collects aggregate reports (rua=). The correct rollout is always the same: start at p=none to watch without breaking anything, use the reports to confirm every legitimate mail stream passes SPF or DKIM in alignment, then step the policy up to quarantine and finally reject. This guide is the step-by-step DMARC setup — for how SPF, DKIM, and DMARC fit together conceptually, see the SPF, DKIM, and DMARC explainer.

What a DMARC record is and where it lives#

A DMARC record is a plain-text DNS entry that tells receiving mail servers two things: what to do with mail that claims to be from your domain but fails authentication, and where to send you reports about it. It is not magic — it is a single TXT record you publish once and then adjust over time.

The location is fixed and non-negotiable: the record must sit at the hostname _dmarc under your domain. So for example.com, the full record name is _dmarc.example.com. If your DNS host asks only for the "name" or "host" field, you usually enter _dmarc and it appends the domain for you.

A minimal, valid starting record looks like this:

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

That is genuinely all you need to begin. It enforces nothing yet — p=none means "take no action" — but it switches on the reporting that makes everything after it possible.

The anatomy of a DMARC record#

Every DMARC record is a semicolon-separated list of tags. Only two are required (v and p); the rest are optional but useful. Here is what each one does in plain terms.

You will see a ruf= tag in some records too — it requests forensic (per- message) reports. Most providers no longer send them for privacy reasons, so you can safely leave it out and rely on rua aggregate reports.

How DMARC alignment works with SPF and DKIM#

This is the concept most setups get wrong, so it is worth slowing down on. Passing SPF or DKIM is not enough on its own — DMARC also requires alignment, meaning the domain that authenticated has to match the domain your recipients actually see in the "From" address.

Here is why that matters. A spammer can send mail that passes SPF for their own domain while forging your domain in the visible "From" line. SPF alone would call that a pass, because SPF checks the hidden envelope sender rather than the address your recipient reads. DMARC closes the gap by insisting the authenticated domain and the "From" domain line up. A message satisfies DMARC when either of these is true:

• SPF alignment — the message passes SPF and the domain SPF checked matches the "From" domain.
• DKIM alignment — the message carries a valid DKIM signature and the signing domain matches the "From" domain.

Only one of the two needs to align, but at least one must. Relaxed alignment (the default) accepts a matching organizational domain, so mail.example.com aligns with example.com; strict alignment demands an exact match. Start with relaxed unless you have a specific reason not to — strict alignment breaks more legitimate mail and rarely adds real protection.

The safe rollout, step by step#

DMARC is the rare piece of email infrastructure where the order of operations matters more than the record itself. Follow it in sequence.

1. Publish p=none with a reporting address. Create the TXT record at _dmarc.yourdomain.com with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. This changes nothing about how your mail is handled — it simply turns on the daily aggregate reports. Leave it here for at least a couple of weeks so you capture a full sending cycle.

2. Read the aggregate reports. Providers send XML reports to your rua address once a day. Each report lists the sending IP addresses that used your domain, how many messages each sent, and whether they passed SPF, DKIM, and DMARC alignment. Raw XML is hard to read at a glance, so most people pipe it into a DMARC report parser or a monitoring dashboard that turns it into a plain table. What you are looking for: every legitimate source of your mail — your ESP, your CRM, your transactional provider, your own mail server — showing a DMARC pass with SPF or DKIM aligned. Anything that fails is either a stream you need to fix or spoofing you are glad to catch. The reports are also how you discover sending services you had forgotten about entirely, which is common in any organization that has been around a few years.

3. Fix alignment for every legitimate stream. This is the real work. For each sending service that fails, make sure it authenticates as your domain: add its servers to your SPF record, set up DKIM signing with your domain (not the provider's default), and configure a custom "From" or return-path domain where the provider allows it. DKIM alignment is usually the one to prioritise because a DKIM signature travels with the message and survives forwarding, while SPF alignment breaks the moment mail is forwarded. Most email platforms document exactly which DNS records to add for a custom signing domain — this is where the bulk of the setup time goes. Keep iterating until the reports show all your genuine mail passing.

4. Move to p=quarantine. Once the reports are clean, change the policy so failing mail goes to spam rather than the inbox. You can ease into it with pct= — p=quarantine; pct=25 applies the policy to a quarter of failing mail first — then raise it toward 100 as you gain confidence.

5. Move to p=reject. The destination. p=reject tells receivers to refuse failing mail outright, which is the setting that actually stops spoofing and the one the large providers reward. Only get here after the reports have been clean at quarantine for a while. This is also the policy that fully satisfies the Google and Yahoo sender requirements for bulk senders.

Why DMARC is now required#

DMARC used to be an advanced best practice. Since 2024 it is a gate. Under the Google and Yahoo sender requirements, bulk senders — anyone sending more than 5,000 messages a day to Gmail — must publish a DMARC record with at least a p=none policy, on top of SPF, DKIM, alignment, and one-click unsubscribe. The requirement is a published policy, not necessarily enforcement, but stopping at p=none forever means you get the compliance box ticked while leaving your domain wide open to spoofing. Moving toward reject is what protects your sender reputation and keeps impersonators from burning it on your behalf.

Common pitfalls#

A handful of mistakes account for most broken DMARC setups:

• Jumping straight to p=reject. Without the monitoring phase, you will discover the streams that don't authenticate the hard way — by bouncing your own invoices and newsletters.
• No rua address. A record with no reporting address is flying blind. You cannot fix what you cannot see; always include rua.
• Forgetting a sending service. Marketing platforms, help-desk tools, invoicing systems, and calendar invites all send "as you." Each one needs SPF and DKIM configured for your domain, or it will fail DMARC once you enforce.
• Using strict alignment by default. Strict mode breaks subdomains and many ESP configurations for little benefit. Relaxed alignment is the right default.
• Multiple DMARC records. Only one TXT record may exist at _dmarc — a second one invalidates both. The same is true of SPF.
• Treating DMARC as deliverability. Authentication proves who you are; it does not make you a good sender. A perfectly authenticated message from a domain mailing dead addresses still lands in spam, which is one of the leading reasons legitimate email goes to spam.

Frequently asked questions#

Where exactly do I put a DMARC record?#

It goes in your DNS as a TXT record at the hostname _dmarc.yourdomain.com. In most DNS control panels you create a new TXT record, set the name or host field to _dmarc (the panel usually appends your domain automatically), and paste the value — for example v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. There is only ever one DMARC record per domain; a second one invalidates both.

What does DMARC p=none mean, and is it enough?#

p=none tells receiving servers to take no action on mail that fails authentication and simply send you reports. It is the correct, safe place to start because it lets you monitor without risking your legitimate mail — but it provides no protection against spoofing on its own. It satisfies the letter of the Google and Yahoo requirement for a published policy, yet you should treat it as step one, not the finish line, and progress to quarantine and reject.

How long should I wait before moving from p=none to enforcement?#

Long enough to capture a full sending cycle and confirm the reports are clean — typically a few weeks, sometimes longer if you have many sending services or low-frequency streams like monthly statements. The waiting period isn't arbitrary: you are watching the aggregate reports until every legitimate source shows a DMARC pass with SPF or DKIM aligned. Move up only when nothing legitimate is still failing.

What is the difference between DMARC and SPF or DKIM?#

SPF lists which servers may send for your domain, and DKIM cryptographically signs each message so a receiver can confirm it wasn't forged. DMARC sits on top of both: it ties them to the visible "From" address through alignment, tells receivers what to do when a message fails, and reports back to you. SPF and DKIM do the authenticating; DMARC sets the policy and makes the result enforceable.

DMARC proves your mail is really yours, but authentication is only the entry ticket to the inbox. The free plan runs the full verification pipeline so you strip dead addresses and spam traps out of your list before they bounce — because a trusted identity only earns placement when the list behind it is clean.