DMARC glossary
What does v=DMARC1 mean in a DMARC record?
By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 15, 2026
v=DMARC1 is the version tag that identifies a DNS TXT record as a DMARC record. It must be the first tag in the record, and DMARC1 is the only valid value. If it's missing, misspelled, or not first, receiving servers ignore the entire record — as far as the world is concerned, you have no DMARC policy.
v=DMARC1 at a glance | |
|---|---|
| Tag | v (version) |
| Valid values | DMARC1 — the only valid value, exactly as written |
| Default | Required — no default. An invalid or missing v tag makes receivers discard the whole record. |
| Where it goes | Always the first tag, in a TXT record published at _dmarc.<yourdomain>, e.g. v=DMARC1; p=none; |
How v=DMARC1 works
DMARC records live in DNS as plain TXT records at a special hostname: _dmarc.yourdomain.com. Since a TXT record can hold anything, receivers need a way to recognise one as DMARC. That's the v tag's only job — it says “this is a DMARC record, version 1.”
The rules are strict on purpose. RFC 7489 requires the value to be exactly DMARC1 and requires it to be the first tag in the record. v=dmarc1, v=DMARC 1, or a record that opens with p=reject before the version tag are all treated the same way: the receiver ignores the record entirely. No error, no warning — your policy just silently doesn't exist.
That silent failure mode is what makes this tag worth checking. A domain can look configured in your DNS console while every mail server on earth treats it as having no DMARC at all. When in doubt, run the record through a checker rather than eyeballing it.
Correct record vs common mistake
Correct
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.comVersion tag first, exact value DMARC1 — receivers parse the rest of the record and apply your policy.
Common mistake
p=reject; v=DMARC1; rua=mailto:dmarc@yourdomain.comThe version tag isn't first, so receivers ignore the entire record. The p=reject you think you have does nothing.
Generate your DMARC record
Build the exact TXT record to publish — pick a policy, add a reporting address, copy. Free, no signup.
Used to show the exact host name to publish — the record itself doesn't contain it.
Start at none to observe, then tighten once reports look clean.
Where daily XML summaries are sent. Comma-separate multiple addresses.
Advanced options (sp, alignment, pct, ruf)
Subdomains inherit p unless you set this. Attackers love unused subdomains — reject is a strong choice once you're at enforcement.
Relaxed allows subdomain matches (mail.yourdomain.com signs for yourdomain.com). Strict requires an exact match — most domains should stay relaxed.
Same idea for the SPF (Return-Path) domain.
Applies quarantine/reject to a percentage of failing mail during rollout. Retired in DMARCbis — use briefly if at all.
Per-message failure samples. Rarely sent by large providers; contains message data.
Your DMARC record
Publish this as a TXT record in your DNS.
_dmarc.yourdomain.com
v=DMARC1; p=none;
Record type: TXT · TTL: your provider's default (e.g. 3600) is fine.
After you publish
- Add the TXT record at your DNS host and allow up to an hour for propagation.
- Verify it with the free DMARC checker.
- Watch your aggregate reports, fix SPF and DKIM for every legitimate sender, then step up to quarantine and reject.
Troubleshooting v=DMARC1
| Issue | Likely cause | Fix |
|---|---|---|
| Checker says 'no DMARC record found' but you published one | Record is at the domain root instead of _dmarc.<domain>, or hasn't propagated yet | Publish the TXT record at the _dmarc subdomain and re-check after DNS propagation |
| Record exists but receivers ignore it | v tag misspelled, lowercase, or not the first tag in the record | Make v=DMARC1 the exact, first tag — then verify with a DMARC lookup tool |
| Two DMARC records at _dmarc | An old record was left behind when a new one was added (common after switching providers) | Delete the duplicate — receivers that find multiple DMARC records ignore all of them |
See this on your own domain
Enter your domain — the check runs instantly on the next page. Free, no signup.
Why it matters for MSPs
A typo in one tag kills the whole record — and nothing alerts you. Across 50–200 client domains, hand-edited DNS means a percentage of your “protected” tenants may have records receivers silently discard. The client believes they're covered; an audit or an incident says otherwise.
Trusted by MSPs
“Their responsive support, agent task lists, white-label reporting, and centralized dashboard make managing our customer domains, effortless.”
Bobby Ghoshal — CEO, dupe.com
Enforce it — don't just monitor it
Palisade validates every client domain's DMARC record as published DNS, not as intended DNS — so a broken v tag, a stray character, or a mangled record gets caught before it quietly disables protection.
Free 15-day trial · No credit card · Your own domain free forever (NFR)