DMARC Limits and Risks: What It Doesn’t Protect and What It Can Break

A p=none policy blocks no message at all, while a poorly prepared p=reject blocks legitimate ones. Between the two, DMARC leaves the display name and lookalike domains out of scope, and a compromised account slips past it too. In short, the protocol stops exact spoofing of the sender domain and nothing else, while deploying it exposes you to lost customer emails and forgotten third-party senders. The limits are covered with other tools; the risks are managed with a gradual rollout.

The email platform dashboard says “all good” and campaigns still land in spam: authentication is one of the first places to look. On the fraud side, the FBI puts losses from Business Email Compromise at $3.05 billion (24,768 complaints) in its 2025 IC3 report, against $2.77 billion for 2024 (21,442 complaints).

What DMARC checks

DMARC builds on SPF and DKIM. A message passes if either one passes and the authenticated domain aligns with the domain in the header From field, as defined by RFC 5322. Teams discover alignment last: an SPF record that is valid for a provider’s domain is not enough when the visible address carries yours. On failure, the recipient applies the policy published by the domain owner: quarantine sends the message to spam, reject refuses it, none does nothing.

Two settings control how strict that alignment is. By default it is “relaxed”: mail.example.com aligns with example.com, since they share the same organizational domain. In “strict” mode, set with adkim=s for DKIM and aspf=s for SPF, the two names must be identical. Strict closes doors, but it also breaks any provider that signs with a subdomain, which rarely shows up before the switch to reject.

The standard sets its own boundaries. Since May 2026, RFC 9989 (on the IETF Standards Track) defines DMARC and replaces RFC 7489 (March 2015) and RFC 9091 (2021). Its section 2.2 states that DMARC does not address visually similar domains or abuse of the sender’s human-readable name, and section 2.4 places display name attacks out of scope. The 2015 text already said the same thing.

Display name and cousin domains: two documented blind spots

A message displayed as “Bank X Customer Service” and sent from support@bank-x-secure.com passes DMARC without trouble. The sending domain belongs to the attacker, who published their own SPF and their own DKIM key, so SPF, DKIM and DMARC are all green. The check covers the technical domain; the name the mail client puts up front is never examined.

Cousin domains (typosquatting, added hyphens, a different extension) follow the same logic: your record protects your domain, not the ones that resemble it. The answer is monitoring for registrations of domains close to yours, plus filtering on the receiving side.

A compromised account passes every check

A mailbox whose credentials leaked sends from the right infrastructure, with the right signature. The entry point is often phishing or a data breach; DMARC then has nothing to flag because the message is genuine. Multifactor authentication and alerts on unusual logins sit upstream, outside the protocol’s scope.

Forwarding and mailing lists: alignment breaks along the way

When a company alias or a mailing list relays a message, the relay’s IP does not appear in the original domain’s SPF record, so SPF generally fails. DKIM remains, and it survives as long as the signed content is untouched. A Mailman or Listserv list that appends a footer invalidates the signature, and the legitimate message fails both checks.

RFC 9989 (section 7.4) gives the example of a bank whose customers provided an alumni address, of the form jones@alumni.example.edu, that forwards to another mailbox: the message arrives from the relay’s IP, which is absent from the sender’s SPF record (RFC 5321 from 2008, MailFrom), unless it is rewritten. DKIM signatures (RFC 6376 from 2011) generally remain valid as long as the message body is not modified. A mailing list that appends a footer breaks them.

RFC 9989 (section 7.4, which refers to RFC 7960 from 2016 on mailing lists) draws two rules from this: a domain at p=reject must not rely on SPF alone and must sign with DKIM, and a domain whose users write to public mailing lists should not publish p=reject. The ARC protocol (Authenticated Received Chain, RFC 8617 from July 2019) preserves the original authentication result, provided the relay has enabled it.

Subdomains: which wins, the domain or the subdomain?

The subdomain wins as soon as it publishes its own record; otherwise it inherits from the parent. RFC 9989 spells this out in two rules. The recipient first looks for a record on the exact From domain, then walks up the DNS tree (DNS tree walk, section 4.10, limited to 8 DNS queries), so a record specific to the subdomain takes precedence over the parent’s. And without an sp= tag, the main domain’s p= policy applies to subdomains.

In practice, a _dmarc.newsletter.example.com left at p=none after a test keeps that scope in plain monitoring while example.com sits at reject. The other way around, an sp=none on the main domain opens every subdomain without a record of its own: handy during the audit, to be removed afterwards. The sp= tag is ignored in a record published on a subdomain. Since RFC 9091, carried over into RFC 9989, an np= tag also covers subdomains that do not exist in DNS.

