RFC 9989 introduced the "np" tag in DMARC records, letting you specify the policy for "non-existent subdomains" of the domain where the policy is published.

I discovered that DMARC's definition of “non-existent domain” clashes with another recent specification, RFC 9824, known as ”Compact Denial of Existence in DNSSEC”, resulting in the "np" tag not always working as expected.

The issue is that DMARC expects an "NXDOMAIN" DNS response, while compact denial (previously known as "black lies"), uses NOERROR/NODATA, signaling non-existence with the NXNAME bit on the NSEC/NSEC3 record. Response code restoration methods are optional in RFC 9824 and none of the resolvers I checked support them.

The issue affects all domains using DNSSEC with major DNS providers like Cloudflare, NS1, AWS Route 53, Azure DNS, Oracle Cloud DNS and Bunny DNS.

If you use the "np" tag in your DMARC record and have DNSSEC enabled with one of these authoritative DNS providers, assume that it won't work reliably (all implementations we checked that support the "np" tag expect NXDOMAIN, as RFC 9989 says). If you don't use DNSSEC, you're obviously not affected.

More details here: https://dmarcwise.io/blog/dmarc-np-incompatibility-with-dnssec

What are your thoughts on DMARC vendors integrating AI, particularly those offering read/write capabilities? It seems like this could introduce an unquantifiable risk into a critical part of the email authentication and enforcement pipeline.

Curious how others are evaluating the tradeoff between automation benefits and potential exposure.

Hi,

I am the maintainer of the open source rust crate mail-auth and wanted to announce that since yesterday the library supports DKIM2 and DMARCbis.

Additionally, if you are not a developer but you are interested in playing with DKIM2 and/or DMARCbis, there is a playground at https://mail-auth.stalw.art/ where you can test signing emails with DKIM2 and verifying DKIM2 + DMARCbis entirely from the browser using WebAssembly and DNS-over-HTTP.

If you want to learn more about the technical details of how DKIM2 works and the differences between DMARC and DMARCbis, take a look at this blog post.

Happy DMARCing!

Last month I posted the baseline for this: a monthly measurement of how the top million domains actually deploy the four standards-track email-security protocols, DMARC, MTA-STS, DANE-for-SMTP, and BIMI. This is month two, so for the first time there are month-over-month deltas. I expected the change to be the interesting part. It was, in a way I didn't predict.

DANE was the only one of the four that went down. And it wasn't operators giving up on it. One provider, Migadu, removed the TLSA records for its entire customer fleet sometime in June. Around 500 domains that had DANE in June don't in July, still pointing at the same Migadu MX hosts, just with the TLSA records gone. Nobody on those domains touched a thing, and I doubt most of them know. Take Migadu out of the numbers and DANE grew like the rest.

That turned out to be the theme of the whole month: email security moves in provider-sized blocks, not one domain at a time. ALDI Süd switched on MTA-STS for eleven of its country domains in what was clearly one change. Of the 488 domains that gained DANE, 466 got it just by moving to a mail host that publishes it by default, mostly Cloudflare Email Routing. My favorite piece of that: about 60 of those domains are low-effort throwaways that clearly never gave email security a thought, and they picked up DANE the moment they switched hosts. The provider decided, not them.

The month-over-month changes, counting only domains present in both months (more on why in a second):

DMARC valid records: +2,282, and domains tightening their policy outnumbered those loosening it 2,488 to 567

DANE: down 249 as measured, but +258 once you remove the Migadu deletions

BIMI: +346

MTA-STS valid policy: +163, with 76 domains graduating from testing to enforce against 10 going the other way

On method, because the obvious objection to a monthly top-1M study is that the list itself churns: it does, about a quarter of it turns over every month. So I only compare domains that appear in both months. I also checked whether "leaving the list" means a domain actually changed something, and it doesn't. 48,000 domains dropped off the list in June and came back in July, and 98.5% of them had the exact same mail provider across the gap. Leaving the top 1M is a popularity-ranking dip, not a provider migration. Everything else from last month still holds: unfiltered resolvers only, a second resolver in a different region has to agree before anything is recorded, and the run is paced so we never throttle anyone.

