What this is. Find out what your domain already says before changing anything. Most domains have something — often set years ago by someone who has left, or added automatically by a mail provider.

What you do. Look up your domain, or paste a record you already have. Either way it is checked against RFC 9989 right here.

dig +short TXT _dmarc.yourdomain.com

  # Windows
  nslookup -type=TXT _dmarc.yourdomain.com

No record change in this phase.

What this is. Two things, neither of which can break your mail.

The first is asking mail providers to report to you — a daily summary of who is sending as your domain, including senders you have forgotten and anyone impersonating you. Nothing about how your mail is treated changes.

The second is shutting down subdomains that do not exist. If payroll.yourdomain.com has never existed, nothing legitimate can come from it — a name with no DNS record cannot have SPF or DKIM. Technically these are names that return NXDOMAIN: the DNS answer meaning "no such name". Phishing uses invented subdomains precisely because they have historically been unprotected. This is the safest change in the whole process, which is why it happens now rather than at the end.

What you do

1. Decide where reports go. Two paths:
   • A reporting service (most people). They give you an address for rua= and handle the rest — follow their setup steps, not ours. dmarcian, Postmark DMARC and URIports all have free tiers that suit a single domain. Listed because “use a service” is useless advice on its own — not as endorsements, and none is affiliated with this site.
   • Your own mailbox. You will get XML attachments daily from dozens of providers. Workable for one domain with light mail; unreadable at volume.
2. Publish as a TXT record at _dmarc.yourdomain.com.
3. Wait and read.

What this is. Reports now show legitimate senders failing. This phase fixes them. Your DMARC record doesn't change — you stay in watch-only mode while the real work happens elsewhere. This is usually the longest phase, and the record sits still throughout.

What you do. For each failing sender, get SPF or DKIM passing and aligned. Aligned means the domain that authenticated matches the domain in the From: address. A sender can pass SPF and still fail DMARC by passing for the wrong domain — the most common source of confusion here.

You only need one of them

DMARC passes if SPF passes and aligns, or DKIM passes and aligns. Both is not required.

Chase DKIM first. When mail is forwarded, SPF breaks — the forwarding server isn't in your SPF record, and nothing you publish fixes that. DKIM survives forwarding. A sender passing only SPF will fail intermittently in ways you can't resolve, so DKIM is where limited vendor-wrangling time is best spent. Keep SPF correct too; just don't rely on it alone.

Optional, for diagnosis

ruf= requests individual failure reports; fo=1 asks for one whenever either check fails rather than only when both do. These can contain message headers and sometimes body content belonging to other people, and many providers won't send them at all for that reason. Turn it off when you're done diagnosing.

What this is. Failing mail goes to spam instead of the inbox. Recoverable, which is why it comes before rejection.

What replaced the old percentage ramp. Previously you ramped with pct=10, then 25, 50, 100. pct= was removed and does nothing — leaving it in doesn't slow anything down; receivers ignore it and apply your policy in full immediately.

The replacement is t=y, and its behaviour is easy to misread: it applies the policy one level below the one you published. It is not an off switch.

Nothing happens to your mail. Reports show exactly what would be quarantined. This is the only genuinely zero-impact step in the ramp. Sit here 1–2 weeks.

Dropping t=y is the moment real mail is first affected.

Holding subdomains back

If Phase 1's reports showed an existing subdomain still failing, it would otherwise be dragged to quarantine alongside the parent. sp=none holds it:

Only use this if reports showed a subdomain sending. Don't set it because one might.

What this is. Failing mail is refused outright rather than spam-foldered. Nobody can retrieve it.

Failing mail is quarantined — the same disposition as Phase 3b. Because the effect on mail is identical, moving from 3b to 4a carries no new risk; what changes is what you are signalling and what the reports show you about rejection impact. Sit here 1–2 weeks.

Bringing subdomains along

Once reports show existing subdomains are clean, drop sp= so they inherit p=reject, or state it explicitly:

Optional. You can run a fully protected domain without any of these.

adkim= / aspf= — how exact alignment must be

Default r (relaxed): mail.yourdomain.com counts as matching yourdomain.com. s (strict) requires an exact match.

Strict alignment most often breaks SaaS vendors, because they sign with their own subdomain:

From:  alerts@yourdomain.com
DKIM:  d=mailer.yourdomain.com

relaxed → matches, passes
strict  → doesn't match, fails

Only pursue strict if you specifically need to stop subdomains authenticating for the parent. Review every vendor first, and introduce it back at p=none and watch — never as an edit to a live p=reject record.

fo= — which failures generate a report

Only does anything when ruf= is set. 0 (default) both must fail; 1 either fails; d DKIM failed; s SPF failed. Combine with a colon: fo=d:s. fo=1 is the useful one.

ruf= — failure reports

Covered in Phase 2. A diagnostic tool, not a permanent setting.

psd= — public suffix domains

Only relevant if other organisations register names under your domain — a registry, or something like co.uk. Values y, n, u (default). If you are not a registry, ignore it.

Multiple report destinations

Comma-separated; every external domain needs its own authorisation record (see “Reports aren't arriving” above):

Tags that no longer exist

pct=, rf=, ri=. Remove them. pct= especially, because it implies a gradual rollout that isn't happening.

A domain that sends no mail at all

Tempting to jump straight to reject, but “we don't use this domain” is exactly the belief that turns out wrong — usually a campaign someone ran years ago. Run a shortened Phase 1 (two weeks) to confirm, then go straight to reject:

Pair it with an SPF record authorising nothing, and a null MX:

A subdomain with its own DMARC record

_dmarc.news.yourdomain.com overrides the parent completely — your sp= is ignored for it. Check for these before assuming the parent is in charge.

Mailing lists

Lists that modify the subject or add a footer break DKIM, and mail arrives from the list server so SPF doesn't align. At p=reject, your posts to those lists may be rejected. Nothing on your side fixes it; well-run lists rewrite the From: address to handle it.

Third-party senders you can't configure

If a vendor can't do aligned DKIM for your domain: have them send from their own domain, give them a subdomain with its own DMARC record set to none, or replace them. No tag makes unaligned mail pass.