p=none, the monitoring mode that gives a false sense of security

The record exists and the compliance check passes, yet nothing is blocked. Google states on its deployment page, consulted on October 27, 2026, that under p=none messages are delivered normally. A domain that stays there for years keeps accepting spoofed messages.

p=reject: the legitimate emails that vanish

Once at reject, a domain sees every sender refused whose SPF and DKIM both fail to align. HR sends payslips through an external tool, support runs on a helpdesk and billing on a SaaS module: each writes in the domain’s name and will be refused on switch day if it is not aligned. Google is blunt about it: messages that fail the check are rejected and never delivered. Under quarantine, they land in the spam folder at best. The next day’s rua reports then list the IPs whose messages failed, including ones nobody had inventoried. Hence the value of going through quarantine, then flagging the testing phase with t=y before any reject.

Sending providers create the most frequent trap. On a shared or dedicated IP, SPF validates the provider’s domain; DMARC alignment then depends on a DKIM signature in your domain’s name, unless you use a custom Return-Path. Without it, the campaign fails on the first switch to reject. The DKIM key is published under a dedicated selector, in the form selector._domainkey.example.com, and the signature must carry the From domain.

TXT errors and the SPF limit of 10 DNS lookups

A single configuration error is enough to neutralize DMARC without any alert. DNS does not flag it: the record is published without validation, so a typo in the zone only shows up when you read the reports, a few days later. A record split into two badly joined strings, a typographic quote pasted from a word processor or a semicolon forgotten between two tags is all it takes. Two DMARC records on the same name end badly: RFC 9989 discards every record found at that location (section 4.10). A misspelled v=DMARC1 makes the whole record ignored, an unknown tag is silently skipped, and a typo in rua= deprives you of reports without visibly breaking anything. A report address hosted on another domain also requires an authorization record at that domain (RFC 9990).

On the SPF side, RFC 7208 (section 4.6.4) caps evaluation at 10 DNS lookups: include, a, mx, ptr, exists and redirect count, ip4 and ip6 do not. Void lookups are limited to 2. Beyond that, the result is permerror (a cap already present in the RFC 4408 of April 2006) and SPF stops contributing to DMARC. Every tool added through an include brings the domain closer to that threshold.

Limits and risks at a glance

Moving from none to reject without losing mail

The path has three stages: list the senders, observe at none, then tighten in steps through quarantine before reject. It starts with a sender inventory: email platform, CRM, helpdesk, payroll, billing, application servers. Teams always forget one; the rua aggregate reports help find it, since they list every IP that sent in the domain’s name with its SPF and DKIM result.

The steps never change: p=none, reading the reports, quarantine, then reject. In the Google Workspace help, Google recommends configuring SPF and DKIM at least 48 hours before publishing DMARC, staying at p=none for a week with a daily read of the reports, then moving to quarantine on a small percentage of messages: 10% for a small organization, 1% for a large one (the “Recommended DMARC rollout” page). A starting record looks like v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com, published as TXT on _dmarc.example.com. Note that the pct= tag from RFC 7489 no longer exists in RFC 9989, which observes that it was applied very unevenly outside the values 0 and 100 and replaces it with t=y (testing) or t=n. RFC 9989 itself recommends publishing p=none for at least a month while relying on aggregate reports.

The time spent at each step depends on the number of flows: with few sending sources, a week of reports may be enough to list them; with 20 tools, the forgotten senders surface report after report. During the ramp-up, a separate sp= lets you harden the main domain while unaudited subdomains stay at none.

Gmail, Yahoo and deliverability

Since February 1, 2024, Google requires senders of more than 5,000 messages a day to Gmail to have valid SPF and DKIM plus a DMARC policy, which can stay at none. The spam rate shown in Google Postmaster Tools must stay under 0.30%, with a target under 0.10% (Google’s sender guidelines). Yahoo, which has applied its bulk sender rules since February 2024, also asks for DMARC at none as a minimum, with a From domain aligned on SPF or DKIM (Yahoo best practices). The Gmail side is covered in detail in the article on Gmail sender requirements.

DMARC opens the door to the inbox without settling sender reputation. That reputation depends on the complaint rate and on bounces: a domain at reject that sends to a list full of dead addresses feeds hard bounces and damages its deliverability. Running a sample of the list through a verification tool before the next campaign shows that rate before Gmail measures it.

Does your next rua report contain a sending source that nobody on the team recognizes?