Een Authentication-Results header wordt normaal gesproken gezet door een ontvangende mailserver. (In dit geval zou dat natuurlijk de 2e hop in het M365 netwerk kunnen zijn.)
Waar hier security.nl staat, is de authserv-id, meestal de hostname van de mailserver die de authenticatie uitvoert of anders een unieke string die later herkenbaar is voor de rest van de keten ... van dus de ontvangende partij!
Deze headers kunnen dan bijvoorbeeld worden gebruikt door een DMARC milter.

https://tools.ietf.org/html/rfc8601#section-2.5

Hoe dan ook, als M365 hier (jouw voorbeeld) security.nl zet, dan klopt er inderdaad iets niet.

Ik vind het maar een raar verhaal. In mijn beeld is Authentication-Results: niet gekoppeld aan het To: CC: of BCC:
domein maar aan het From: domein en de envelope sender. DIE bepalen de DKIM results e.d. op de plek waar die
header wordt toegevoegd, waar die mail heen gaat heeft daar niks mee te maken.
Ik denk dat het een resultaat is van het gebruik van hetzelfde domein in zowel From: als BCC: en als gevolg daarvan
ontstane verwarring bij de melder.

Klopt! Tenzij je spammer bent natuurlijk.

Reken maar dat het een complex knooppunt is daar (het zou me verbazen als ze daar nooit een vette loop hebben gehad die de boel lamlegde).

Vandaar dat ik meteen dacht aan de situatie waarbij security.nl-e-mail door Microsoft gehost zou worden (zie mijn "Nb." over amnesty.org).

Vijfentwintig jaar geleden leerde ik, door schade en schande, dat men het Bcc: veld nooit moet vertrouwen als het om een vertrouwlijke correspondentie gericht aan meerdere ontvangers gaat. Dan kun je beter het To: veld gebruiken, om daarmee iedere geadresseerde een afzonderlijke mail te versturen -- met gebruikmaking van GPG of S/MIME.

Het probleem is dat men in het geval van een Bcc: de werking en configuratie van de ontvangende mailserver niet onder eigen controle heeft. Dat kan betekenen dat je naderhand van een koude kermis thuis komt. Heden ten dage verstuur ik nog steeds maar hoogst zelden een Bcc: email, en als ik er één ontvang -- dan vertrouw ik die niet.

Ja, maar Bcc introduceert wel complexiteit: je kunt natuurlijk niet het DATA deel van een e-mail (met daarin potentieel Bcc adressen) digitaal signeren en later die Bcc adressen verwijderen. Uit efficiency-oogpunt zou je, bij meerdere MTA's in het uitgaande deel (ook spam en AV-check) het liefst alles bij elkaar willen houden in één blob. En bij het afleveren alle mails bestemd voor meerdere gebruikers in één domein, in één transactie (multiple RCPT TO) willen afhandelen.

Dat zoiets fout kan gaan zie je "mooi" in https://talk.plesk.com/threads/315-duplicate-dkim-signatures-in-one-email-header.340713/ en https://talk.plesk.com/threads/multiple-dkim-headers-added-when-having-multiple-bcc-addresses.342217/, waarbij de uitgaande MTA per Bcc een DKIM signature toevoegde.

Aangezien de melder zeer stellig is en het lek bevestigd wordt door "cosmogfd" in https://old.reddit.com/r/Office365/comments/n3qky1/office_365_leaking_bcc_domain_name/gwrmsyg/, heb ik het sterke vermoeden dat er wel degelijk ergens een fout zit in de complexe mail-infra van Microsoft (anders had ik dat niet hier gepost).

Maar die spammer weet niet welk authserv-id mijn mailservers gebruiken. En mochten ze het juist hebben geraden, dan sloopt mijn server ze eraf (MUST in jouw link) voor hij nieuwe zet. :-)
Zelfs dan zouden ze die domeinnaam niet als authserv-id moeten gebruiken.
Authserv-id dient als "bewijs" dat de header is gezet door een eigen (of anderszins vertrouwde) server.

Bij mij worden door twee verschillende milters SPF en DKIM gecontroleerd. Deze milters zetten een Authentication-Results header met het resultaat en die headers worden weer gebruikt door de DMARC milter, die dan ook weer een Authentication-Results zet (of een reject doorgeeft aan de MTA).

Het tweede antwoord (van EML dat begint met "Very late, but the accepted answer is essentially wrong") in https://stackoverflow.com/questions/2750211/sending-bcc-emails-using-a-smtp-server laat zien dat het allemaal niet zo simpel is ("You can persuade Sendmail to keep the Bcc if you want to").

Ik gebruik sendmail en ben die instelling nog nooit tegengekomen. Ook een snelle DDG zoektocht leverde niks op behalve jouw link. Wat overigens niet wil zeggen dat het daarom niet mogelijk zou zijn, want sendmail kun je ongeveer alles laten doen, behalve koffie zetten en zelfs daar ben ik niet zeker van.

