DMARC Record: Format, Examples & How to Add One

A DMARC record is one line of DNS that tells email receivers what to do with mail that pretends to be from your domain — and where to send you the proof that it happened. It lives in a single TXT record at _dmarc.yourdomain.com. If you're new to the whole chain, SPF, DKIM & DMARC explained covers how the three fit together first.

The DMARC record format

The DMARC record is made up of several tags separated by a semicolon. While there are many available tags, the ones you'll actually use are:

• v=DMARC1 — the "version" tag. Required, and always first in a DMARC record.
• p= — the policy tag: what should an email receiver do with a message that does not pass SPF and/or DKIM validation — none, quarantine, reject.
• rua= — where should aggregate reports be sent — usually an email address that can receive XML files.
• sp= — policy for subdomains.
• adkim= / aspf= — how aligned the sender's identity must be. Valid values are "r" (relaxed, the default) or "s" (strict).
• np= — policy for non-existent subdomains. This is often considered the simplest way to spoof your domain.

Every tag, and whether you need it

Only v= and p= are required. Everything else is optional, and a record with two tags is perfectly valid — it's just blind, because it asks for no reports.

• v=DMARC1 — required, and it must be first and spelled exactly like that. A record starting anything else is not a DMARC record and is ignored entirely.
• p= — required. none, quarantine or reject. It is the only tag that changes what happens to mail.
• rua= — one or more mailto: addresses for aggregate (XML) reports, comma-separated. Optional in the spec, mandatory in practice: without it you enforce a policy with no idea what it's doing.
• ruf= — addresses for forensic, per-message reports. Most large providers stopped sending these years ago over the privacy implications, so expect little to arrive. Safe to omit.
• sp= — the policy for your subdomains. Without it, subdomains inherit p=. Set it explicitly when you want a different answer for them.
• np= — the policy for subdomains that don't exist in DNS at all. Attackers favour these precisely because nobody is looking at them; np=reject costs nothing and closes the door.
• adkim= / aspf= — alignment mode, r (relaxed, the default) or s (strict). Relaxed accepts a subdomain of your organisational domain; strict demands an exact match.
• pct= — the percentage of failing mail the policy is applied to, historically used to ramp enforcement gradually. Note that DMARCbis (RFC 9989) removes it, so treat it as a legacy control rather than the basis of your rollout plan.
• fo=, rf=, ri= — forensic options, report format and reporting interval. Almost nobody needs to touch these; the defaults are sensible and ri= in particular is a hint receivers are free to ignore.

DMARC record examples

Below are three minimal DMARC records. Copy & paste and replace "yourdomain.com" with your actual domain name, and update the "reports@" part to point to wherever you want your reporting service to receive reports.

Minimal monitoring (start here):

v=DMARC1; p=none; rua=mailto:reports@yourdomain.com

Quarantine, after your senders align:

v=DMARC1; p=quarantine; rua=mailto:reports@yourdomain.com; sp=quarantine; adkim=s; aspf=s

Reject all non-senders (full enforcement):

v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com; sp=reject; adkim=s; aspf=s; np=reject

A domain that never sends mail — a parked domain, a redirect, an old brand you still own. There are no legitimate senders to break, so start at full enforcement on day one:

v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com; sp=reject; np=reject

What the policy actually does

DMARC does not check whether a message is spam, and it does not check whether the sender is trustworthy. It asks one question: does the domain in the From address the reader sees match a domain that already passed SPF or DKIM? That match is called alignment, and it's the whole mechanism.

A message passes DMARC if either path aligns — SPF passing for your domain, or a DKIM signature carrying your domain. It only fails when both miss. That redundancy matters more than it sounds: SPF breaks whenever a message is forwarded by a server you never authorised, while a DKIM signature survives the trip. Domains publishing both have two independent chances for real mail to authenticate; domains relying on SPF alone are the ones whose forwarded mail mysteriously disappears.

Then, and only then, p= decides the consequence:

