InboxRatio
Check your domain

How to set up DMARC: a step-by-step walkthrough from nothing to published

Publishing a working DMARC record takes one DNS TXT entry and about fifteen minutes. That's the honest scale of the task people put off for quarters — the setup itself is small; what takes longer is the monitoring phase that follows. This walkthrough covers the setup: the prerequisites, building the record, publishing it in DNS, and verifying that receivers can see it.

This is the deployment lane of our DMARC series. What the policy levels mean and when to ratchet them up is covered separately, as are diagnosing failures and reading the reports that will start arriving. Here, we get you from nothing to published and verified.

Step 1: confirm SPF and DKIM exist first

DMARC doesn't authenticate anything itself — it evaluates the results of SPF and DKIM and checks their alignment with your From domain. Publishing DMARC over broken underlying mechanisms just documents your failures, so verify both before touching DMARC:

  • Run your domain through the SPF checker. You want a single valid record that includes every service sending as your domain, within the 10-DNS-lookup limit.
  • Check DKIM with the DKIM checker — you'll need your selector, which your ESP's authentication settings page shows (it's also visible as s= in the DKIM-Signature header of any message you send yourself).
  • Critically, confirm DKIM signs with your domain. In your platform's settings this is usually called custom domain signing or domain authentication; in a message header it's the d= value. A signature with the ESP's own domain works cryptographically but will never align for DMARC.

Both green? Continue. If not, fix these first — the rest of the walkthrough assumes them.

Step 2: decide where reports will go

DMARC's reporting is the reason to deploy it before enforcement makes sense. Aggregate reports arrive as XML attachments, typically daily, from every major receiver your mail touches. Decide now which mailbox receives them.

Two workable patterns. Simplest: a dedicated mailbox like dmarc-reports@yourdomain.com — fine to start, and you can read the XML by hand while volume is low. More sustainable: a report-processing service (free tiers exist) that parses the XML into dashboards, with its ingestion address as your rua target. You can also list both, comma-separated.

One technical wrinkle: if reports should go to a different domain than the one publishing the record (say, reports for example.com going to example-dmarc.net), the receiving domain must publish a small authorization record. Keep the report address on the same domain and the wrinkle never applies.

Step 3: build the record

A first DMARC record should be monitoring-only:

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

Three tags, in order: the version (always DMARC1), the policy (none = deliver failing mail normally, but report it), and the aggregate-report address. That's a complete, valid, useful record.

Worth considering now rather than later:

  • sp= — subdomain policy. If your subdomains send no mail at all, sp=reject from day one protects them while the root stays at none.
  • adkim= / aspf= — alignment strictness. The default (relaxed) is correct for almost everyone; don't set strict unless you know precisely why.
  • What you should not add: ruf= (forensic reports — most large receivers no longer send them), and pct= (meaningless at p=none; it becomes a rollout dial later).

The DMARC generator builds this record interactively and catches syntax mistakes before they reach DNS — tag order, missing semicolons, malformed mailto: URIs.

Step 4: publish the TXT record in DNS

In your DNS provider's console (wherever your domain's zone lives — registrar, Cloudflare, Route 53, your host's panel), create a new record:

  • Type: TXT
  • Name / Host: _dmarc — most consoles append the domain automatically, making the full name _dmarc.example.com. If yours wants the fully qualified name, enter _dmarc.example.com.
  • Value: the record string from step 3, exactly, starting with v=DMARC1.
  • TTL: the default (often 1 hour) is fine.

The two mistakes that account for most broken deployments happen right here: publishing at the domain root instead of the _dmarc label, and ending up with two DMARC records (an old one from a previous attempt plus the new one — receivers treat duplicates as no valid record at all). Check for an existing record before saving.

Step 5: verify it resolves

DNS changes propagate on the record's TTL — usually minutes. Then run your domain through the DMARC checker, which queries live DNS and validates what it finds: record present at the right label, exactly one of it, syntax parseable, policy and report address recognized. If you prefer the command line, dig TXT _dmarc.example.com +short shows the raw published string.

Seeing the record resolve correctly is the finish line for setup. For the full-stack view — SPF, DKIM and DMARC together, the way a receiver evaluates them — run the email authentication checker once and screenshot the result; it's your baseline.

Step 6: send a test and read the header

DNS being right doesn't prove the end-to-end flow is. Send a real message from your sending platform to a mailbox you control at Gmail, open the raw source, and find the Authentication-Results header. You want dmarc=pass. Decode the whole thing with the email header analyzer if raw headers aren't your comfort zone.

Seeing dmarc=fail here while your record checks out usually means an alignment problem — typically the DKIM d= domain issue from step 1. The failure-diagnosis guide covers the causes systematically.

Step 7: let reports accumulate, then actually read them

Within a day or two of publishing, the first aggregate reports arrive. Give them two to four weeks to accumulate a representative picture, then work through them with one question: what sends mail as my domain, and does it pass with alignment? Expect surprises — the forgotten survey tool, the ancient monitoring relay, a partner mailing "from" you. Every legitimate source that fails alignment is a work item; unrecognized sources are what DMARC exists to shut down.

Step 8: plan the ratchet

Setup complete is not deployment complete. The record you published protects nothing at p=none — it observes. Once reports show your legitimate mail passing aligned consistently, move to p=quarantine, then p=reject, gating each move on clean reports rather than elapsed time. The staging logic, pct= sampling and subdomain strategy are the policy guide's territory. Put the first report-review date in a calendar before you close this tab; unread reports are how deployments die at p=none.

Related guides

About this guide

Written by InboxRatio Editorial. The procedure reflects RFC 7489 and current receiver behavior, and matches how we configure DMARC on our own test domains for every benchmark cycle — this is the walkthrough we actually use, not a theoretical one.

Methodology

Every InboxRatio deliverability test sends from domains with SPF, DKIM and DMARC configured and verified in advance, because receivers treat unauthenticated mail differently and our platform comparisons must hold authentication constant. The full testing protocol is documented at how we test.

Last updated

21 August 2026. Procedure re-verified against provider documentation quarterly.

Frequently asked questions

How long does it take to set up DMARC? The record itself: under an hour including DNS propagation, assuming SPF and DKIM already work. The full deployment — monitoring reports and ratcheting to enforcement — typically runs weeks to months depending on how many systems send as your domain.

What should my first DMARC record be? v=DMARC1; p=none; rua=mailto:you@yourdomain.com — monitoring mode with reports flowing to an address you'll actually read. Enforcement comes later, informed by what the reports show.

Where exactly does the DMARC record go in DNS? A TXT record at the _dmarc label of your domain: _dmarc.example.com. Not at the root, and never in duplicate — two DMARC records invalidate each other.

Do I need DMARC on subdomains too? Subdomains inherit the root policy unless you set sp= or they publish their own record. If a subdomain sends mail through a different platform, watch its results in your reports; if your subdomains send nothing, sp=reject closes them off immediately.

Do I need to buy a DMARC service? Not to deploy. The record is free, and low-volume senders can read XML reports manually. Report-parsing services earn their keep when report volume grows or multiple domains are involved — a convenience for the monitoring phase, not a prerequisite for setup.

Gmail says dmarc=fail but my record is published — why? A published record makes DMARC evaluated, not passed. Failure means no aligned SPF or DKIM pass existed — most often because DKIM signs with your ESP's domain rather than yours. Re-check step 1's d= requirement before anything else.

Fifteen minutes of setup buys you the receiver-side view of everything sending as your domain — publish the p=none record today and schedule the first report review before closing the tab. Start with the DMARC generator and verify with the DMARC checker before you close the DNS console.