English Nederlands Español Italiano 日本語 Français
Log in

DMARC Guidelines

DMARC (Domain-based Message Authentication, Reporting & Conformance) is the policy layer that sits on top of SPF and DKIM. It tells receiving mail servers what to do when a message fails authentication, and asks them to report back on what they saw.

Think of it like a policy handed to the doorperson

DMARC is like a policy handed to a venue’s doorperson: “check ID using SPF or DKIM; if it doesn’t check out, do this — let it through, send it to a side room, or turn it away — and send me a report either way.” SPF and DKIM do the checking; DMARC decides what happens next, and asks for the paperwork.

Why it matters

Before DMARC, there was no standard way for a domain owner to tell the world “reject anything claiming to be from me that doesn’t check out.” Receivers had to guess, using ad hoc spam filtering, which is one reason email has historically been such a common channel for impersonation and phishing. DMARC gives domain owners an explicit, machine-readable way to say what should happen to failing mail, and gives them visibility into who is sending as their domain through its reporting.

How it works

A DMARC record is published in DNS at _dmarc.yourdomain.com. It names a policy (none, quarantine, or reject) and an address to receive aggregate reports. Every domain should have one — at minimum p=none with a reporting address, so you start receiving visibility into your mail flows even before enforcing anything.

DMARC policies are inherited by subdomains by default, but a subdomain that actually sends mail should still have its own explicit record for clarity, and to override the inherited policy if needed.

I need more information

The plain-language version above covers what most people need. The rest of this article is the detailed reference: exact record syntax, optional tags, and enforcement guidance.

General

  • Every domain should have a DMARC record: at minimum p=none with an aggregate (rua) reporting address.
  • A domain should only ever have one DMARC record, published at the host _dmarc.
  • DMARC records are published in DNS as TXT records (or via a CNAME pointing at one).
  • DMARC record syntax is case-sensitive and should be validated with tooling before publishing.
  • Keep records clean: don’t include tags at their implicit/default value (for example adkim=r or aspf=r are both already the default, so stating them adds nothing).

Configuration

The minimum valid record needs a version tag and a policy tag:

v=DMARC1; p=<policy>; rua=mailto:<reporting-address>

  • v=DMARC1; — the version tag, required.
  • p=none|quarantine|reject; — the policy tag, required.
  • pct= — defaults to 100 (the policy applies to 100% of failing messages) if left out; only set it explicitly if you deliberately want a partial rollout.
  • aspf=r|s and adkim=r|s — alignment mode for SPF and DKIM respectively (relaxed or strict); these only affect how alignment with the Header.From domain is evaluated, not whether SPF/DKIM themselves pass.
  • ruf= — forensic report address. If it isn’t set, the related fo= (forensic options) tag has nothing to act on and can be left out.
  • Avoid ri= (reporting interval) and rf= (reporting format) — most reporters ignore these tags, so they add clutter without effect.
  • Don’t set sp= on a subdomain’s own DMARC record — that tag is for the organisational domain to describe its subdomains, not for a subdomain to set for itself.
  • If your rua or ruf address uses a different domain than the one being protected, that other domain must publish an explicit authorisation record, so it can’t be used to redirect reports without consent: <domain-collecting-the-data>._report._dmarc.<domain-being-protected> as a TXT record with value v=DMARC1;.

Security

  • A policy of p=none is monitoring-only: it does not stop abuse by itself, it only gives you visibility.
  • Move towards enforcement once your reports show your legitimate senders are all passing: p=quarantine (spam folder) at minimum, ideally p=reject (blocked outright) as the end goal.

References & further reading

  • RFC 7489 – Domain-based Message Authentication, Reporting, and Conformance (DMARC): datatracker.ietf.org/doc/rfc7489. Note that RFC 7489 is published as an Informational, Independent Submission rather than on the IETF Standards Track (unlike SPF’s RFC 7208 or DKIM’s RFC 6376) — that’s simply how DMARC entered the RFC series, and it doesn’t make the document any less authoritative in practice: it’s still the specification the whole industry treats as the DMARC standard.