How to set up DMARC

DMARC performs no authentication of its own. It reads the results of SPF and DKIM, then asks a second question those two never ask: does the domain that passed match the domain a human sees in the From header? That second question is alignment, and it is the whole point of DMARC.

So a DMARC record on a domain with neither SPF nor DKIM is not a security control, it is a report of your own mail failing. Publish SPF, turn on DKIM signing at whichever platform sends your mail, and confirm both resolve before you go further.

Two of those choices matter more than the rest. p=none is where a first setup starts: receivers deliver everything as before and simply tell you what they saw, which is exactly what you want while you still have unknown senders. The rua address is where the daily aggregate reports go, and a record without one produces no evidence at all, which is the quiet way a DMARC project stalls for a year.

Aggregate reports arrive as XML, one file per receiver per day, and reading them by hand stops being practical almost immediately. Most people point rua at a monitoring service for that reason. If you point it at an address on a different domain, that domain has to publish an authorisation record before receivers will send anything, which is the third row in the mistakes table below.

The record goes at whichever host answers for the domain, which is not always where you bought it. Run dig NS yourdomain.com, or use the DNS lookup, and match the result. There are three ways to get the record in once you know where it belongs.

Saving a record proves the provider accepted it, not that the internet can see it. Check from outside your own account, because that is where the two common failures show up: a record sitting in a zone nothing is delegated to, and a record still inside the old TTL. If it does not resolve within an hour, the host is almost always the problem rather than the syntax.

Reading the aggregate reports is the part that takes weeks, and the part that decides whether enforcement breaks your mail. Aggregate reports name every IP and service sending as your domain and show whether each one passed SPF and DKIM with alignment. Almost every domain finds senders nobody remembered: an invoicing tool, a recruiting platform, a form on the marketing site, a newsletter someone set up years ago.

Work through them one at a time. Each legitimate sender needs either an SPF authorisation or a DKIM signature that aligns with your domain, and the provider's own documentation is usually where that lives. Anything you do not recognise and cannot trace is the spoofing DMARC exists to stop, and it is the reason to keep going. To inspect one delivered message rather than the aggregate picture, see how to check DMARC alignment from a delivered message.

A domain sitting at p=none is not protected. It is instrumented. Receivers report on the spoofed mail and then deliver it anyway, so the only thing that changes at enforcement is that the spoofing actually stops.

Move in stages and watch the reports at each one. p=quarantine sends failing mail to spam, which is recoverable if you missed a sender. p=reject refuses it, which is not. If you run subdomains that send mail, the sp tag sets their policy separately, so you can hold a subdomain at monitoring while the parent domain enforces.

One tag to ignore if an older guide recommends it: pct, which applied the policy to a percentage of failing mail. Receivers implemented it inconsistently and RFC 9989 retires it, along with rf and ri. Stage the rollout by moving the policy, not by sampling.

The DMARC record itself is the same wherever your mail is hosted: one TXT record at _dmarc, published in DNS, not in the mail platform's admin console. What changes per platform is the DKIM setup that has to happen first, and where you turn it on.

Setting up DMARC for Microsoft 365 covers the custom-domain case and the onmicrosoft.com domains Microsoft handles differently. DMARC for Google Workspace covers the Admin console path and Gmail's sender requirements.