DMARC record examples to copy (and understand)

v=DMARC1; p=none; rua=mailto:dmarc@example.com

Template 2 — Quarantine (first enforcement)

Once the sources are aligned, the policy moves up a notch. Failing mail goes to junk instead of the inbox. Here we add sp and np to cover subdomains, and t=y to signal a test phase.

v=DMARC1; p=quarantine; sp=quarantine; np=reject; t=y; rua=mailto:dmarc@example.com

np=reject goes in right away: non-existent subdomains carry no legitimate mail, so they can be locked down immediately (see the subdomain policy). Once reports are clean and test mode is reassuring, t=y comes out.

Template 3 — Reject (the target)

Maximum enforcement. Mail forged in the domain's name is refused before it arrives. This is the goal of most deployments, to reach once the reports have been proven clean for several weeks.

v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@example.com

Symmetric and clean: root, existing and non-existent subdomains, all at reject. If a legitimate subdomain needs room, the fix isn't lowering sp for everyone — it's giving that subdomain its own dedicated record. The full sequence to get here without breakage is described in getting to p=reject without breaking email; the readiness checklist answers the question of whether the moment has come.

Template 4 — Parked or mail-less domain

Some domains never send mail at all (defensive brand, old name, registration). Leaving one without DMARC turns it into a free impersonation target. It takes the strictest policy from the start, with no observation phase: by definition, no legitimate email can be blocked.

v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@example.com

It's the same as the reject template, but it can go in immediately, without passing through none or quarantine, since there's nothing to observe. A protected parked domain is one fewer door for fraudsters, and it costs nothing but the two minutes it takes to publish the record.

Where to publish the record

The thing that trips up most beginners isn't the value, but where it goes. The record is published at the DNS host (the one managing the zone), as a TXT record, on the name _dmarc. Depending on the interface, the field takes either the full name _dmarc.example.com, or simply _dmarc (the interface appends the domain automatically). The value is the string v=DMARC1; …, with no quotes to add by hand in most interfaces.

One classic mistake to sidestep: the record does not go on example.com directly, but on the _dmarc sub-name. A DMARC record placed at the root will never be found by receivers. One more point: DNS propagation isn't instant — after publishing, a few minutes to a few hours pass before the new record is visible everywhere, depending on the zone's TTL. Five minutes in is far too early to conclude it "doesn't work"; the check belongs after propagation completes.

Per-provider settings

The DMARC record itself is identical whatever the email provider — it's a property of the domain, not the mail platform. What changes from one provider to another is the alignment (SPF/DKIM) that DMARC verifies. A few pointers:

• Google Workspace: DKIM signing is enabled from the admin console (Apps → Google Workspace → Gmail → Authenticate email), which yields a DKIM record to publish. Once DKIM is aligned to the domain, the DMARC above works as is.
• Microsoft 365: DKIM is enabled in the security center (or via PowerShell) and signs with the domain. SPF for Microsoft goes through include:spf.protection.outlook.com. The SPF detail is in SPF for Microsoft 365 and Google Workspace.
• OVH, Scaleway and EU hosts: the mechanics are the same — the _dmarc TXT goes in the DNS zone, and the sending platform must sign DKIM with d=example.com.
• Third-party platforms (marketing, billing, transactional): each provides its own branded DKIM procedure. That's where the real alignment happens, source by source.

In other words, there's no "special Gmail DMARC record" or "special Microsoft" one: there's a DMARC record for the domain, and alignment work to do at each sender. This is worth internalizing, because it dissolves a common source of confusion. People search for a provider-specific record and find contradictory advice; the contradiction vanishes once it's clear the record is always the same and only the alignment plumbing differs. The single record gets set right, then the senders are worked through one at a time until every legitimate source shows an aligned pass in the reports.

Relaxed or strict alignment (adkim / aspf)

Two optional tags deserve a word, since they show up often in templates found online: adkim and aspf, which control alignment strictness. In relaxed mode (r, the default), a subdomain counts as aligned with the organizational domain: a DKIM signed d=mail.example.com aligns a From: at example.com. In strict mode (s), the two must match exactly.

The practical advice: staying relaxed absent a specific reason. Strict mode breaks perfectly legitimate setups (platforms signing with a technical subdomain) and only helps in very pointed security scenarios. Without a clear reason to go strict, there's no need for it — which is why none of the templates above mention these tags: their absence is the right setting for nearly every domain.

Is ruf (forensic reports) worth adding?

Many old examples include a ruf= tag alongside rua=. In 2026, that's rarely useful: most major providers (Google, Microsoft, Yahoo) no longer send forensic reports, and those raise privacy concerns, since they can contain headers or even snippets of real messages. Absent a specific diagnostic need and a controlled GDPR framework, ruf is best left aside at the start. The difference between the two report types is detailed in RUA vs RUF, and the privacy angle in forensic reports and GDPR. That's why none of the templates above contain ruf: starting simple avoids collecting sensitive data nobody has a use for.

Common syntax mistakes

• Forgetting rua. A DMARC with no report address "works," but leaves no visibility: who sends in the domain's name, and whether hardening is safe, both stay invisible.
• Wrong host name. The record goes on _dmarc, not the domain root.
• Mixing several DMARC records. There must be only one TXT record starting with v=DMARC1 on _dmarc. Two records = undefined behavior, often ignored.
• Copying a rua address from another domain. Sending reports to dmarc@other-domain.com requires authorization on the receiving domain's side (see configuring the rua address). To start, an address on the domain itself is the safe choice.
• Leaving t=y in place. Test mode is a phase of the ramp, not a permanent setting.

The record as managed configuration

One last habit separates the teams that stay calm from the teams that panic months later: keeping a written trace of every change to the DMARC record. DNS interfaces rarely offer a history — once a value is overwritten, the previous one is gone, along with the reasoning behind it. The date of each edit, what changed and why, belongs wherever the team already documents its infrastructure. Ownership of the _dmarc entry deserves an explicit agreement too, so a well-meaning colleague doesn't "clean up" a tag they don't recognize. DMARC edits are rare by nature — which is exactly why memory fails: when a deliverability incident strikes, being able to answer "what did the record say before, and who changed it?" turns an afternoon of archaeology into a five-minute check.

What next?

A pasted template is only a beginning. The real work — aligning each source so hardening blocks no one — starts after. Once the record is published, the free DMARC analyzer checks it from a receiver's point of view: it confirms the syntax is valid, the policy is read correctly, and above all that the sources align as expected. It's the fastest way to turn a generic template into protection genuinely fitted to a domain — and to catch the typo or duplicate record that would otherwise sit unnoticed for months.