Echter, misschien dat het vijfentwintig jaar geleden vaak fout liep, maar als je een beetje moderne MUA als Thunderbird gebruikt krijgt de MTA de header niet eens te zien...
Alle adressen, ongeacht of ze To, CC, of BCC zijn worden verstuurd in de 'RCPT TO' fase en TB stuurt in de DATA geen BCC header mee.
Als ik in mijn scripts BCC's zet, worden ze in (mijn redelijk standaard) sendmail verwijderd.

Ik begrijp even niet waar dit over gaat. Niet alleen kun je zelf bij het signen (DKIM) bepalen welke headers je signed en dus die BCC niet meenemen, maar bovendien zet (zoals Anoniem 17:55 ook al aangeeft) een beetje mailer helemaal geen BCC header in de verstuurde mail, dat is ook nergens voor nodig want die info staat in de RCPT TO regels van de SMTP sessie.

Dat antwoord linkt naar RFC 2822, dat over het berichtformaat gaat en niet over SMTP. Wat daarin staat over drie manieren om met de Bcc-header om te gaan gaat niet per se over hoe er in de SMTP-afhandeling mee wordt omgegaan, dit is breder dan alleen dat.
Traditioneel hebben *nix-systemen naast SMTP een andere interface naar de locaal draaiende MTA. Het sendmail-commando (onderdeel van de MTA, geïntroduceerd door de MTA die sendmail heet) plaatst een e-mail in een maildrop-directory, waar de MTA het oppakt en verder verwerkt.

Bij die manier van werken worden er nog geen SMTP-commando's gebruikt, en is er een manier nodig om Bcc-adressen door te geven. Ik heb het niet nagekeken, maar het ligt erg voor de hand dat er dan een Bcc-header wordt opgenomen die wordt gebruikt om bestemmingen te specificeren maar die zelf uit de headers wordt verwijderd.

Zoals ik het SMTP-protocol begrijp hoort hooguit de originating MTA (de eerste die een e-mail afhandelt op weg naar de bestemming) wijzigingen aan te brengen, en de rest mag alleen headers bovenaan toevoegen en blijft af van wat er verder instaat.

RFC 5321 (SMTP-specificatie) noemt in paragraaf 6.4 over het afhandelen van fouten in de aanlevering een discussie over de voors en tegens van compenseren, en concludeert:

https://tools.ietf.org/html/rfc5321#section-6.4

Zoals ik dat lees zijn de correcties die een MTA mag aanbrengen heel beperkt (de drie die genoemd worden), en mogen ze alleen door de MTA die de e-mail van de client in ontvangst neemt gedaan worden, de rest "weet" al niet genoeg om te kunnen beoordelen wat de bedoeling is. Bcc wordt hier niet genoemd.

Bcc wordt in RFC 5321 op twee plaatsen genoemd:
• In paragraaf 7.2 wordt gemeld dat adressen in RCPT-commando's die niet in de headers voorkomen (dat zijn Bcc's) ook niet zelf aan de headers moeten toevoegen. Daar staat ook dat die regel vaak wordt geschonden en dat MTA's om dat voor te zijn voor elke Bcc een apart bericht met die Bcc als enige bestemming kunnen doorgeven aan de volgende MTA.
• In appendix B, over het genereren van SMTP-commando's uit headers, wordt aanbevolen dat een MUA (mail user agent, een e-mailclient) de envelope-informatie die in de SMTP-dialoog belandt gescheiden van het bericht aanlevert, en dat als het toch door de ontvangende MTA wordt gedaan die de Bcc-header verwijdert als de envelope-informatie is afgeleid. Dit slaat op de MTA die de e-mail van de MUA ontvangt, en dat is dus de originating SMTP server uit paragraaf 6.4 hierboven.
https://tools.ietf.org/html/rfc5321#section-7.2
https://tools.ietf.org/html/rfc5321#appendix-B

Bij elkaar opgeteld komt het er volgens mij op neer dat de norm is dat Bcc alleen door een client als header wordt opgenomen als de bestemmingsadressen niet buiten de inhoud van het bericht (inclusief headers) om worden aangeleverd aan de MTA. In dat geval verwijdert de MTA de Bcc-header. Voor zover mij bekend gebeurt dit alleen bij gebruik van een maildrop-directory waar een client een e-mail inplaatst en een MTA geplaatste berichten uit oppakt. In alle andere gevallen moet een client al geen Bcc-header genereren, blijft een MTA van de headers af, en zorgt die er alleen voor dat die zelf geen e-mailadressen in de zelf toegevoegde headers opneemt die niet al in de headers staan.

Als M365 inderdaad de domeinnaam van de eerste Bcc wél in de headers opneemt schendt het strikt genomen niet deze norm, omdat het geen volledig e-mailadres is. Maar in sommige situaties is het natuurlijk voor de ontvanger duidelijk wie de andere ontvanger zal zijn geweest, en het geeft hoe dan ook prijs dát er een andere ontvanger is. Ook zo'n domein moet dus niet in de headers belanden.

