DMARC ties SPF and DKIM to your visible From address and tells receiving servers what to do when checks fail. How it works and how to roll it out safely.
DMARC is the record that makes SPF and DKIM useful. It does two jobs: it requires that the domain a human sees in the From line matches the domain that SPF or DKIM verified, called alignment, and it tells receiving servers what to do when a message fails, deliver it, quarantine it, or reject it. It also sends you reports on who is sending mail as your domain. Without DMARC, SPF and DKIM still run, but nothing enforces alignment and nothing acts on failures. Major inbox providers now expect DMARC on any domain sending volume. For setup steps, see our SPF DKIM DMARC setup guide.
DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS TXT record that builds on SPF and DKIM. It requires the visible From domain to align with an authenticated domain, instructs receiving servers how to handle messages that fail authentication, through a policy of none, quarantine, or reject, and delivers aggregate reports on all mail sent using the domain.
Three things. First, alignment. SPF and DKIM can each pass on a domain that is not the one the recipient sees. DMARC closes that gap by requiring the authenticated domain to match the From domain, so a message cannot pass authentication while displaying someone else's name.
Second, a failure policy. SPF and DKIM produce a pass or fail result but say nothing about consequences. DMARC's p= tag tells receiving servers what to do with a failing message: p=none (do nothing, just report), p=quarantine (send it to spam), or p=reject (refuse it outright).
Third, reporting. DMARC's rua tag collects aggregate XML reports from receiving servers showing every source sending mail as your domain, how much passed, and how much failed. This is how you discover a forgotten tool, or a spoofing attempt, before it damages your reputation. See cold email deliverability guide.
It is a single TXT record published at _dmarc.yourdomain.com. A starter record: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Reading it: v=DMARC1 declares the record; p=none sets monitoring-only mode; rua= is where aggregate reports are sent.
More complete records add pct= (apply the policy to a percentage of mail during rollout), sp= (a separate policy for subdomains), and adkim=/aspf= (strict or relaxed alignment). For most senders, the progression is what matters more than the extra tags: start at p=none, watch reports, then tighten.
The record must live at the _dmarc host, not the root domain. A DMARC record placed at the root does nothing, a common and silent setup error. See the common errors section of our setup guide.
In stages, because jumping straight to p=reject can bounce your own legitimate mail if a sending source is misconfigured.
Optionally use pct= to ramp, for example p=quarantine; pct=25, applying the policy to a quarter of failing mail first. See how to set up cold email infrastructure.
For a dedicated cold sending domain, moving to p=quarantine or p=reject once your sources are confirmed is the right call, and provider guidance points that way. The reason is that p=none gives you monitoring but no protection: a spoofer using your sending domain still gets their forged mail delivered, and the resulting complaints hurt your reputation. A stricter policy protects the domain you are trying to build.
The caution is sequencing. On your main corporate domain, with many internal senders and third-party tools, rush to p=reject and you can block payroll notifications or a support platform. On a clean dedicated cold domain with one or two sending sources, the path to p=reject is short and low-risk.
DMARC aggregate reports arrive as XML files, one per receiving provider per day, at the address in your rua tag. Raw XML is hard to read, so most senders pipe them into a free or paid DMARC dashboard that parses them into a table. Whatever the format, you are looking for three things.
Sources. Every IP and domain sending mail as your domain, grouped by sending service. You should recognize all of them: your mailbox provider, your cold email tool, your CRM, your support platform. An unrecognized source is either a forgotten tool or someone spoofing you.
Pass and fail counts per source. For each legitimate source, SPF and DKIM should be passing with alignment on nearly all volume. A legitimate source showing high failure rates has a configuration problem, usually a missing DKIM setup or an SPF include: that was never added.
The alignment column. A source can pass raw SPF or DKIM but fail DMARC because the authenticated domain does not match the From domain. This is the most common reason a "correctly configured" tool still fails DMARC, and the fix is domain-aligned DKIM for that source.
Spend one to two weeks reading reports at p=none before tightening. The goal is a report where every source is known and passing with alignment. Once you see that, moving to p=quarantine and then p=reject is safe. See how to set up cold email infrastructure.
Once your DMARC policy reaches enforcement (p=quarantine or p=reject), you become eligible for a related standard called BIMI (Brand Indicators for Message Identification). BIMI lets your verified logo appear next to your emails in supporting inboxes like Gmail and Apple Mail, a small trust and recognition boost.
BIMI is not part of authentication and does nothing for deliverability on its own. It is a reward for having authentication fully in place: providers only show a BIMI logo for senders whose DMARC is at enforcement, precisely because that proves the domain is protected against spoofing. Setting it up involves publishing a BIMI DNS record pointing to a specially formatted SVG logo, and for Gmail specifically, a Verified Mark Certificate (VMC) or Common Mark Certificate (CMC) from an approved authority.
For a dedicated cold-email domain, BIMI is usually not worth the cost and effort, since brand recognition matters less than for a consumer marketing domain. For your primary corporate domain, once DMARC is at p=reject, BIMI is a reasonable next step. Either way, the point stands: BIMI is downstream of a fully enforced DMARC policy, which is one more reason to complete the none-to-quarantine-to-reject progression rather than parking at p=none. See cold email deliverability guide.
The Alignment Verdict: DMARC checks that the domain a person sees in the From line is the same domain a machine authenticated, then delivers a verdict, pass, quarantine, or reject, and mails you a report.
The verdict framing shows why DMARC is the keystone. SPF and DKIM are evidence: one says the courier was authorized, the other says the seal was intact. DMARC is the judge. It looks at that evidence, applies one extra test, does the authenticated domain match the name on the envelope, and issues a ruling that the receiving server acts on. It also keeps a log, the aggregate report, of every case.
Without the judge, the evidence is collected but never weighed, and no ruling is issued. That is a domain with SPF and DKIM but no DMARC: technically authenticated, practically unprotected, because a spoofer can still display your name while passing checks on a different domain.
The quotable version: "SPF and DKIM gather the evidence. DMARC is the only one of the three that reaches a verdict and enforces it."
A strict DMARC policy protects your domain's name. It does not make a bad list deliverable. Bounces still erode reputation regardless of how airtight your authentication is. See how to reduce email bounce rate for cold outreach and what is an SPF record.
A p=reject DMARC policy stops others from forging your domain. It does nothing about whether your own sends reach real people. Bounces from a stale list still damage the reputation DMARC is guarding.
InboundLabs is a sales intelligence platform built on a database of 280M verified B2B contacts with 98% email deliverability on verified contacts. It lets you filter by industry, headcount, region, and title, so your authenticated domain sends to verified inboxes and its reputation strengthens over time. Monthly plans, no annual lock-in. Free to start, no credit card required.
See how InboundLabs finds verified contacts instantly → inboundlabs.app
DMARC is the record that turns SPF and DKIM into protection. It enforces alignment between the visible From domain and the authenticated one, sets a policy of none, quarantine, or reject for failing mail, and sends you reports on everyone using your domain. Publish p=none first, read the reports, confirm your sources, then tighten to quarantine and reject. On a dedicated cold domain the path is short. And no policy fixes a bad list.
What is DMARC in simple terms?
DMARC is a DNS record that builds on SPF and DKIM. It requires the domain a person sees in the From line to match the domain that was authenticated, tells receiving servers whether to deliver, quarantine, or reject mail that fails, and sends you reports on every source sending email as your domain.
What is the difference between DMARC, SPF, and DKIM?
SPF checks the sending server's IP. DKIM checks the message signature. DMARC checks that the authenticated domain matches the visible From domain, decides what happens on failure, and provides reporting. SPF and DKIM produce results; DMARC enforces them.
What does p=none, p=quarantine, and p=reject mean?
They are DMARC policies for failing mail. p=none means monitor only, deliver as normal, just report. p=quarantine sends failing mail to spam. p=reject refuses failing mail outright. The standard rollout is none, then quarantine, then reject, after confirming your legitimate sources pass.
Should I start DMARC at reject?
No. Start at p=none so nothing is blocked while you collect reports and confirm every legitimate sending source aligns. Then move to quarantine, then reject. Starting at reject risks blocking your own mail if a source is misconfigured, which is common on busy corporate domains.
Where does the DMARC record go?
As a single TXT record at _dmarc.yourdomain.com, not at the root domain. A DMARC record placed on the root does nothing. This misplacement is a frequent and silent setup error, so verify the host is exactly _dmarc.
What are DMARC aggregate reports?
XML reports that receiving servers send to the address in your record's rua tag. They summarize all mail seen using your domain: the sending sources, volumes, and SPF/DKIM pass and fail counts. They are how you spot a forgotten tool or a spoofing attempt before it hurts your reputation.
LSI keywords: DMARC, Domain-based Message Authentication, alignment, p=none quarantine reject, aggregate report, rua tag, From domain, SPF, DKIM, email authentication, spoofing protection, dedicated sending domain
Yahoo sender requirements mirror Gmail's, with one sharper edge: Yahoo rejects non-compliant bulk mail outright instead of foldering it.
Google bulk sender requirements apply at 5,000 emails a day, but the thresholds that filter you apply to everyone. The full 2026 checklist.
How to get off an email blacklist: fix the root cause first, then request delisting. Skip the fix and you get relisted, often faster.
No commitment. No credit card. Just 50 free verified contact lookups.