DMARC was standardized anew in 2026 – what website teams should actually audit

In May 2026, DMARC was standardized anew: RFC 9989 replaced RFC 7489 and RFC 9091, while aggregate and failure reporting moved into RFC 9990 and RFC 9991.

For website teams, that can sound like mail-server trivia. In practice, the update raises a very useful question:

Can you name every system that sends email using your domain — and prove that its real messages authenticate correctly?

A contact form, ecommerce platform, newsletter service, CRM, WordPress plugin, booking system, password reset flow and helpdesk can all use the same visible sender domain. DMARC is therefore not DNS decoration. It is part of website operations.

What RFC 9989 changed — and what it did not

First, the reassuring part: there is no DMARC2. RFC 9989 still requires v=DMARC1.

The operationally relevant changes include:

• the old pct tag has been removed from the current specification,
• RFC 9989 adds t as a policy test mode,
• organizational-domain discovery is clarified through a defined DNS Tree Walk,
• aggregate reporting is now specified in RFC 9990 and failure reporting in RFC 9991.

That does not mean every existing domain needs an emergency DNS migration. It does mean old DMARC runbooks deserve another look.

Red flag: your rollout still depends on pct=10

Older guides often recommend moving toward p=reject gradually with pct=10, pct=25 or pct=50.

RFC 9989 deliberately removes pct. The reason is operational: receivers did not apply percentage values consistently. The current specification introduces t=y as a testing signal instead, but it is not a new percentage slider.

If your safety plan still depends on pct= behaving like a portable rollout ramp, review DNS, documentation and infrastructure-as-code. A legacy value may remain in configuration while no longer providing the behavior your team expects from the current standard.

A DMARC record does not prove a DMARC pass

A common shortcut is: “DMARC is configured because the TXT record exists.”

DMARC also evaluates alignment. At least one authenticated SPF or DKIM identifier must align with the domain in the visible From: header.

Website email often fails exactly here. The application displays contact@example.com, while the delivery provider authenticates using one of its own domains. SPF or DKIM can succeed technically without producing a DMARC pass for the domain the recipient actually sees.

That is why an audit should inspect real test messages and headers, not DNS alone.

The classic contact-form mistake

A visitor enters customer@gmail.com. The website then sends the notification with From: customer@gmail.com through the website's own mail system.

The application is now technically claiming to send on behalf of Gmail.

A more robust pattern is usually:

• From: uses an address on a domain you own and authenticate,
• Reply-To: contains the visitor's address,
• delivery uses a deliberately configured SMTP or transactional-email provider.

The team can still hit Reply without impersonating somebody else's sender domain.

SPF: do you have a complete sender inventory?

SPF defines which systems may use a domain for the SMTP envelope sender. RFC 7208 does not permit multiple independent SPF records for the same owner name.

The practical risk is configuration drift. A company starts with one mail provider, then adds a newsletter platform, CRM, shop, helpdesk or CMS plugin. Eventually nobody can explain every source.

Audit questions include:

• Which systems send today?
• Which domains and subdomains do they use?
• Are retired providers still authorized?
• Is a current provider missing?
• Are there accidentally two v=spf1 records?
• Who owns DNS changes?

DKIM: is the right service signing with the right domain?

DKIM adds a cryptographic signature. For DMARC, however, “DKIM valid” is not the whole question. The d= signing domain and its alignment with the visible From: matter too.

For organizations with multiple providers, document the provider, selector, signing domain and owner. RFC 6376 also makes key lifecycle an operational concern: during rotation, old public keys should not be removed before messages signed with them have had a reasonable validation window.

p=none is monitoring — if somebody monitors it

RFC 9989 describes p=none with aggregate reporting as Monitoring Mode. That is useful because reports can reveal legitimate senders that are still unauthenticated or unaligned.

A mailbox full of unread XML is not monitoring.

A working process should answer:

• Are reports arriving?
• Are they parsed or regularly reviewed?
• Can you detect a new sending source?
• Can you distinguish legitimate sources from suspicious ones?
• Are retired vendors removed from DNS and documentation?

RFC 9990 now defines aggregate reporting, while RFC 9991 handles failure reporting separately.

Gmail and Yahoo turn authentication into a deliverability issue

Gmail's current sender guidelines require all senders to personal Gmail accounts to use at least SPF or DKIM, TLS and additional infrastructure and message-format controls. Senders delivering more than 5,000 messages per day to Gmail have further requirements: SPF and DKIM, DMARC, visible-From alignment and one-click unsubscribe for marketing and subscribed messages.

Yahoo likewise requires authentication for all senders and applies stricter requirements to bulk senders. Yahoo's FAQ explicitly distinguishes transactional messages such as order confirmations and password resets from the marketing messages covered by its one-click requirement.

For website teams, the takeaway is straightforward:

Not every email is marketing. But every sending stream should be deliberately identified, authenticated and monitored.

Eight questions for a website email audit

1. Which applications, plugins and SaaS services send using our domains?
2. Which visible From: domains do they use?
3. Do real test messages pass SPF, DKIM and DMARC?
4. Do From:, the SPF envelope domain and DKIM d= align correctly?
5. Are there stale SPF includes, DKIM selectors or legacy pct= instructions?
6. Do contact forms use visitor addresses as Reply-To: rather than an invented external From:?
7. Are transactional and marketing streams separated and documented?
8. Can we trace bounces, deferrals and provider events for critical messages?

The final question matters: a green “message sent” state in the frontend does not prove inbox delivery. For password resets, bookings and confirmations, deliverability is part of the product.

What Website-Pflichtencheck would inspect

Depending on the setup, a technical review can include:

• public SPF, DKIM and DMARC configuration,
• sending domains and subdomains,
• controlled test messages and authentication results,
• form From: and Reply-To: behavior,
• alignment gaps,
• stale DNS records and retired providers,
• whether DMARC reports are actually consumed,
• separation of marketing and transactional mail,
• one-click unsubscribe where the specific stream and provider require it,
• bounce and failure observability for critical website email,
• documented ownership for future provider migrations.

The useful output is not merely “DMARC present: yes.” It is a sender map with concrete gaps and responsibilities.

RFC 9989 is a good trigger for this review: pct is no longer the current rollout mechanism, v=DMARC1 remains the required version value, and reporting has been separated cleanly.

But the larger operational truth is timeless:

A website can work perfectly while its most important email remains unreliable.

If enquiries, logins, orders or bookings depend on email, the sending chain belongs to the website infrastructure — and deserves to be audited like one.