What Is a DMARC Record, and How Do You Set One Up?

You can set up SPF and DKIM perfectly and still have someone send phishing mail that shows your domain in the From: line. That's because neither standard, on its own, ties its result to the address your recipients actually see. DMARC is the layer that does. It tells the world, "mail claiming to be from my domain must pass SPF or DKIM for my domain — and here's what to do if it doesn't."

This article explains what a DMARC record is, how alignment works, what every tag means, and — most importantly — how to roll DMARC out safely, from monitoring to full enforcement, without blocking your own legitimate mail. It assumes you've at least started on SPF and DKIM.

What Is a DMARC Record?

DMARC (Domain-based Message Authentication, Reporting, and Conformance), specified in RFC 7489, is an email authentication policy published as a TXT record at _dmarc.yourdomain. It does three things:

1. Requires alignment. A message passes DMARC only if it passes SPF or DKIM and the authenticated domain matches the domain in the visible From: header.
2. Publishes a policy. You tell receivers whether to do nothing, quarantine (usually send to spam), or reject messages that fail.
3. Requests reports. Receivers send you aggregate reports showing which servers are sending mail as your domain and whether it passed.

A minimal DMARC record looks like this:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

This says: DMARC version 1, take no action on failures for now, and send daily aggregate reports to dmarc-reports@example.com.

Why DMARC Matters Now

