I suspect Outlook overwrites `p=none` to `p=reject`, resulting in dropped emails from apache.org that lack DKIM signatures.
But apache.org hasn't configured `rua` field, so ASF won't receive any reports of these failures. On 2026/04/18 15:48:35 2380189206 wrote: > However, the fact is that @outlook.com has a DMARC policy of `p=none`, so > this shouldn't prevent ASF from **receiving** emails from @outlook.com. > > According to the Microsoft Community, users seem to have stopped receiving > emails from ASF around a specific date. ( > https://learn.microsoft.com/en-us/answers/questions/4722114/unable-to-receive-emails-from-******@ozone-apache > ) > > It appears that Outlook adjusted its inbound policy for high volume sender > around that same time. ( > https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730 > ) > > Therefore, I suspect that this specific policy change is what is causing the > failure to receive emails from ASF. > > On 2026/04/18 13:56:57 Bill Cole wrote: > > On 2026-04-17 at 16:21:27 UTC-0400 (Fri, 17 Apr 2026 16:21:27 -0400) > > Christopher Schultz <[email protected]> > > is rumored to have said: > > > > > Hello, > > > > > > It's odd anyone is blocking messages. apache.org does not have a DMARC > > > record, and so anything your email service is blocking is > > > non-standard. > > > > Not relevant. > > > > As you say, there is no DMARC record for apache.org. That means that a > > site which demands DMARC compliance cannot use SPF to validate the > > message, because the envelope sender address (a.k.a. Return-Path or > > RFC5321.MailFrom) has no record. That is salvageable iff the address in > > the From header ("RFC5322.From") is in a domain with a DMARC record. In > > the OP's case, that's qq.com, which has a 'quarantine' policy in their > > DMARC record. To validate that header for DMARC, a DKIM signature from > > qq.com needs to exist, and it does. However, the signature is broken by > > the fact that the ASF mail system adds a footer. > > > > In the fantasy world where everyone uses DMARC as designed, all ASF list > > mail would go to quarantines, because there is no successful validation > > mechanism aligned to the RFC5322.From. > > > > > apache.org appears to have 2 SPF records (both v1 and v2). Are you > > > able to get anything from one of these blocked messages (e.g. by > > > special request to your email provider)? I'd be interested to see the > > > path those messages take to get to you and if SPF alone can be blamed > > > somehow. > > > > Unlikely, since messages from ASF mailing lists have @apache.org > > RFC5321.MailFrom addresses and come from addresses listed in the SPF > > record, which is uncomplicated. (SPF v2 is irrelevant) > > > > This dilemma is present for all mailing lists. The most common approach > > is to replace the RFC5322.From header with the submission address of the > > list, and use a VERP address in the list's domain as the > > RFC5321.MailFrom. This means that SPF passes for the domain used in the > > From header, so DMARC passes. Unfortunately, this also hides the real > > sender address, which usually moved to another header. That also would > > allow the list system to sign the message with DKIM and have that > > signature used for DMARC. Just re-signing the modified message on its > > way out is not enough, without the munged From header. > > > > There's a mechanism called ARC that is supposedly capable of maintaining > > a chain of trust by recording and signing the authentication status as > > it arrives at the list, then DKIM signing the message on the way out so > > that later handlers can validate that any changes that break the > > original signature were done and signed by the list system. Support for > > ARC is extremely thin. > > > > Another approach being taken by a few lists is encapsulation: turning > > each incoming message into a message/rfc822 object as a MIME part in a > > de novo message constructed by the list server. This solves all basic > > problems with authenticating mailing list mail and introduces a big new > > one because many MUAs have no clue about accessing such messages. > > > > > > > > > -chris > > > > > > On 4/17/26 8:08 AM, 2380189206 wrote: > > >> Yes, they are all working well. > > >> > > >> On 2026/04/17 11:15:11 Gary Gregory wrote: > > >>> Do you subscribe to non-Apache mailing lists and do these come > > >>> through OK? > > >>> > > >>> Gary > > >>> > > >>> On Fri, Apr 17, 2026 at 5:34 AM 2380189206 <[email protected]> wrote: > > >>>> > > >>>> I am writing to report an ongoing email deliver-ability issue that > > >>>> has been preventing users from receiving emails from apache.org > > >>>> since at least May 2025. > > >>>> > > >>>> Emails sent from Apache mailing lists (e.g., @ozone.apache.org, > > >>>> @hadoop.apache.org, and other Apache project subdomains) are being > > >>>> blocked by Outlook. The root cause appears to be that these emails > > >>>> are not carrying DKIM signatures, which seems to have triggered > > >>>> Microsoft's security policies implemented around April 2025 ( > > >>>> https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730 > > >>>> ). > > >>>> > > >>>> This issue was first reported by users on Microsoft's community > > >>>> forum ( > > >>>> https://learn.microsoft.com/en-us/answers/questions/4722114/unable-to-receive-emails-from-******@ozone-apache > > >>>> ) as early as June 2025. In this post, the user confirmed that he > > >>>> stopped receiving messages suddenly in June 2025, and standard > > >>>> troubleshooting (safe sender lists, checking junk folders) did not > > >>>> resolve the issue, indicating it is not an isolated incident but a > > >>>> systemic infrastructure conflict between Apache's email setup and > > >>>> Outlook's filtering rules. > > >>>> > > >>>> As of today (April 2026), this problem persists ( > > >>>> https://www.reddit.com/r/Outlook/comments/1smr1x7/anyone_else_having_issues_subscribing_to_apache/ > > >>>> ). This blockage is severely disrupting communication for > > >>>> developers and users who rely on these mailing lists for critical > > >>>> project updates and support. > > >>> > > >>> --------------------------------------------------------------------- > > >>> To unsubscribe, e-mail: [email protected] > > >>> For additional commands, e-mail: [email protected] > > >>> > > >>> > > >> > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: [email protected] > > >> For additional commands, e-mail: [email protected] > > >> > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > -- > > Bill Cole > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > >
