How to Set Up DMARC, Step by Step

Last updated: October 2026

DMARC is the record that turns email authentication from a suggestion into a policy. It tells Gmail, Outlook and Yahoo what to do with mail that claims to be from your domain but fails the checks — and it sends you reports on who's sending as your domain in the first place. Setting it up takes ten minutes. Setting it up safely takes a staged rollout over a few weeks, and this guide covers both.

Before the record: the prerequisites

DMARC doesn't authenticate anything by itself. It judges the results of SPF and DKIM — so both need to exist first:

• SPF: one single record at your domain root listing every service that sends as you. Not two records — two SPF records break the check entirely.
• DKIM: enabled inside every sending platform, with the records each platform gives you published in DNS.
• Alignment: DMARC passes when SPF or DKIM passes and the domain it validated is the same as your visible From: domain. This is why platform DKIM matters so much — a Mailchimp campaign can pass SPF for Mailchimp's domain and still fail DMARC if it isn't signed with yours. (Our Mailchimp DKIM guide covers that platform's setup.)

If SPF and DKIM aren't in place yet, the InboxProof wizard builds both for your exact set of senders, then hands you the DMARC stages below with your domain filled in.

Step 1: Create a report address

DMARC reports need somewhere to go. Create a dedicated mailbox or alias on your domain — dmarc@yourdomain.com is the convention. It must be a real, monitored address: these reports are the entire point of stage one, and an unmonitored report address is how businesses sit at p=none for years learning nothing.

Expect roughly daily aggregate reports (XML files, usually compressed) from Google, Microsoft, Yahoo and others. Nobody reads them raw — free tools exist that convert the XML into a readable summary, and the Email Authentication Kit includes a plain-English guide to reading your first one.

Step 2: Publish the monitoring record

Add a TXT record in your DNS with:

• Host / Name: _dmarc
• Value:

Reading it left to right: v=DMARC1 is the version tag and must come first. p=none is your policy — "take no action on failing mail, just report it." rua= is where aggregate reports go.

At this stage nothing changes for your recipients. Mail that fails is still delivered. You're buying visibility: within a few days, the reports show every service sending as your domain and whether each one passes. This is also when forgotten senders surface — the old newsletter tool, the website's forms, the invoicing app. Fix what the reports reveal before moving on: authenticate each legitimate source with SPF and DKIM, and investigate sources you don't recognize.

Step 3: Move to quarantine

When one to two weeks of reports show every legitimate sender passing consistently, replace the record's policy:

Now mail that fails authentication is treated as suspicious — typically filed to spam rather than the inbox. If you want an extra-cautious ramp, add pct=25 and raise it (50, then 100) over the following weeks: the policy then applies to only that percentage of failing mail.

Keep reading reports at this stage. A platform that suddenly starts failing usually means something changed — a new sending service, an edited record — and the reports will show you which source it is.

Step 4: Move to reject

At p=reject, receivers refuse failing mail outright. This is the only stage that actually stops strangers from spoofing your domain — and it's the stage Google, Yahoo and Microsoft's bulk-sender rules are ultimately steering everyone toward (their compliance floor is p=none, but the protection only exists at reject). Move here when reports have been clean for several consecutive weeks, not on a schedule. Our companion guide goes deeper on what each policy does and how to judge readiness.

Step 5: Keep it alive

DMARC is not set-and-forget, for one practical reason: every new tool that sends as your domain changes the equation. A new invoicing app, a new helpdesk, a marketing platform migration — each needs DKIM configured and a place in your SPF record (mind the 10-lookup limit) before its first send, or its mail starts failing a policy you set to reject. The five-minute habit that prevents almost all of it: "new sender" always triggers "update the authentication worksheet first."

Subdomains, briefly: by default, your record's policy covers subdomains too. The optional sp= tag sets a different policy for subdomains — useful if a platform sends from a subdomain you don't fully control. Most small businesses can ignore it; the p= policy alone is enough.