Prerequisites

SPF and DKIM must be in place first. DMARC on its own does nothing — it only evaluates what those two deliver. More important than their mere existence is alignment: the envelope domain validated by SPF, or the d= domain signing under DKIM, must match the domain in the visible From header. Either one of the two is sufficient.

Phase 1 — Publish the record and observe

Always start with p=none. This policy changes nothing about delivery but ensures you receive reports.

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

The most important tags:

  • v=DMARC1 — must be the first tag, otherwise the record is invalid
  • p= — the policy: none, quarantine or reject
  • rua= — address for the daily aggregate reports. Without this tag you are flying blind
  • sp= — separate policy for subdomains. If absent, p= applies there too
  • adkim= / aspf= — alignment mode, r (relaxed, default) or s (strict)
  • pct= — share of messages the policy is applied to
  • ruf= — forensic reports. Most providers no longer send them anyway, for privacy reasons

Phase 2 — Evaluate the reports

After a day or two the first aggregate reports arrive: XML files summarizing which IPs sent using your domain and how SPF and DKIM turned out. This is where you find the systems nobody remembered — monitoring scripts, the invoicing software, an old contact form.

Observe for two to four weeks. The goal is for every legitimate sender to achieve either SPF or DKIM alignment. Do not tighten anything while legitimate sources still fail.

If rua points at a foreign domain, that domain must authorize acceptance — otherwise compliant receivers send no reports at all:

yourdomain.com._report._dmarc.provider.com. IN TXT "v=DMARC1"

Phase 3 — Tighten to quarantine

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:dmarc@yourdomain.com"

Unauthenticated messages now land in the spam folder. If you want to move carefully, use pct=25 and raise it in steps. Observe for another two to four weeks.

Phase 4 — p=reject

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc@yourdomain.com"

Only here does real protection begin: messages claiming to come from your domain that cannot prove it are rejected. Everything short of this is observation, not defence.

Enable strict alignment (adkim=s, aspf=s) only at the end, and only if every system works with exactly the main domain. Where a subdomain is used in the envelope from, aspf=s breaks delivery.

For domains that never send mail

Domains that send no email at all are especially popular spoofing targets — there are no reports that would raise an eyebrow. For those, apply the strictest policy immediately, with no observation phase:

yourdomain.com. IN TXT "v=spf1 -all" _dmarc.yourdomain.com. IN TXT "v=DMARC1; p=reject; sp=reject;" *._domainkey.yourdomain.com. IN TXT "v=DKIM1; p="

Common mistakes

  • Staying at p=none permanently. By far the most common state — and it protects against nothing.
  • pct=0 — looks like a policy, applies to not a single message.
  • sp=none alongside a strict p= — opens every subdomain to attackers.
  • rua pointing at a mailbox nobody reads. Aggregate reports are XML; use an analysis tool or a dedicated address.
  • Moving to reject too early, before all sending systems are known. The safe route runs through the reports.

Testing

Send an email to hello@analyzemy.email. The report shows policy strength, alignment, all audit findings, and actually resolves the authorization records for external report destinations in DNS.

Verify your work

Once the DNS change is live, send an email to hello@analyzemy.email and check in the report whether it took effect.

Analyze your email now

Last updated: · All guides