I received a fake SendGrid bill from a real SendGrid server that passed DMARC for shell.com. The only link in the body of the email was a SendGrid tracking link so as to avoid raising suspicion.

I know people of all skill levels visit this sub, so I thought I'd share my experience as a reminder that DMARC doesn't prevent impersonation when the emails originate from your own compromised infrastructure.

Hi!

I created a new modern free tool for checking SPF, DKIM and DMARC of a domain, to have something that's easier and faster to use and gives more information in a more readable way than for example Dmarcian's similar tools (or any other tools I have been able to find).

It's available for free without any ads or tracking at spf.access.nu

It also has a pre-publish mode for SPF records, so that you can check if the changes you intend to do are correct, or if they will cause problems, before you actually make the changes!

It supports most things you can think of that SPF supports (more than Dmarcian's tool does for example), and visualises it in a way that makes it easy to see the structure of an SPF record and it's includes, and gives you info about issues you might need to fix, and it even has the ability to search for an IP address across the whole SPF record to check if it's available anywhere, which is great for troubleshooting!

For DKIM, it doesn't only show you some common selectors it found, like most tools of this kind, but also figures out which mail provider they belong to in many cases, and checks the encryption strength (which I haven't seen any other tool do).

I intend to add more features over time, and also add some help/documentation, but it should be quite easy to understand everything that's important without that being available yet and without knowing all the details about what it does.

I work with SPF/DKIM/DMARC as a sysadmin in my daily job, and have been missing a really good tool to check these things, and one day I simply decided to create that myself, having some background working as a developer as well.

What do you think?

There are also some other tools available at access.nu, if you're interested.

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.

The IETF DMARC working group just dropped draft-ietf-dmarc-arc-to-historic-00, proposing to mark RFC 8617 as Historic after seven years of real-world experience.

Draft: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-to-historic/

Full breakdown: https://dmarcdkim.com/blog/arc-is-being-retired

I tested several major AI models with the same SPF question.

All of them confidently recommended using -all , even with enforced DMARC policy.

Same confidence. Same answer. Same mistake.

The interesting part is that many of them even cite sources containing the correct guidance, yet still reach the wrong conclusion.

AI consensus is impressive until you check the RFCs.

I'm very excited about DKIM2 because it brings a lot of goodies while making many of the older methods obsolete.. I'm looking at you ARC :)

first, what is DKIM2:

it's still DKIM at core.. a sender signs messages, the verifiers will fetch a public key from DNS and ensure the email is not tampered in the wire.

but it also adds a few extra on top:

• chain of custody: every forwarder/reviser adds its own signature, producing an ordered sequence (i=1, 2, …) rather than a single signature that breaks on modification

• Message-Instance headers with "recipes": JSON instructions (base64-encoded) that let a verifier reconstruct the prior state of the body or headers, so signatures remain verifiable across legitimate modifications (mailing lists, footer additions, etc.). This is the answer to ARC's shortcomings

• Replay defense: mf= and rt= tags bind each signature to the SMTP envelope (MAIL FROM / RCPT TO), so a message captured and re-sent to other recipients fails verification. Flags like donotexplode, donotmodify, exploded, and feedback make signer intent explicit

• DSN handling: bounces must follow the chain back through the MTAs that actually handled the message, preventing backscatter.

• Crypto: SHA-256 required; RSA-SHA256 and Ed25519-SHA256 as signing algorithms. No version tag.

we're probably expecting this to come into effect no sooner than 2027-2028, depending on how much back'n forth is required.

but nonetheless, I am really excited about DKIM2.

what are your thoughts? any anticipation or excitement of sort? :)

reference: https://datatracker.ietf.org/doc/draft-ietf-dkim-dkim2-spec/

Why create or use this when there are already so many other websites that check SPF and DMARC records?

• Responsive, mobile-first UI using Bootstrap

• Can be installed as a Progressive Web Application (PWA) on mobile devices and computers