• p=none — do nothing differently, but send the reports. It protects nobody. It is a measurement tool, and it is where every rollout starts.
• p=quarantine — treat failing mail as suspicious, in practice the spam folder. A spoofed message still reaches your user, one click from the inbox.
• p=reject — refuse the message at the SMTP conversation. It never exists as far as the recipient is concerned. This is the only value that actually stops impersonation, and it is the destination.

The staged walk between them is the subject of DMARC policies explained.

How to add your DMARC record to DNS

1. Log into your DNS provider's control panel and select "Add New Record".
2. Select "TXT".
3. Enter the following information: "_dmarc" in the host field, and paste the entire DMARC record value in the value field, including quotes if requested.
4. Set the TTL (time to live) to however long your provider defaults.

Once you've added the record, it'll take anywhere from a few minutes to a few hours to reach most major email providers. You won't need to change anything else about your email configuration — DMARC simply adds a layer of protection on top of what you already have.

The host field, which is where this usually goes wrong

Nearly every DNS panel appends your domain to whatever you type in the host or name field. So the correct entry is _dmarc on its own. Typing the full _dmarc.yourdomain.com creates a record at _dmarc.yourdomain.com.yourdomain.com — which is a perfectly valid DNS record that no receiver on earth will ever look up. A handful of providers (Cloudflare among them) are the exception and expect the full name; the giveaway is what the saved record looks like in the list afterwards. Read it back before you walk away.

Get this wrong and every checker reports no DMARC record found while the record sits in your zone looking correct — which is the single most common reason a record that exists behaves as though it does not.

Where to point rua=

Aggregate reports arrive as gzip- or zip-compressed XML attachments, several a day once the major providers pick you up. A personal mailbox will hold them, but you won't read them for long: the questions you actually need answered — which service is this IP, what share of my mail aligns, what breaks if I enforce — take parsing every report and resolving IPs to named senders. Point rua= at a monitoring service instead, or at a mailbox you're prepared to feed into one. If you want to see inside a report right now, the free DMARC report analyzer parses one in your browser without an account, and DMARC aggregate reports explained covers the format.

One wrinkle worth knowing: sending reports to an address at a different domain requires that domain's permission, published as a TXT record at yourdomain.com._report._dmarc.theirdomain.com. Reporting services set this up as part of onboarding; if you point rua= at a colleague's address on another domain and never see a report, this is why.

Common DMARC record mistakes

• Two records at _dmarc. As above — the result is no DMARC at all. It usually happens when a second person adds one without checking, or a hosting provider adds a default.
• A policy with no rua=. Enforcing blind. You will not learn which of your own senders you just broke until someone complains.
• Curly quotes. Copying a record out of a word processor turns straight quotes into typographic ones, and the record silently fails to parse. Copy from a plain-text source.
• A trailing tag with no value, like p=reject;; or a stray rua=. Some receivers tolerate it, some discard the record.
• Jumping straight to p=reject on a domain that sends mail. Your invoicing tool, your CRM, your ticketing system and your newsletter platform are all senders, and any one of them that isn't aligned starts bouncing the moment you enforce.
• Publishing it and never looking again. Records rot — a rotated DKIM key, an SPF include that grew past the lookup limit, a registrar migration that dropped TXT records. DNS drift is the ordinary case, not the exception.

Checking that it worked

Don't trust the panel; read the live record. Run the domain through the free DMARC checker — it resolves _dmarc.yourdomain.com the way a receiver does, tells you whether the record parses, which policy it enforces and what's missing. Then check the other half of the chain: the SPF record checker counts your lookups, and the DKIM checker probes for a published key. A DMARC record over an unauthenticated domain is a policy waiting to reject your own mail.

Free checks: DMARC checker SPF checker DKIM checker Spam checker

Want to check the record you just published? Run the free DMARC checker — it reads your live DNS and tells you if the record parses, what policy it enforces, and what's still missing. For the full walk from p=none to p=reject, see DMARC policies explained.