Does a DMARC record actually block spoofing, or just the campaigns your marketing team still sends from a misaligned router? DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS record that tells receiving servers, Gmail, Outlook, Yahoo, which policy to apply to an email that fails SPF or DKIM alignment. Published alone, without the two protocols it supervises, it blocks nothing. By late 2025, 83.9% of domains analyzed by Red Sift had no DMARC record published, out of a sample of 73.3 million domains. The rest of this guide covers the exact record syntax, the three available policies, and how to read rua reports.
What is DMARC?
A domain that publishes SPF and DKIM without _dmarc leaves each receiving server to decide on its own how to handle an authentication failure. Some reject the message, others deliver it anyway and flag it as suspicious, others change nothing at all. DMARC closes that ambiguity: the domain owner sets the policy directly, in a TXT record published on the _dmarc.yourdomain.com host. The standard has been documented in RFC 7489 since 2015, but adoption remains uneven. Large listed companies pass 85% coverage in per-country analyses, while the global average stays under 15% (Red Sift, 2025). The gap comes mostly from how complicated the syntax looks, rarely from how hard it actually is.
Why DMARC matters
A domain without a DMARC policy lets anyone send an email signed with its name, with no mechanism warning the recipient. It’s the main vector for brand-impersonation phishing, the kind that gets an accountant to click a fake invoice supposedly sent by their own supplier. An email SaaS dashboard can show solid deliverability without saying anything about what a third party sends outside that platform: deliverability measured internally and external spoofing exposure remain two different things. A domain targeted by a spoofing campaign also sees its sender reputation degrade with Gmail and Outlook filters, a signal that later shows up in Gmail Postmaster Tools metrics, even when no fraudulent email actually leaves the company’s own infrastructure. Filters key off the visible domain name, not the sending IP.
How DMARC relies on SPF and DKIM
DMARC doesn’t replace SPF or DKIM. It supervises them, building on their results. SPF checks that the sending server is authorized to send for the domain listed in the MAIL FROM envelope. DKIM signs the message content with a cryptographic key, which makes it possible to detect any change in transit. An email can fail one and pass the other: DMARC requires that at least one of the two succeeds, and, more importantly, that the domain verified by that protocol matches the domain shown in the From header, the one the recipient sees. That match has a name, alignment.
Alignment can be strict or relaxed, set by the aspf and adkim tags of the DMARC record. In relaxed mode, the default, a subdomain like newsletter.company.com aligns with company.com. In strict mode, only an exact match is accepted. Most third-party sending platforms publish their own SPF records and sign with their own DKIM keys, whether it’s a transactional router or an external CRM. Without explicit configuration of the sending subdomain in DNS, these emails fail alignment even when they’re perfectly legitimate. That’s the most common cause behind a DMARC rejection rate that climbs right after a new marketing tool gets added, with no phishing campaign involved at all.
Creating a DMARC record: syntax and example
Setting up a DMARC record always starts with choosing the right DNS host. The record gets published as a standard TXT entry, on the _dmarc host of the domain’s DNS zone, never on the root domain. Here’s an annotated example, built for a gradual rollout:
v=DMARC1; p=quarantine; pct=50; rua=mailto:rua@company.com; ruf=mailto:ruf@company.com; aspf=r; adkim=r; sp=none
Each tag has a specific role. v sets the protocol version, always DMARC1. p defines the policy applied to the domain. pct sets the percentage of non-compliant messages covered by that policy. rua points to the address that receives daily aggregate reports. ruf points to the address for forensic reports, rarely honored by major mailbox providers. sp sets the policy applied to subdomains that don’t have their own record.
To create and check the record:
- Identify every legitimate sender for the domain (ESP, CRM, billing, helpdesk) and confirm each one publishes SPF or signs with DKIM.
- Create a dedicated address for rua reports.
- Publish the TXT record on _dmarc with p=none for at least two to four weeks, observing only.
- Read the first aggregate reports to spot the sources failing alignment and fix them one by one.
- Raise the policy in stages, pct=25 then pct=50 then pct=100, before moving to quarantine and then reject.
A malformed record, a duplicated tag, or an invalid rua address, generally doesn’t stop it from publishing to DNS. It silently blocks report delivery instead, which makes monitoring impossible with no alert ever warning the administrator.
The three DMARC policies and the gradual rollout
Three values are possible for the p tag. none changes nothing about delivery: the email goes through as usual, only the rua report logs the failure. quarantine sends the non-compliant email to the recipient’s spam folder or equivalent. reject blocks the message before it even reaches the inbox, with an SMTP rejection sent back to the sender.
Jumping straight to p=reject without an observation phase also blocks legitimate emails that aren’t aligned, a mailing list that rewrites the From header, a misconfigured third-party CRM router, an outsourced billing service. The recommended rollout starts with none for observation, moves gradually toward quarantine, and finishes with full rejection, raising pct in stages. A reject policy at 100% also opens the door to BIMI, the brand logo displayed in Gmail and Yahoo inboxes, which requires strict DMARC as a technical prerequisite.
Reading DMARC reports: rua and ruf
rua reports arrive as compressed XML. Every mailbox provider that has received mail from the domain typically sends one per day, listing the sending IPs, the volume processed, the SPF and DKIM alignment result, and the policy applied. Manual reading stays workable for a domain with two or three senders. Past a dozen active subdomains and several sending platforms, the volume of XML lines makes line-by-line reading unrealistic without a dedicated parsing tool.
ruf reports, on the other hand, detail one specific email that failed, full headers included. Gmail and Yahoo don’t send them, for reasons tied to the privacy of the personal data contained in those headers. Only a minority of smaller mailbox providers still honor them. The full guide to reading an aggregated DMARC report without getting it wrong covers the XML parsing field by field.
What DMARC doesn’t cover
DMARC protects the exact domain published in the record, nothing more. An email sent from company-support.com instead of company.com, a visually similar domain registered by an attacker, slips right past the whole setup: no SPF, DKIM, or DMARC covers a domain the company doesn’t own. This typosquatting remains the most common blind spot in DMARC deployments, including ones already set to p=reject. The full list of limitations, from message content to protecting domains you don’t own, is worth knowing before announcing internally that a domain is now protected.
Who needs to publish a DMARC record in 2026
Since February 1, 2024, Google requires aligned SPF and DKIM authentication, plus a DMARC record at least at p=none, for any sender sending 5,000 or more messages within 24 hours to personal Gmail accounts. Microsoft followed starting May 5, 2025, on Outlook.com, Hotmail, and Live.com: past the same threshold, unauthenticated emails get rejected at the SMTP level with Enhanced Status Code 550 5.7.15, instead of being routed to the spam folder. The complaint rate reported through mailbox-provider feedback loops needs to stay under 0.3%, with a recommended threshold under 0.1% to avoid tighter filtering.
Google specifies that the 5,000-message threshold gets evaluated on a rolling 24-hour window: a sender who crosses it even once stays subject to the same requirements as if they hit it every day.
Below that threshold, nothing legally requires publishing DMARC. But an active B2B domain, even at low volume, stays a prime target for impersonation: the fraudulent invoice aimed at a supplier doesn’t care about the victim’s sending volume. Just one more tool in the stack, some will say on finding out they also need to watch hard bounce rate and sender reputation tied to the domain. DMARC doesn’t replace anything that already exists. It mostly consumes data already sitting in Google Postmaster Tools. Cleaning the mailing list, basic list hygiene, before tightening the policy toward DMARC reject avoids confusing a bouncing address with a misdiagnosed alignment failure, a mix-up that delays rollout by several weeks in most cases observed.
How long has it been since the rua report for this domain was last read?