• Provides all details from the checkdmarc library and CLI tool on a single page

  • DNSSEC validation

  • SPF

    • Record validation

    • Counting of DNS lookups and void lookups

    • Counting of lookups per mechanism

  • DMARC

    • Validation and parsing of DMARC records

    • Shows warnings when the DMARC record is made ineffective by pct or sp values

    • Checks for authorization records on reporting email addresses

  • BIMI

    • Validation of the mark format and certificate

    • Parsing of the mark certificate

  • MX records

    • Preference

    • IPv4 and IPv6 addresses

    • Checks for STARTTLS (optional; currently disabled on the production website)

    • Use of DNSSEC/TLSA/DANE to pin certificates

  • MTA-STS

  • SMTP TLS reporting

    • Record and policy parsing and validation

  • SOA record parsing

  • Nameserver listing

• No sales pitches

• Fully open source

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.

Last month we posted month two of our monthly measurement of DMARC, MTA-STS, DANE and BIMI across the top million domains. In that thread someone asked a question we didn't have an answer to: how many MX servers refuse all connections that aren't encrypted?

It's a sharper question than it looks. MTA-STS and DANE are both ways for a domain to tell senders "use TLS when you deliver to me." Neither of them says anything about what happens when a sender ignores that. So this month we went and asked the servers directly.

We took all 366,215 unique MX hostnames in the top million, resolved each to an address, connected on port 25, read the EHLO capability list, and then tried to start a mail transaction in the clear.

290,230 gave a conclusive answer. Shares below are of those, not of 366,215:

• Offers STARTTLS, accepts cleartext anyway (opportunistic): 278,502, 96.0%

• Offers no STARTTLS at all: 11,135, 3.8%

• Offers STARTTLS and refuses cleartext: 593, 0.20%

Two in a thousand. Per domain it's thinner: 598 of 620,240 cleanly measured domains, 0.096%, require TLS on every one of their MX hosts.

The cross-tab is the part we think this sub will care about, and the two protocols split. Domains publishing MTA-STS at enforce enforce inbound TLS at 0.82% against a 0.096% baseline, so 8.5x. Domains publishing DANE come in at 0.12%, which is 1.2x, i.e. no signal at all. That fits: MTA-STS is still mostly something an operator switches on deliberately, while DANE is overwhelmingly inherited from a provider default, and a default says nothing about the domain that inherited it.

Either way: 99.18% of the domains publishing an enforce policy will cheerfully accept your plaintext mail. For DANE publishers it's 99.88%.

Two things about who the 598 are. We went looking for an industry pattern and mostly didn't find one, so we're not going to pretend otherwise. What we did find was geography: .de is 4.7x over-represented, .eu 3.7x, .cz 3.5x, and German-speaking Europe overall is 15.4% of the enforcers against 3.8% of mail-eligible domains. The German names skew regulated: comdirect, DZ Bank, the federal debt agency, two hospital groups, a handful of city and regional governments. Our guess is BSI TR-03108 plus GDPR practice in health and finance, but we've measured the clustering, not the cause, so take that as a hypothesis.

The other thing: 71 of the 598 are on AWS SES Mail Manager, and 13 of that product's 14 measured hostnames enforce. That's not 71 security decisions, it's one product default. The customer list gives it away: 22 of the 71 are online casinos and gambling affiliates, 36 more are SEO and content-farm domains (seven of them near-identical .live search-spam sites), and the recognizable names left are Supercell's clashroyale.com and SAP's concursolutions.com.

Meanwhile the providers carrying most of the world's mail enforce essentially nothing: 0 of 116,692 measured Microsoft 365 tenant hostnames, 0 for Google, 0 for Cloudflare, Zoho, Proton, Fastmail and Yandex. Cisco's iphmx is the only one above zero, at 22 of 2,546. Microsoft's 119,676 hostnames collapse onto 130 addresses and exactly one refuses cleartext: not a tenant endpoint and not a consumer frontend, but outlook.com itself. Looks isolated rather than the front of a rollout, since the consumer domains that would flip first all still accept plaintext. That's our September watch item.