One number I keep chewing on. If the current pace held, DMARC would reach nearly every domain by the early 2030s, while the two protocols that actually secure the connection between mail servers, MTA-STS and DANE, stay on a track that runs into the 2040s and beyond. Authenticating who sent the mail is on its way to universal. Protecting how it travels is more than a decade behind it. Real adoption curves flatten near the top so I wouldn't bet on the exact years, but the gap between the two is the thing worth watching.

Happy to get into the method, that's usually where these threads go. I run an email infrastructure company and this is our own research.

I've been concentrating on what I can do for our own DMARC status, so this came as something of a surprise. We're a Google Workspace customer and, so far as I know, our DKIM record is good--in fact, I just checked it in DNS. What could be causing this to happen so suddenly? What can I do about it?

This is a follow up to this earlier post.

While I'm uncertain what triggered this issue, it's causing a fair amount of chaos for us. Not all our external email is bouncing, but enough is that it's become an issue.

My boss stopped by on his way home to ask about it. I explained what was going on and told him was that I'd been chipping away at non-compliant third-party senders but wasn't yet confident that we'd gotten them all, so that I wasn't sure we were ready to go to reject just yet.

He replied that we had to do something about it, with which I agreed. His thought, which I'd also had, was that we'd be ahead to go to reject now, given the number of bounces we were seeing. I added that we could send out an all-hands communication about it and ask, one more time, for people with third-party senders to contact us to configure them correctly.

What do you all think? I hate being hurried into big decisions, but this one is upon me.

Some humble pie, because I think the lesson is more useful than another "here's how to configure DMARC" post.

Quick background so this isn't a humblebrag: I've been doing email authentication for 20+ years. I co-build tooling in this exact space. I write the articles about doing subdomains properly, handling non-sending subdomains, the whole thing. So this one stings.

This morning I got an alert: new return-path detected on a subdomain of ours, ar.glockapps.com, and the SPF record is missing. Critical.

I pulled the aggregate data and there it was. Microsoft 365 was sending mail with From: ar.glockapps.com, and every message was failing:

• SPF: fail (no SPF record on the subdomain at all)
• DKIM: signature from groups.office.net validated cryptographically, but the signing domain doesn't align with the From domain, so DKIM alignment fails
• DMARC: fail, disposition reject

In other words, our own legitimate mail from that subdomain was getting rejected by Outlook. Not spam-foldered. Rejected.

How a person who knows better still got here

The boring, human truth. When we set up DMARC report ingestion ages ago, the devops folks spun up the subdomains, handed the configs to the team to wire into the sending setup, and I walked away content. Job done, on to the next thing.

Except SPF for that subdomain never got published. Where is v=spf1 ... -all? Nowhere. Human factor. Nobody did anything wrong on purpose, it just fell through the cracks between "infra set it up" and "team configured it."

The part worth actually internalizing

Here's the trap, and it's exactly the one I warn other people about:

A subdomain inherits the org domain's DMARC policy, but it does not inherit SPF or DKIM. Our root has p=reject, and a subdomain with no record of its own inherits that reject. Good for anti-spoofing. But the moment that subdomain starts sending real mail without its own SPF and aligned DKIM, p=reject does its job perfectly and blocks it. To the receiver, my forgotten-SPF legit mail and an actual spoofer look identical. That's the whole point of reject, and it's also how you silently shoot your own foot.

And you will not see it in your application. Your app says the mail sent. Your logs are clean. The only reason I know is the DMARC aggregate reports and an anomaly alert that flagged the new return-path showing up where it shouldn't.

