Exchange Online en SPF faliures bij ontvangers

[Blokker_1999]

De laatste weken krijgen we regelmatig melding van klanten van de firma dat onze mails soms niet aankomen bij hen. De logging op onze mail security appliance geeft evenwel aan dat de mails bij ons netjes vertrekken. Een gemeenschappelijke factor bij al deze klanten is dat zij allemaal Exchange Online gebruiken en dat wij onze mail dus ook bij EXO afleveren.

Nadat we enkele klanten zo ver hebben gekregen van ons headers te bezorgen van emails die bij hen in quarantaine terecht komen merkten we al vrij snel iets vreemds op. Er zit inderdaad een permanente SPF failure op, maar dan vanwegen een IP address dat toebehoord aan een mailserver van Exchange Online. Verdere analyse van de headers toont ook aan dat elke mail zowat door 5 of 6 verschillende servers gaat binnen de EXO omgeving, waaronder een outbound verbinding, net alsof EXO de mail dus opnieuw extern doorstuurt naar een andere omgeving waarbij de andere omgeving er dan voor kiest om de SPF te valideren met als bron de EXO server van Microsoft.


Resultaat is dan ook dat wanneer je de header leest, je gewoon een staalharde SPF fail krijgt, bijvoorbeeld:

code:

Authentication-Results: spf=permerror (sender IP is 2a01:111:f403:c201::3)
 smtp.mailfrom=domain.tld; dkim=pass (signature was verified)
 header.d=domain.tld;dkim=pass (signature was verified)
 header.d=domain.tld;dkim=fail (body hash did not verify)
 header.d=domain.tld;dmarc=pass action=none
 header.from=domain.tld;compauth=pass reason=100
Received-SPF: PermError (protection.outlook.com: domain of omp.com used an
 invalid SPF mechanism)

En we begrijpen niet waarom dat dit ineens faalt. De eerste rapporten zijn ondertussen een maand oud, maar we krijgen steeds meer rapporten van gebruikers die melden dat externe ontvangers niet alle mails krijgen. Wat dan ook weer aantoont dat andere mails, die langs dezelfde weg naar buiten gaan, ook gewoon aankomen bij die externe ontvangers.

Ondertussen hebben we het spf record voor outlook.com ook toegevoegd en dat lijkt het probleem op het eerste zich op te lossen, maar we zouden graag begrijpen waar dit probleem in 1 keer vandaan komt. Daar het zich voor doet aan de ontvangende kant lijkt het ons namelijk onwaarschijnlijk dat dit komt door een aanpassing aan onze kant.

Hoewel we zelf ook in Exchange Online werken, zitten we vandaag nog met centralized transport die de mail via ons mail security appliance die we on-premise hebben naar buiten stuurt. Het gaat hier dus niet om mail die rechtstreeks van EXO naar EXO gaat.

[Marc H]

header.d=domain.tld;dkim=fail (body hash did not verify)

Daar hebben we een eerste aanknopingspunt. Voor verzenden wordt er van de body van het mailtje een hash berekend. Bij ontvangst wordt die opnieuw berekend om te zien of het bericht niet onderweg gewijzigd is.

Hier failed die hash controle en daarom denkt de ontvangende mailserver dat het bericht gewijzigd is.

[Blokker_1999]

Maar elke aanpassing hoort aan de ontvangende kant te gebeuren. Onze interne mail infra past de body namelijk niet meer aan wanneer de gebruiker op verzenden duwt. Daarnaast doet het probleem zich ook exclusief in Exchange Online voor. Ontvangers die bijvoorbeeld Gmail gebruiken hebben hier geen last van.

Bijkomend is dat dkim, en dat zou geen enkele invloed mogen hebben op SPF.

En om dat verder te verklaren, die DKIM hash check gaat falen wanneer de ontvanger zelf het bericht aanpast, bijvoorbeeld om een waarschuwing te injecteren dat dit een externe email is. Dus DKIM failures op body hash bij ontvangst zijn geen uitzondering.

[ Voor 36% gewijzigd door Blokker_1999 op 01-08-2025 13:37 ]

[winux]

Heeft je SPF record meer dan 10 lookups? Dat zou deze fout kunnen veroorzaken.


TIP:

Zet DMARC reporting aan op je domein. Als je dit nog niet heb.

Dit geeft je meer details over wat er fout gaat.

Als je bijvoorbeeld dmarcadvisor.com gebruikt (NL bedrijf) is gratis voor persoonlijk gebruik.

Die geven ook advies over de aanpassingen die benodigd zijn.

[ Voor 14% gewijzigd door winux op 06-08-2025 11:52 ]

[Bartosy]

Toevallig veel mensen op vakantie OOF of auto reply/forwarding actief dat wilt soms ook wel wat problemen op SPF vlak geven.

[Blokker_1999]

Er zitten zeker geen 10 lookups in onze SPF, al hebben we er nu dus wel weer 1 extra, iets wat we op termijn toch hadden moeten doen.

Zoals aangehaald, het probleem zit niet in onze config voor zover we weten. Het probleem doet zich enkel voor wanneer er mail naar andere Exchange Online tenants wordt gestuurd. Daarbij routeert MS blijkbaar de mail terug naar hun edge waarna ze opnieuw valideren of je SPF record klopt maar dan klot het niet meer omdat de verzender ineens Exhange Online zelf is, welke door de hybride setup met centralized transport via onze on-prem naar het internet, niet in de SPF record staat.

[winux]

Gebruikt de mail security toevallig bounce verification?

Zou je dat mail flow eens kunnen schetsen?