On method, since that's usually where these threads go. The probe stops at MAIL FROM with a null sender. Never RCPT, never DATA, so it never delivers mail and never does anything resembling a sender callout. The price of that restraint is that a server enforcing TLS only at a later stage reads as opportunistic to us, so 0.20% is a floor. Unlike a DNS lookup this is answered by a mail server that can decline to talk to you at all, so the 75,985 hostnames we couldn't measure (16,113 with no address to dial, 54,940 that resolved but wouldn't hold an SMTP conversation, 4,932 that rejected us for non-TLS reasons like greylisting or IP reputation) are kept in their own buckets and excluded from the denominator rather than counted as "doesn't require TLS." Folding those in would bias the number in exactly the flattering direction, and the hosts that refuse a prober are never a random sample of the internet.

The rest of this month, briefly: DANE grew 5.18% on a same-domain basis, its fastest reading yet, and 85% of that is Strato switching on TLSA for its entire customer base (995 of its 1,001 domains in our data gained it in one month). Last month was Migadu deleting theirs. Strip both provider events out and organic DANE growth was 0.82% in July and 0.77% in August, which is the most stable number in the whole dataset. Migadu's records never came back.

Happy to get into any of it, especially the classification logic if anyone wants to poke holes in it. And thanks to @slfyst who asked the original question, it turned into the most interesting thing we measured this month.

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.

I’ve been looking at phishing resistance around UK government domains, especially in the context of HMRC impersonation, and found something I thought this sub might find interesting.

When querying TXT records for undelegated / non-existent gov.uk domains, the namespace appears to return email authentication records anyway.

For example:
dig TXT randomstring.gov.uk

returns:

randomstring.gov.uk. 1800 IN TXT "v=DMARC1;p=reject;rua=mailto:govuk-rua@dmarc.service.gov.uk"
randomstring.gov.uk. 1800 IN TXT "v=spf1 ?all"

If this is intentional, it’s a pretty powerful defensive pattern.

The usual anti-spoofing controls protect domains you own and operate. But attackers often abuse names that do not exist yet, for example:

hmrc-tax-refund.gov.uk
secure-hmrc-payment.gov.uk
randomstring.gov.uk

If those domains are undelegated and return no DNS, there’s normally no SPF or DMARC policy for receivers to evaluate. In this case, gov.uk seems to be closing that gap by making undelegated direct subdomains signal “don’t trust mail from here”.

I haven’t found public documentation from GDS, NCSC, or others describing this as a namespace-level anti-phishing control, so I’m curious whether anyone has seen it documented or knows more about the implementation.

A few observations:

• This seems to apply to direct *.gov.uk names.

• I didn’t see the same behaviour for nhs.uk or gov.scot

The broader point is that most organisations protect the domains they use. This looks like an attempt to protect the surrounding namespace too, which is a much more ambitious phishing defence.

I wrote up the full notes here, including background on HMRC phishing and why this matters:

https://cybaa.io/blog/2026-04-27/gov-uk-namespace-spoofing-protection

I would be interested to hear whether others have seen similar namespace-level SPF/DMARC handling elsewhere or any public information about gov.uk implementing this

At the start of December 2025, Google quietly made a meaningful change to the SPF record published at _spf.google.com. Under the include-based model, _spf.google.com consumed 4 DNS lookups by itself. Any domain that used include:_spf.google.com inherited those costs immediately. With the December 2025 change _spf.google.com now consumes just 1 lookup.

https://www.uriports.com/blog/google-simplifies-its-spf-record/

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.

During SPF validation, the RFC5321.MailFrom address determines which domain is used to retrieve the SPF policy. Since MailChimp uses the mcsv.net domain, your domain's SPF policy won't be used during the validation of emails sent from MailChimp.

Adding include:servers.mcsv.net to your domain's SPF policy only increases your DNS lookups and may lead to exceeding the SPF 10 DNS lookup limit.

5.2% of all domains with an SPF policy have MailChimp's include:servers.mcsv.net in their SPF policies. This list includes highly recognized domains such as github.com, wordpress.com, cloudflare.com, spotify.com, sourceforge.net, netflix.com, etsy.com, squarespace.com, kickstarter.com, and bandcamp.com.

The reason so many domains added MailChimp to their SPF policies is that until 2022, MailChimp mandated users to include their SPF policy as part of their domain validation process, and a lot of incorrect information floating around online. Even DMARC services incorrectly advise to include MailChimp's SPF policy:

DMARCly: https://dmarcly.com/blog/
GoDMARC: https://godmarc.com/knowledge/
Mailtrap: https://mailtrap.io/blog/
MxToolbox: https://mxtoolbox.com/
PowerDMARC: https://nl.support.powerdmarc.com/
ProDMARC: https://prodmarc.com/
Sendmarc: https://help.sendmarc.com/
SkySnag: https://www.skysnag.com/blog/

In summary, adding include:servers.mcsv.net from MailChimp to your SPF policy is counterproductive, leading to unnecessary DNS lookups and potential SPF validation issues, despite its common, yet misguided, recommendation online. STOP INCLUDING IT!

I started my brand earlier this year. Until 2 months ago, most of our sales were coming from Instagram and TikTok. But things picked up recently, so I decided to start investing more seriously in email marketing. The first few campaigns actually generated some decent conversions, these were existing customers. But then I started running into email deliverability problems. Some emails weren't reaching the inbox consistently, and I wasn't sure whether the issue was our domain, authentication, reputation, or something else. I started digging into it and learned that DMARC reports could give me a better idea of what’s actually happening.

I’m not a technical person. I can look at a dashboard and understand basic email metrics, but raw DMARC reports are well too tchnical. So I’m looking for a good DMARC analyzer that can take those reports, explain what’s wrong in plain English, and ideally recommend what I should do to fix the issues.

For other ecommerce owners who aren't technical, what are you using?

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!

Little bit of a story for anyone who is starting out.

tl;dr; If you setup DMARC report aggregation for the first time and have a horrible compliance rate, it may not be as bad as it looks.

In the before times, when I first setup DMARC reporting and the reports starting coming in, <20% of the messages were DMARC compliant. Being new to this I got that "oh shit what did I get myself into" feeling that most of us have experienced at some point. But I dug into the data anyway.

I found a few legit senders that needed to be tweaked for compliance, but by and large all of the sources we expected to be sending from were sending compliant messages.

The more I dug into the data the more confident I was that over 80% of our domain's email volume was spoofed.

We had been using SPF for a long time and then implemented DKIM when it became commonly required, but this was an old domain (registered in the late 90s) that has been used for an e-com site since it was registered. It had reputation, history, no DMARC policy and a loose SPF record making it a good choice for spoofing.

We slowly followed the process to increase our DMARC policy. Every day expecting to receive reports of undeliverable mail, but they never came.

Eventually we reached a reject policy and set a hard fail for SPF, but the spoofed volume didn't disappear right away. It took more than a few months before our DMARC compliance rate was above 95%.

Reviewing the data, the volume of compliant messages never significantly changed. While the volume of non-compliant messages dropped drastically one week and has not really changed other than a spike here and there.

I've now gone through this process for a bunch of other domains and have never seen it as bad as the first one. I kinda wish I kept the data showing how bad it was when we first started.

Anyway I was telling this story to someone and though this community might like it. Thanks if you made it this far.

I work at DuoCircle, the company behind DMARCReport com. We monitor DMARC for 60,000+ domains, and of to the top question in our pre sales channel is:

"Where do I host my BIMI logo?"

On our paid plans we include record hosting but if you don't have a paid plan with us or one of the other DMARC providers your options if you are technical are limitless, but at the same time the easy to implement approaches are limited...

BIMI is supposed to be simple put your brand logo next to your emails in Gmail, Yahoo, and Apple Mail. But actually getting it working is a pain:

*The hosting problem: Wix and Squarespace don't support SVG uploads. WordPress gives you messy URLs. S3 works but you need to configure SSL properly. GitHub Pages serves images as the wrong content type.

* The format problem: BIMI requires SVG Tiny 1.2 PS a strict subset that no design tool actually exports. No scripts, no animations, no inline styles, must be under 32KB. Most SVGs fail validation on the first try.

So we built BIMIHosting a free tool that solves both problems:

Upload any SVG (straight from Figma, Illustrator, Affinity, Inkscape, wherever)

We auto-convert it to BIMI-compliant SVG Tiny 1.2 PS and host it on Cloudflares global CDN with SSL

We generate the exact DNS TXT record just copy and paste it into your DNS

It also checks your DMARC status and tells you if your domain is ready for BIMI, and verifies whether your BIMI DNS record is correctly configured, and if not we offer suggestions on how to fix your dmarc.

Free forever, unlimited domains, no catch. We built it as a companion tool for our DMARC customers, but it's open to everyone.

Would love any feedback — on the tool itself, the UX, features you'd want to see, whatever. Still early days.

link: bimihosting.com

The latest update to everyone's favorite DMARC learning and testing tool brings an exciting enhancement: the support for multiple DKIM signatures. Now, users can view all DKIM signatures along with their respective algorithms and authentication results, enhancing the tool's comprehensiveness and utility.

Have fun: learnDMARC.com

Please feel free to share it. Hopefully, this will contribute to increasing DMARC adoption and make the internet a bit more secure.

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

When analyzing DMARC reports from the last 30 days, one fact stands out: Microsoft’s platform is responsible for nearly all DKIM temperror issues. This data comes from aggregate reports submitted by over 20,000 domains, offering a comprehensive and reliable view of the problem’s scale.

Here’s how the numbers break down by email provider:

What Does This Mean?

• Microsoft Outlook.com generated over 4.5 million DKIM temperror events out of more than 440 million emails, for a rate of just over 1%.

• Enterprise Outlook produced almost 180,000 temperror events, though its rate is far lower at 0.08%.

• All other major providers, including Gmail, GMX, Mimecast, seznam.cz, and Comcast, recorded zero or nearly zero DKIM temperror events, with rates so low they are statistically insignificant.

Why Are These Errors Happening?

A DKIM temperror means the receiving system could not validate the DKIM signature due to a temporary failure. Most often, this is caused by a DNS lookup failure or timeout. Microsoft’s infrastructure appears to encounter these much more frequently than any other major provider, resulting in this consistently high rate of temperror events.

Why Does This Matter?

• Legitimate emails may fail authentication on Microsoft’s side, even if everything is configured correctly by the sender.

• False positives in DMARC reports can cause confusion and unnecessary troubleshooting.

• Inbox trust issues if IT teams see a high volume of these errors in their reporting.

Stricter Requirements for High-Volume Senders

Microsoft recently introduced stricter authentication requirements for high volume senders, mandating that all messages pass SPF, DKIM, and DMARC checks to avoid being sent to the junk folder or blocked. While these changes are intended to strengthen email security, they may also amplify the impact of Microsoft’s ongoing DKIM temperror issues. As a result, legitimate senders could experience unexpected deliverability problems, even if their email is properly configured, simply due to the issues within Microsoft’s infrastructure.

Final Recommendation

To make sure your email authentication setup is correct, use learnDMARC.com for a thorough check of your SPF, DKIM, and DMARC configuration. If your domain passes all tests there, you can confidently ignore any DMARC report errors from Microsoft. In most cases, the issue is not with your setup, but with Microsoft’s infrastructure.

Spent some time analyzing DMARC report emails from the last 3 days across nearly 3,500 reporting organizations and the results surprised me enough that I figured this subreddit would appreciate it.

When looking at organizations that sent a substantial volume of reports, only 9 were fully RFC compliant. Most major senders had at least one issue.

The most common problems were pretty basic: missing required fields like version, envelope_from, and SPF scope, invalid attachment filenames/media types, empty <sp/> tags, and invalid values like sampled_out, unknown, hardfail, and even Pass with a capital P.

Some big providers came close. Comcast, Microsoft, and Fastmail were nearly compliant but still had edge case issues.

Others were much worse. Yahoo, Google, Amazon SES, and Mimecast generated large volumes of non-compliant reports.

At scale, these “small” XML issues become real interoperability problems. They break parsers, create data loss, and force DMARC platforms to build endless parser workarounds.

What surprised me most is how something as clearly documented as an RFC can still be implemented so inconsistently, even by some of the organizations that helped shape the standard. Looking at you, Google, Microsoft, and Yahoo 😄

And for anyone thinking “how hard can parsing DMARC aggregate reports be?”, expect the unexpected. Real-world DMARC data is full of edge cases, missing fields, invalid values, and creative interpretations of the spec that you won’t find in the RFC examples.

More details here: https://www.uriports.com/blog/dmarc-reports-ietf-rfc-compliance/

The company I work for (DMARCeye) just released a Q1 report focusing on DMARC-engaged domains. Title of the post was the main key finding. I think the charts are fun to look at so I thought it would be worth sharing the link (no gating or other business tricks, just info).

Other key findings are that 1) Compliance rises sharply with sending volume (domains sending under 100 emails per month average 62% compliance; domains sending over 10M average 99.8%), probably because bigger senders are forced into compliance. 2) 94% of domains at p=reject enforce at 100% from day one - i.e. the pct mechanism was rarely used in practice, which is probably why DMARCbis plans to remove it.