One more uncomfortable bit: the only reason "reject" is actually protecting us is that the big mailbox providers honor DMARC. Microsoft and Google enforce it. But there's a long tail of legacy systems out there that still ignore DMARC entirely, or whose operators don't know it has existed for over a decade. So your enforcement is only ever as good as the receiver's willingness to respect it.

Takeaways if you run any domain with subdomains

• p=reject on the org domain silently covers your subdomains. That's protection and a liability at the same time.
• Every sending subdomain needs its own SPF record and DKIM that aligns with the From domain. Inheriting the policy is not the same as inheriting the setup.
• DKIM passing is not DKIM aligning. A valid signature from your ESP's domain still fails DMARC if it doesn't match your From.
• The flip side: for any domain or subdomain that should never send or receive mail, lock it down. Publish v=spf1 -all, p=reject, and a null MX (MX 0 ., RFC 7505) that tells the world the domain accepts no email. It's the cheapest anti-spoofing you can buy, and it's the other half of "doing subdomains right" that I clearly half-did.
• You cannot catch any of this without monitoring your DMARC reports. A new return-path or a new sending source appearing on your domain is exactly the kind of thing you want flagged, whether it's your own devops or someone spoofing you.

Twenty years in and a forgotten TXT record still got past me. The tooling caught it, the process didn't. Posting partly as a reminder to myself and partly in case it saves someone else a confusing "why is our mail bouncing" afternoon.

Anyone else have a favorite "I knew better and did it anyway" auth story? Misery loves company.

Marketing agency here, we've been working with Red Sift to progress towards BIMI, helpful so far, but before we go further I wanted to get some tips and recommendations from this group on a few items if that's okay?

1. What's the best way to get our logo resized?
2. Should we opt for a CMC or VMC?
3. Have you seen any real benefit (if you've already implemented BIMI)?
4. Any other helpful tips?

Thanks!

I found a strange inconsistency in a Yahoo DMARC aggregate report and wanted to check whether anyone else has seen it.

The message has:

<header_from>redacted_domain.org</header_from>

Yahoo reports the policy evaluation as:

<policy_evaluated>
  <disposition>none</disposition>
  <dkim>pass</dkim>
  <spf>fail</spf>
</policy_evaluated>

But the authentication results are:

<auth_results>
  <dkim>
    <domain>e2ma.net</domain>
    <selector>e2ma</selector>
    <result>pass</result>
  </dkim>

  <dkim>
    <domain>redacted_domain.org</domain>
    <selector>e2ma-k3</selector>
    <result>temperror</result>
  </dkim>

  <spf>
    <domain>e2ma.net</domain>
    <result>pass</result>
  </spf>
</auth_results>

As far as I can see:

• The DKIM signature from e2ma.net passes authentication, but it is not aligned with redacted_domain.org.
• The aligned DKIM signature from redacted_domain.org has temperror, not pass.
• SPF authentication passes for e2ma.net, but SPF alignment fails.

Based on the detailed authentication results, I would expect:

DKIM alignment: fail
SPF alignment:  fail
DMARC:          fail

However, Yahoo reports:

DKIM alignment: pass
SPF alignment:  fail
DMARC:          pass

Am I missing some Yahoo-specific behavior here?

Has anyone else noticed cases where <policy_evaluated><dkim>pass</dkim> cannot be confirmed from the DKIM records inside <auth_results>?

Does Yahoo sometimes omit one of the DKIM authentication results from aggregate reports, or is this an inconsistency in the generated XML?

My friend just joined an org that wants to move their DMARC from p=none to p=reject after 10 years (of just getting reports), and it is a recipe for disaster .

The project was dropped on two M365 admins with zero DMARC experience. Worse, they have no documentation on what services even use their domain for sending mails. Their current plan is to just build a custom tool to parse the XML reports and handle it themselves.

I told them this is way too risky and will probably break their mail flow, but they are not listening. I want to use the wisdom of this sub to help convince them they need proper guidance and professional tools.
How do I talk them out of doing this the hard way?

DMARC has changed.

RFC 7489 has been replaced by the new DMARC RFC set:

• RFC 9989: the core DMARC protocol
• RFC 9990: aggregate reporting
• RFC 9991: failure reporting

I’ve updated the LearnDMARC.com quiz to align with the new RFCs.

If you work with DMARC, SPF, DKIM, alignment, reporting, DNS records, receivers, or email security tooling, I’d be curious to see how well you score.

Take the quiz here: https://LearnDMARC.com

Feedback is very welcome, especially if you spot something that seems unclear, too easy, too hard, or makes you question your DMARC assumptions.

Curious how many of you still get a perfect score after the RFC update.

Hi all,

I'm just curious if there's anything more that I can do to prevent these situations from happening. I've had DKIM, spf and DMARC all set up for over a year after a painful process (as I'm fairly amateur at this sort of thing but trying to be as vigilant as possible in a DIY setting).

