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] > >