DMARC used to be optional for most senders. That changed in February 2024, when Google and Yahoo began requiring anyone sending bulk mail to their users (Google's threshold is roughly 5,000 messages a day to Gmail accounts) to publish a DMARC record, alongside SPF and DKIM. A p=none policy satisfies the minimum, but the direction of travel is clear: domains without DMARC are increasingly treated as unauthenticated.

Beyond deliverability, DMARC at an enforcing policy is the only DNS-based control that stops attackers from spoofing your exact domain in the From: header. It is also a prerequisite for BIMI, which displays your logo in supporting inboxes.

How DMARC Alignment Works

This is the core idea, and the reason DMARC fails even when SPF and DKIM "pass."

Every message has several domains attached to it:

• The From: header domain — the one the recipient sees. DMARC protects this one.
• The envelope sender (Return-Path / MAIL FROM) — the domain SPF checks.
• The DKIM signing domain — the d= value in the DKIM-Signature header.

DMARC passes if at least one of these is true:

1. SPF passes, and the envelope sender domain aligns with the From: domain.
2. DKIM passes, and the d= domain aligns with the From: domain.

Relaxed vs. strict alignment

• Relaxed alignment (the default) means the domains only need to share the same organizational domain. mail.example.com aligns with example.com.
• Strict alignment means the domains must match exactly.

Here's a common scenario. You send newsletters through a marketing platform. The platform uses its own bounce domain for the envelope sender and signs with its own DKIM key:

Check	Domain used	Result	Aligned with example.com?
SPF	bounces.mailplatform.example.net	pass	No
DKIM	mailplatform.example.net	pass	No
DMARC	—	fail	—

Both checks passed, but neither is about your domain, so DMARC fails. The fix is to configure the platform to sign with a DKIM key on your domain (and ideally use a custom bounce domain under your domain). Once DKIM's d= is example.com, DMARC passes.

DMARC Record Tags Explained

Tag	Example	Meaning
v	v=DMARC1	Version. Required and must come first.
p	p=reject	Policy for the domain: none, quarantine, or reject. Required.
sp	sp=quarantine	Policy for subdomains. Defaults to the value of p.
rua	rua=mailto:dmarc@example.com	Where to send aggregate (daily summary) reports.
ruf	ruf=mailto:forensic@example.com	Where to send failure (forensic) reports. Few large receivers send these.
pct	pct=25	Percentage of failing mail the policy applies to. Defaults to 100.
adkim	adkim=s	DKIM alignment mode: r (relaxed, default) or s (strict).
aspf	aspf=r	SPF alignment mode: r (relaxed, default) or s (strict).
fo	fo=1	When to generate failure reports. 0 (default) means only when all checks fail; 1 means when any check fails.
ri	ri=86400	Requested interval between aggregate reports in seconds. Most receivers send daily regardless.

The three policies

• p=none — monitoring only. Receivers apply their usual filtering and send you reports. Nothing is blocked because of DMARC.
• p=quarantine — failing mail should be treated as suspicious, typically delivered to the spam folder.
• p=reject — failing mail should be refused during the SMTP conversation. This is full protection.

Receivers treat your policy as a strong request, not an absolute command. A large provider may still deliver a failing message if other signals strongly suggest it's legitimate — but in practice, p=reject stops the vast majority of spoofing.

The IETF has also been working on a revised DMARC specification (often referred to as DMARCbis) that refines some tags and how the organizational domain is determined. The record format above is what receivers support today, and records written this way remain valid.

How to Set Up DMARC, Step by Step

Rolling DMARC straight to p=reject is the most common way to accidentally block your own invoices, password resets, and newsletters. The safe path is gradual.

Step 1: Make sure SPF and DKIM are in place

List every service that sends email as your domain — your mailbox provider, marketing platform, CRM, helpdesk, billing system, website contact forms. Each needs to either be included in your SPF record or, better, sign with DKIM on your domain. If you're setting up a mailbox provider for the first time, see setting up a custom email domain through DNS.

Step 2: Publish a monitoring record

Create a TXT record with the name _dmarc (your dashboard will append the domain) and this value:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1

Verify it's live:

dig TXT _dmarc.example.com +short

You should see the record exactly as you entered it. If nothing comes back, check that the name is _dmarc and not _dmarc.example.com.example.com.

Step 3: Collect and read aggregate reports

Within a day or two, you'll start receiving aggregate reports: zipped or gzipped XML files, one per receiver per day. Each lists source IP addresses, message counts, and the SPF/DKIM/DMARC results for each.

Reading raw XML is tedious, so many people use a DMARC reporting service. But you can also parse them yourself. This Python script summarizes a single aggregate report:

import gzip
import sys
import zipfile
import xml.etree.ElementTree as ET

path = sys.argv[1]

if path.endswith(".gz"):
    with gzip.open(path, "rb") as f:
        xml_data = f.read()
elif path.endswith(".zip"):
    with zipfile.ZipFile(path) as z:
        xml_data = z.read(z.namelist()[0])
else:
    with open(path, "rb") as f:
        xml_data = f.read()

root = ET.fromstring(xml_data)
org = root.findtext("report_metadata/org_name")
print(f"Report from: {org}")

for record in root.findall("record"):
    ip = record.findtext("row/source_ip")
    count = record.findtext("row/count")
    disposition = record.findtext("row/policy_evaluated/disposition")
    dkim = record.findtext("row/policy_evaluated/dkim")
    spf = record.findtext("row/policy_evaluated/spf")
    header_from = record.findtext("identifiers/header_from")
    print(f"{ip:40} count={count:5} from={header_from} dkim={dkim} spf={spf} action={disposition}")

Run it with python3 summarize_dmarc.py report.xml.gz. The dkim and spf values under policy_evaluated are the aligned results — the ones DMARC actually used — so any row where both say fail is mail that would be blocked under an enforcing policy.

For each failing source, decide whether it's legitimate (a service you use that needs SPF or DKIM fixed) or not (spoofing, which is exactly what you want to block).

Step 4: Move to quarantine

Once legitimate sources consistently pass — usually after a few weeks of clean reports — tighten the policy. You can use pct to ramp up gradually:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com; fo=1

This quarantines a quarter of failing mail. Increase pct to 50 and then 100 as reports stay clean.

Step 5: Move to reject

Finally:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; fo=1

At this point, mail that fails alignment is rejected outright. Keep monitoring reports — a new tool someone in your company signs up for next year will show up as a failing source.

Protecting Subdomains and Unused Domains

DMARC applies to subdomains through the sp tag, and receivers look up the policy at the organizational domain if a subdomain has no _dmarc record of its own. Attackers love subdomains like billing.example.com because owners forget about them.

For domains that never send email — parked domains, old brand domains, redirect-only domains — publish a strict lockdown:

example.org.         3600 IN TXT "v=spf1 -all"
_dmarc.example.org.  3600 IN TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s"

The SPF record says no server is allowed to send for the domain, and the DMARC record rejects anything claiming to come from it or its subdomains.

Sending Reports to Another Domain

If your rua address is on a different domain than the one publishing DMARC — for example, a reporting service — the receiving domain must authorize it, or receivers won't send the reports. The authorization is a TXT record on the report destination's domain:

example.com._report._dmarc.reports.example.net. 3600 IN TXT "v=DMARC1"

This tells receivers that reports.example.net agrees to receive DMARC reports about example.com. Hosted DMARC reporting services usually publish this for you.

Common Mistakes and Best Practices

1. Jumping straight to p=reject. Without reviewing reports first, you'll almost certainly block some legitimate mail. Spend at least a few weeks at p=none.
2. Staying at p=none forever. Monitoring alone doesn't stop spoofing. Treat p=none as a stage, not a destination.
3. Publishing more than one DMARC record. Two TXT records starting with v=DMARC1 at _dmarc cause receivers to ignore DMARC entirely.
4. Ignoring third-party senders. Services that send as your domain but sign with their own DKIM domain will fail alignment. Set up custom DKIM for each.
5. Using a personal inbox for rua. Aggregate reports arrive daily from many receivers. Use a dedicated mailbox or a reporting service.
6. Wrong record name. The record must be at _dmarc.yourdomain, not at the root.
7. Forgetting DMARC when changing DNS providers. It's a single TXT record, and easy to lose — see how changing DNS affects email services.

---

DMARC Record FAQ

Conclusion

DMARC is the policy layer that turns SPF and DKIM from separate technical checks into real protection for the domain your recipients see. Its central concept, alignment, explains most of the confusing failures people run into, and its reporting gives you a clear view of every system sending mail in your name — often including a few you didn't know about.

The setup itself is a single TXT record. The real work is the rollout: publish p=none, read the reports, fix every legitimate source, and then step up through quarantine to reject. Done that way, DMARC blocks spoofing of your domain without ever blocking the mail your business depends on.

Here are some useful references for going deeper on DMARC:

1. RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — the DMARC specification, including tags, alignment, and reporting.
2. DMARC.org: Overview and resources — background, FAQs, and deployment guidance from the DMARC community.
3. Google Workspace Admin Help: Email sender guidelines — Gmail's requirements for SPF, DKIM, and DMARC.
4. Cloudflare Learning Center: What is DMARC? — an explainer of how DMARC, DKIM, and SPF work together.
5. MXToolbox: DMARC Lookup — a free tool to check and parse a domain's DMARC record.