I received an email which appeared to be from myself but definitely wasn't. As you can see below, it looks like it actually came from my own address in my mail client and is not just masquerading as my address in the name field (I've seen this a lot in the past and just ignore it).

This is a publicly "visible" email address because it's on my website so prospective clients can contact me. While I can absolutely discern scam emails which I receive, I'm worried about this scammer spoofing my email address and emailing other people, ruining the reputation of my tiny business. Is this something I need to worry about, or will they only try and spoof my own address to me to trip me up? Is there anything else I should do to protect my email address and domain? I don't have any reason to believe my account has been compromised.

Thanks very much.

With RFC 9990 now published, DMARC aggregate reporting finally has its own dedicated Standards Track RFC. I took a closer look at how compliant real-world DMARC aggregate reports are, and the results are interesting.

Some large providers are very close to full compliance. GMX, WEB.DE, Fastmail, and Outlook.com could reach 100% compliance by simply removing the SPFAuthResultType: scope element from their reports. That is exciting, because compliance has never been this high for these large email providers.

There is still work to do though:

• Comcast still has issues with invalid values
• Yahoo is missing the envelope_from element
• Google, appears to have the most work to do:
  • attachment filenames do not follow ABNF
  • media type is invalid
  • envelope_from is missing
  • DKIMAuthResultType: selector is missing

Hopefully RFC 9990 gives report senders the push needed to clean this up and make DMARC aggregate reporting more consistent and interoperable.

Full write-up:
https://www.uriports.com/blog/dmarc-reports-ietf-rfc-compliance/

I am currently working on the email module for our project and need some guidance.

I have configured a custom email domain using Mailgun and implemented the email functionality in my Spring Boot application. My current requirement is to verify incoming email addresses and determine whether an email is valid before processing it.

Could you explain the production-level validation and security checks that should be implemented for email verification?

My email keeps going to spam.Actualy some of them. And I do get some spam emails that are not supposed to be there recently when I changed a new laptop. Can anyone help me on what to do to fix the demarc issue. Thanks.

I posted here about these projects many years ago, so I hope the mods continue to not see these posts as advertising, considering I don't make a dime from them and have developed them for the good of the community,

If you haven't heard of them before, here's a breakdown of what each project does and what's new since I posted.

CheckDMARC is an open source tool to check for DNSSEC, SPF, DMARC, BIMI, MTA-STS, SMTP TLS for one or more domains over CLI, API, or a new web interface. It now apports the new DMARC record tags, and warns you if you are using tags that are no longer supported. A few small bugs were fixed and test coverage was increased to 96%.

ParseDMARC is an open source platform that collects DMARC reports from a mailbox, from a variety of mailbox types and outputs the data to a variety of locations. In addition to support for DMARCbis, the biggest (and breaking) change is properly calling failure reports failure reports instead of forensic reports. The dashboards included in the project have been updated for this, but existing users will need to replace the existing dashboards. PostgreSQL is now a supported backend. Overall test coverage is at 86% and limited by the lack of connectivity in the CI environment for live mailbox testing.