Maar dat "sendmail" commando heeft traditioneel de bestemmingsadressen als argumenten van de programma aanroep.
De mogelijkheid om alleen een file aan te leveren en alle info uit de headers te halen (-t optie) is volgens mij iets wat
er "later" bij gemaakt is... de manpage zegt erover:

-t Read message for recipients. To:, Cc:, and Bcc: lines will be
scanned for recipient addresses. The Bcc: line will be deleted
before transmission.

Toepassingen van sendmail die ik zelf gezien en/of gemaakt heb die geven -f mee en dan het from adres en de
bestemmingsadressen. Dan doen de headers er niet toe. Ik zou dan ook geen Bcc header erin zetten.

Je hebt gelijk. Dat krijg je als je op je herinneringen afgaat en niet elk detail checkt, herinneringen slijten...

Ik vraag me wel af wat ik heb gezien als ik e-mails in de maildrop-directory bekeek, wat ik ongetwijfeld wel eens gedaan heb toen ik met Postfix kennis aan het maken was, en of ik misschien heb gezien dat daar e-mailheaders aan waren toegevoegd en daar dat beeld aan heb overgehouden. Ik ga nu geen mailservers installeren om die vraag te beantwoorden ;-).

Meestal staan er in die directory 2 files per mail, de ene bevat de mailbody en de andere bevat de routing informatie voor
de mail (zoals alle bestemmingsadressen) en de headers in een "geparsede" vorm waar het mailprogramma weer een
nieuwe set headers uit maakt bij verzenden.
Er kan ook nog een file zijn die aangeeft wat de status van verzending is (bijv dat het al een tijdje niet lukt hem te verzenden).

Maar hoe dan ook is het niet de bedoeling dat programma's zelf files in die directory zetten, dat moet via het sendmail
commando en gaat dan met die beschreven -f of -t optie (en andere opties). Tegenwoordig gaat het meestal ook niet
direct naar de verzendqueue directory maar is er een aparte submit queue voor lokale mail. Van daar gaat het dan naar
de verzendqueue via een aparte submit daemon.

Enkele off-topic antwoorden (geen verwijt, ik ben zelf met theoriën over mogelijke oorzaken begonnen).

Niet onmogelijk maar je moet er moeite voor doen om dat soort info geheim te houden, vooral als het statisch is. Wat komt er in bounce-messages bij niet bestaande gebruikers? Wat gaat er mee "naar buiten" als iemand een mail incl. headers als bijlage bijsluit?

Als je niet alle bestaande "Authentication-Results:" onconditioneel eruit sloopt kunnen deze bewust gemanipuleerde info bevatten die mensen op het verkeerde been kunnen zetten en soms geautomatiseerde systemen kunnen misleiden.

Internet barst van de legacy systemen. Het zou mij bijvoorbeeld niet verbazen als Outlook het opsplitsen van recipients aan Exchange overlaat. Ook bij de good old commandline programma's "elm" en "mail" zou dit zomaar kunnen. Out of the box ondersteunen IMAP en POP3 niet het verzenden van mail, maar extensies daarop zouden dat kunnen toevoegen voor specifieke MUA's. Ik heb geen idee of webclients zoals bijv. RoundCube Bcc zelf uitsplitsen of dit aan een speciaal daarvoor geconfigureerde MTA overlaten.

In ThunderBird "copy self" mails staat een Bcc header als je die velden hebt gebruikt, en zo te zien ook in drafts (tot je op Send drukt). Ook al worden blobs met een Bcc regel niet via SMTP verzonden door TB, zijn er wel instances waarin die Bcc regel(s) voorkomen. Dergelijke blobs als bijlage toevoegen kan dus weer (onverwachte) privacy-risico's opleveren. Zelfs als je ze forward, maar dan is de Bcc regel wel zichtbaar.

@Anoniem vandaag 09:22: dank voor jouw RFC uitzoekwerk, helder!

On topic:
Exact. Los van hoe dat zou kunnen gebeuren, zijn er situaties denkbaar waarmee vertrouwelijke informatie wordt gelekt (zoals in mails naar kandidaten bij een aanbesteding).

Mijn server bounced niet, maar reject en laat dus de NDR over aan de verzendende mailserver.
Bouncen doe je als de mail al is aangenomen en je server daarna besluit dat de user niet bestaat. Eigenlijk not done omdat de afzender nogal eens wordt vervalst door spammers.
V.w.b. een mail als bijlage zou je wel eens gelijk kunnen hebben, maar dit zou dan waarschijnlijk een mail zijn die ze zelf hebben verstuurd en uit de Sent map hebben gevist.De RFC zegt MUST voor AR headers met je eigen authserv-id... Hierdoor zouden dus de headers met de juiste authserv-id betrouwbaar moeten zijn.
Als mensen zelf headers gaan analyseren zouden ze ook moeten weten dat alles wat onder de headers staat die door je "eigen" mailserver zijn gezet, in principe onbetrouwbaar is.
Door er andere headers uit te slopen loop je een grote kans DKIM handtekeningen te verknallen. Ik ben er sowieso niet voor om headers uit mails te slopen.