I have spent years watching DMARC quietly decide whether cold email lands in the inbox or the void. So when the standard changed in 2026, I read the actual records, not the headlines.
The short version: this is the first substantive update to DMARC since 2015. It does not break your current setup. It does add real precision, and a couple of the new controls matter directly to anyone sending outbound at scale.
Below is the plain-English breakdown I wanted when I first opened the new specs, including the exact record edits worth making this year.
DMARC got its first real rewrite in a decade in 2026. Here is what changed and what to do about it.
The update landed in May 2026 as three separate documents rather than one. The old single spec was split for clarity.
Together, these three obsolete RFCs 7489 from 2015 (and RFC 9091, the earlier PSD add-on). The community calls the package DMARCbis, though that word never appears in the records themselves.
The other headline is status. DMARC moved from an Informational document to a Proposed Standard on the IETF Standards Track. In practice, that gives auditors and vendors a formal reference to point at, without creating new obligations on its own.
One thing that did not change: your record still starts with v=DMARC1. There is no DMARC2, and existing records keep working.
The np tag is the change I would act on first. It fixes a gap that attackers have used for years.
Before this update, DMARC had a p tag for your main domain and an sp tag for existing subdomains. Neither cleanly covered subdomains that do not exist at all in DNS.
That gap mattered. A spoofer could send mail from a made-up subdomain like invoices.yourbrand.com that was never registered. The receiver would fall back to whatever your p or sp policy said, which was often p=none.
The np tag closes that. It sets a dedicated policy for non-existent subdomains, defined precisely as any name that returns NXDOMAIN.
So you can keep your main domain at p=none while setting np=reject. You close the fake-subdomain loophole without committing all your mail to strict enforcement on day one.
One honest limit: np only covers subdomains that truly do not exist. It does nothing for a real subdomain that gets hijacked. And it only helps once a given receiver honors it, and support is still rolling out across mailbox providers. Publishing it now is forward-compatible insurance, not an instant fix.
The t tag is the other addition worth knowing. It changes how you stage a stricter policy.
The old pct tag let you apply your policy to a percentage of mail. In practice almost everyone used it at 0 or 100, and receivers implemented the in-between values inconsistently.
The t tag simplifies that to a plain testing flag with two values.
This gives cautious teams a safer path. You can publish a stricter policy in testing mode, read the aggregate reports, confirm nothing legitimate is failing, then flip t=y off for real enforcement.
A few tags are gone. If your record still carries them, clean them out on your next DNS update.
None of this is a breaking change. Removing the deprecated tags just keeps your record clean and aligned with the current spec.
There is also a new psd tag for operators of public-suffix-style domains. Leave it out unless you actually run a public suffix domain.
This change is quiet but structural. It changes how a receiver finds your policy and your organizational domain.
The old method leaned on the Public Suffix List, a maintained file used to figure out where an organizational domain boundary sat. The update replaces that with a DNS Tree Walk.
Under the Tree Walk, a receiver starts at the exact sending name and queries progressively higher labels, up to a set number of lookups, until it finds a DMARC record. The boundary comes from DNS itself rather than an external list.
There is a practical implication. A receiver running the new spec can, in edge cases, resolve a different organizational domain than a receiver still on the old method.
The safe move if you run a complex subdomain setup: publish an explicit DMARC record at every domain and subdomain you send from. That removes any ambiguity about which policy applies, no matter which version a receiver uses.
Here is the mapping I keep next to me when auditing a record. It shows what to keep, what to drop, and what to add.
Most of this update is quiet. For an outbound sender, though, a few edits are worth making now. Here is my short list.
Why the urgency, even though nothing breaks? Inbox providers keep tightening bulk-sender rules. High-volume senders face DMARC alignment requirements and strict complaint-rate limits. The t tag gives you a way to reach stricter enforcement without risking legitimate mail during the change.
If you want to see where your mail is actually landing before and after these edits, run a free email deliverability test against your mailboxes and domains.
Publishing a clean DMARC record is step one. Watching it hold is step two, and that is where I spend most of my time. A record that silently breaks quietly costs you the inbox.
The reason every mailbox I run goes through Warmforge is the monitoring. Warmforge runs automated Health Checks on DNS, MX, and blacklist status for each mailbox.
So when I add an np tag or flip a t flag, a broken SPF, DKIM, or DMARC record shows up as an alert, not a mystery dip in replies. I catch it before it burns a domain.
A record edit is only good if inbox placement holds. I check two things after any DNS change.
A Heat Score™ tracks each mailbox's reputation over time, so I can see if a policy change moved it. Inbox Placement Tests send to Google, Outlook, and other providers and show where mail lands: primary, promotions, or spam. One free placement test comes with every plan.
The warmup itself is one click. AI-written emails mimic real conversation to signal legitimacy, and the pool is premium by default: aged Google Workspace and Microsoft 365 mailboxes running multilingual activity, so the traffic looks natural. I keep it always on, with a two-week warmup before any mailbox sends cold.
DMARC records live on the domains your mailboxes run on, so clean setup matters as much as monitoring. Across the Forge Stack, SPF, DKIM, and DMARC are configured automatically at setup.
That runs across Mailforge for shared-IP infrastructure, Infraforge for dedicated IPs with pre-warmed mailboxes, and Primeforge for real Google Workspace and Microsoft 365 mailboxes with ESP matching. Warmforge then warms and monitors whatever those products create.
If I send through Salesforge, Warmforge warmup is included free on every plan, with unlimited slots. That is the line item competitors charge extra for.
The list matters too. Leadsforge finds contacts across a 500M+ database with waterfall enrichment and intent signals like funding rounds, acquisitions, and job changes, then feeds them into a sequence with no CSV export.
No other stack puts warmup, monitoring, infrastructure, lead finder, and outreach under one login. I can run it myself, or hand the whole workflow to Agent Frank, the autonomous AI SDR who prospects, sends, and books meetings around the clock.
Want to see a broken record before your prospects do?
Sign up for Warmforge and get 1 free warming slot plus 1 free placement test.
DMARC in 2026 is an upgrade, not an upheaval. The spec got a formal standards status, a cleaner tag set, and a smarter way to find your policy in DNS.
For a cold email sender, the practical work fits on a sticky note: add np=reject, move from pct to t, drop the retired tags, and publish a record on every subdomain you send from.
The senders who stay ahead are the ones who treat authentication as part of a living deliverability system, not a one-time DNS chore. That is the whole reason I keep my records, my warmup, and my sending in one place.
Sign up for Warmforge and start with 1 free warming slot and 1 free placement test. Then watch your records the way you watch your reply rate.
1. What changed in DMARC in 2026?
In May 2026, the IETF published DMARCbis as three standards: RFC 9989 (core protocol), RFC 9990 (aggregate reporting), and RFC 9991 (failure reporting). They replace RFC 7489 from 2015 and move DMARC to a Proposed Standard. Records still start with v=DMARC1, so existing setups keep working.
2. What is the np tag in DMARC?
The np tag sets a DMARC policy for subdomains that do not exist in DNS, meaning any name that returns NXDOMAIN. Values are np=reject, np=quarantine, and np=none. It lets you block spoofing from fake subdomains while keeping your main domain policy unchanged. Receiver support is still rolling out, so it is forward-compatible protection.
3. What is the t tag and did it replace pct?
Yes. The t tag replaces the old pct percentage tag. It is a testing flag: t=y publishes your policy in testing mode so it enforces one level softer, and t=n (the default) applies the policy in full. It gives you a safe way to stage a stricter policy before turning on enforcement.
4. Do I need to change my DMARC record right now?
Nothing breaks if you do not. But it is worth adding np=reject, swapping any pct value for t, removing the retired pct, rf, and ri tags, and publishing an explicit record on each sending subdomain. These are small edits, not a migration.
5. What is the DNS Tree Walk in DMARCbis?
The DNS Tree Walk replaces the old Public Suffix List method for finding your organizational domain and policy. A receiver starts at the exact sending name and queries higher labels until it finds a DMARC record. Publishing a record on every subdomain you send from removes any ambiguity.
6. Why does the DMARC 2026 update matter for cold email?
Cold email programs often send from lookalike or throwaway subdomains, so the np tag protects your root domain from being spoofed through subdomains nobody is using. The t tag also helps you tighten policy ahead of inbox-provider bulk-sender rules without risking legitimate mail during the change.