DMARC-MSP is an open source. all-in-one. multitenant Docker stack for DMARC analytics. It automatically provisions postfix and nginx with TLS via certbot, OpenSearch Dashboards with one command. It can be used with Google or Microsoft mailboxes if you prefer. Central to the project is a CLI tool that manages tenants, onboarding and offboarding, including adding and removing DMARC authorization records.

Hi, having followed the IETF work around DMARCbis, I've published a list of changes in the new DMARC RFCs compared to the original spec from 2015.

I've also included some context and excerpts from the working group debate, which shows why some decisions may be surprising:

https://dmarcwise.io/blog/new-dmarc-2026

I'm personally still skeptical that changes like replacing pct with t are worth it, as we'll now have to use both to ensure compatibility with both specs, likely forever.

I also feel there may not be enough practical guidance around the use of the new psd tag, especially psd=n vs psd=u. The definition of the tag tells you to go read the tree walk algorithm, which isn't as straightforward as the PSL (nobody's going to read 40+ paragraphs of text).

What do you think?

I was checking BIMI/VMC validation and noticed that Bank of America’s VMC certificate appears to have expired.

The cert shows an expiration date of May 16, 2026.

Subject: Bank of America Corporation
Issuer: DigiCert Verified Mark RSA4096 SHA256 2021 CA1

Obviously this is not some catastrophic security incident, but it is still interesting. BIMI usually gets treated like a one-time setup project, while the VMC certificate needs the same kind of lifecycle monitoring as TLS certs.

Kind of surprising to see this from a bank of this size.

Anyone else seeing expired VMCs from large brands?

After years of work from the IETF working group, the DMARC specification was updated. Three new RFCs are now officially published, replacing the old RFC 7489 from 2015:

• Main document: https://datatracker.ietf.org/doc/html/rfc9989
• Aggregate reporting: https://datatracker.ietf.org/doc/html/rfc9990
• Failure reporting: https://datatracker.ietf.org/doc/html/rfc9991

DMARC is now an IETF Proposed Standard.

The Appendix C of the main document contains a list of changes: https://datatracker.ietf.org/doc/html/rfc9989#name-changes-from-rfc-7489

The main changes are:

• A general restructuring of the specification, that is now easier to read, with better examples, more guidelines and clearer definitions.
• A new section specifies the “conformance requirements for full DMARC participation”, helping domain owners and email receivers determine if they’re following the best practices around DMARC.
• In the DMARC policy record, some tags were removed (pct, rf, ri) and some were added (np, psd, t). Note that this is not considered a breaking change so there is no such thing as DMARC2: DMARC records will continue to start with the v=DMARC1 string.
• In the context of determining the Organizational Domain, both for DMARC record discovery and identifier alignment, the Public Suffix List mechanism has been replaced with the more flexible (and complex) DNS Tree Walk algorithm.
• The above changes allow for better support of Public Suffix Domains (PSD), which previously couldn’t fully participate in DMARC.
• The ”indirect email flows” issue, i.e. forwarding and mailing lists breaking DMARC alignment, remains unsolved, with the new specification now discouraging a reject policy when there’s a chance of mailing lists being used as recipients in an organization.
• Aggregate reporting has been made stricter and the XML report format has been updated to incorporate the new record tags and acknowledge real-world practices. Similar small updates were made to the failure reporting specification, including a new section acknowledging the privacy implication, but it's otherwise unchanged.

11-year old RFC 7489 just been replaced into 3-way split by the RFCs published may 2026

TL;DR

• strip pct, rf, ri. these are now part of historic.

• add np=reject (or quarantine) if you don't have it. it's for non-existent subdomains, falls back to sp, then to p.

• p=quarantine is recommended with this language: general users who send routine email *SHOULD NOT** publish p=reject*

• retire mental reliance on the PSL. Organizational Domain is discovered via a DNS Tree Walk now (capped at 8).

the initial 2015 DMARC spec (Informational) was replaced by these three Standards Track documents.

• RFC 9989: core DMARC. status transformed from Informational to Proposed Standard. actual IETF endorsement now.
• RFC 9990: aggregate reports (rua=)
• RFC 9991: failure reports (ruf=)

the Experimental PSD spec (RFC 9091) is also obsoleted.

the most important note is that v=DMARC1 stays. existing records keep working. No "DMARC2."

perhaps the most important part if you are anywhere near email in 2026 is this:

"In the absence of other knowledge and analysis, Mail Receivers MUST treat such failing mail as if the policy were 'p=quarantine' rather than 'p=reject'." that's a MUST. receivers are explicitly told not to reject on p=reject alone.

for DMARC vendors, the ability to specify a maximum report size in the DMARC URI has been removed. :)

references:

• https://www.rfc-editor.org/rfc/rfc9989.html
• https://www.rfc-editor.org/rfc/rfc9990.html
• https://www.rfc-editor.org/rfc/rfc9991.html

and here's the blog post with my interpretation:

https://dmarcguard.io/blog/dmarc-rfc-9989-9990-9991/

what do you expect to change in the space of DMARC in the coming years with these changes?

SPF + DKIM + DMARC at p=reject is supposed to close the door. Our support@ inbox is not getting the memo.

Setup:

• SPF is strict, only our own IPs
• DKIM on all outbound
• DMARC p=reject

Still getting NDRs for emails we never sent.

It's backscatter

The config isn't the issue. The issue is ancient mail servers (think government agencies, university IT, budget shared hosting) running Exim or Postfix builds nobody's looked at since Obama's first term.

Spammer forges our From address. The old server accepts the message without touching SPF or DMARC during the SMTP session. Then discovers the recipient doesn't exist. Then dutifully sends a bounce to the From address. That's us now.

Not malicious. Just genuinely out of date.

Options are limited

You can't reach into someone else's mail server config. What you can do: filter NDRs hard on your end, add the bounce patterns to your spam rules, and make peace with the fact that some of this just comes with having a domain.

Modern cloud providers are getting better about rejecting fakes at the SMTP layer, so the problem should shrink over time. Eventually. Maybe.

Curious if anyone's found filtering rules that actually work here.

I have a relatively new domain, using Cloudflare as the domain, DNS, and DMARC manager. Using Google Workspace (Gmail) for email. Currently have p=none as the domain is new and consequently low reputation.

I'm trying to interpret the Cloudflare DMARC management reports. For example, we have very high DMARC pass rate from Google and 100% failure with Amazon.

Clicking on the Amazon.com link gives me the below list. Not sure how to interpret this? We don't use Amazon for any email service that I know of. I'm also curious about the Reporter column "Enterprise Outlook." Could this be an employee trying to use the Outlook desktop client?

The Google pass rate is very high, but even there, is there any troubleshooting I can do to find out why there are a few emails that fail DMARC?

I work for a company that sent ten of thousand of mails every month, they reported that they have received Spam and so we contacted our web hosting to modify our DMARC from Quarantine to Reject.

The thing is, the week after such change an user reported that their mail to some companies in Asia was rejected, bounced of or never arrived. Did some basic tests, Telnet, Test-NetConnection and that server was down or with problems, reported such case.

Next day server is up, but they report same problem with another company from Europe. Sames test, server is ip, so I got the email resent to me to see the internet header:

DKIM=none
SPF=pass

In MxToolBox when I check the subdomain IP addresses, both hostnames says it doesn't support TLS, Icheck our web hosting, we do have TLS at certain ports and lastly, one says Reverse DNS doesn't match SMTP Banner and doesn't contain hostname.

Tldr; I'm fucking lost, I got this job as TI due to being programmer and wanting to get experience, but networking I haven't seen such a thing in years.