Outlook.com en Hotmail weigeren sinds 5 november mogelijk ten onrechte e-mails: SPF-controles veroorzaken problemen bij de aflevering

Gebruikers van Outlook.com en Hotmail melden sinds 5 november problemen met het ontvangen van e-mails. Berichten van afzenders met correct ingestelde e-mailbeveiliging worden soms onverwacht geweigerd. De verzender krijgt dan een foutmelding waarin staat dat de e-mail niet voldoet aan de SPF-, DKIM- of DMARC-authenticatievereisten. Er zijn aanwijzingen dat het probleem zich niet uitsluitend voordoet bij Microsoft 365-gebruikers, maar ook bij berichten die vanuit andere e-maildiensten worden verstuurd.

Sinds 5 november zijn er steeds meer meldingen van problemen met de e-mailbezorging bij Microsofts consumentendiensten Outlook.com en Hotmail. Verschillende gebruikers geven aan dat zij niet alle e-mails ontvangen die naar hun Microsoft-e-mailadres worden verstuurd. In bepaalde gevallen worden berichten al door de servers van Microsoft geweigerd voordat ze in de inbox of de map Ongewenste e-mail terechtkomen.

Opvallend is dat niet alleen berichten van onbekende of mogelijk onbetrouwbare afzenders worden getroffen. Ook e-mails van bedrijven en organisaties die hun e-mailbeveiliging naar eigen zeggen correct hebben ingericht, worden soms afgewezen.

De verzender ontvangt in dergelijke gevallen een foutmelding waarin wordt aangegeven dat de betreffende e-mail niet aan de vereiste authenticatiecontroles voldoet. Een veelgenoemde foutmelding luidt:

550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)

Ook foutcode 550 5.7.23 wordt genoemd. Deze foutcodes wijzen op een probleem met de e-mailauthenticatie of de manier waarop de ontvangende mailserver de authenticatiegegevens beoordeelt.

Het bijzondere aan deze meldingen is dat sommige getroffen afzenders aangeven dat hun SPF-, DKIM- en DMARC-instellingen al correct zijn geconfigureerd. Bovendien lijkt het probleem niet consequent op te treden. Een e-mail die op het ene moment wordt geweigerd, kan enkele minuten later bij een nieuwe verzendpoging soms wel worden afgeleverd.

Dat maakt het probleem extra lastig te herkennen en te onderzoeken.

Wat is er precies aan de hand?

De meldingen wijzen op mogelijke problemen bij de verwerking van inkomende e-mail door de infrastructuur van Microsoft.

Wanneer iemand een e-mail naar een Outlook.com- of Hotmail-adres verstuurt, controleert de ontvangende mailserver onder meer of de verzendende server bevoegd is om namens het gebruikte domein e-mail te versturen.

Daarvoor worden verschillende beveiligingstechnieken gebruikt:

• SPF (Sender Policy Framework): controleert of het IP-adres van de verzendende mailserver volgens het SPF-record van het domein is toegestaan om e-mails namens dat domein te versturen.

• DKIM (DomainKeys Identified Mail): controleert een digitale handtekening die aan een e-mail wordt toegevoegd. Daarmee kan worden vastgesteld of de ondertekende onderdelen van het bericht onderweg zijn gewijzigd en of de handtekening overeenkomt met de gepubliceerde domeinsleutel.

• DMARC (Domain-based Message Authentication, Reporting and Conformance): bouwt voort op SPF en DKIM en controleert onder andere of het domein dat door deze technieken wordt geauthenticeerd overeenkomt met het domein dat de ontvanger in het afzenderadres ziet. Daarnaast bepaalt DMARC welk beleid voor niet-geauthenticeerde berichten geldt.

Deze technieken zijn bedoeld om misbruik van e-mailadressen tegen te gaan, bijvoorbeeld bij phishing, spoofing en andere vormen van e-mailfraude.

Het probleem ontstaat wanneer een ontvangende mailserver een bericht als niet-geauthenticeerd beoordeelt, terwijl de verzendende organisatie ervan overtuigd is dat alle benodigde beveiligingsinstellingen correct zijn.

In dat geval kan een legitieme e-mail worden geweigerd alsof deze afkomstig is van een niet-geautoriseerde server. Dat lijkt bij een deel van de huidige Outlook.com- en Hotmail-meldingen te gebeuren.

Foutmeldingen: waarom e-mails worden geweigerd

Verschillende gebruikers melden dat hun e-mailserver een foutmelding terugstuurt zodra zij een bericht naar een Outlook.com- of Hotmail-adres proberen te versturen.

Een voorbeeld daarvan is:

550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)

Een dergelijke melding betekent dat de ontvangende infrastructuur het bericht niet accepteert omdat de vereiste authenticatiegegevens ontbreken of niet als geldig worden herkend.

Dat betekent overigens niet automatisch dat de verzender daadwerkelijk een fout in zijn DNS-instellingen heeft gemaakt.

Er zijn namelijk verschillende mogelijke oorzaken:

1. Het SPF-record ontbreekt of bevat een onjuiste configuratie.
2. De verzendende mailserver staat niet vermeld als toegestane verzender in het SPF-record.
3. De DKIM-handtekening ontbreekt, is ongeldig of kan niet worden gecontroleerd.
4. Het DMARC-record ontbreekt of de authenticatie voldoet niet aan de vereiste domeinafstemming.
5. De ontvangende server kan de DNS-records tijdelijk niet goed opvragen of verwerken.
6. Er is sprake van een probleem in de verwerking van authenticatiegegevens bij de ontvangende infrastructuur.

Vooral die laatste mogelijkheid is interessant, omdat meerdere organisaties aangeven dat hun instellingen al langere tijd correct functioneren en dat de problemen plotseling zijn ontstaan.

Ook melden sommige beheerders dat slechts een deel van de berichten wordt geweigerd. Andere berichten van hetzelfde domein worden zonder problemen afgeleverd.

Dat zou kunnen wijzen op een probleem dat afhankelijk is van de gebruikte ontvangende server, de verwerking van DNS-informatie of een andere tijdelijke factor binnen de e-mailinfrastructuur van Microsoft. Dit is echter nog niet bevestigd.

Ook bedrijven met correct ingestelde SPF-, DKIM- en DMARC-records worden getroffen

Een belangrijk onderdeel van de meldingen is dat niet alle getroffen organisaties dezelfde e-mailprovider gebruiken.

Er zijn bijvoorbeeld meldingen van bedrijven die Microsoft 365 gebruiken, maar ook van organisaties die hun e-mail via andere aanbieders versturen.

Zo zijn er gebruikers die aangeven dat berichten vanuit Zoho naar Outlook.com worden geweigerd. Bij een nieuwe verzendpoging, enkele minuten later, zou hetzelfde bericht vervolgens wel zijn aangekomen.

In een dergelijk geval is het interessant om te kijken naar de authenticatieresultaten van beide verzendpogingen.

Als het opnieuw verzonden bericht volgens de ontvangstheaders wel door SPF en DKIM komt, betekent dat nog niet automatisch dat de oorspronkelijke poging dezelfde resultaten had moeten opleveren.

De twee berichten kunnen bijvoorbeeld via verschillende verzendservers of netwerkpaden zijn verwerkt. Ook kunnen er tijdelijke verschillen zijn geweest bij het opvragen of verwerken van DNS-gegevens.

Zonder de volledige foutmelding, de oorspronkelijke e-mailheaders en de bijbehorende serverlogboeken is niet met zekerheid vast te stellen waarom het eerste bericht werd geweigerd en het tweede wel werd geaccepteerd. Toch is het opvallend dat meerdere gebruikers vergelijkbare ervaringen beschrijven.

Waarom is dit probleem zo lastig te herkennen?

Het vervelende aan dit soort problemen is dat de ontvanger meestal helemaal niet merkt dat er iets misgaat.

Wanneer een bericht door Microsoft wordt geweigerd voordat het daadwerkelijk wordt afgeleverd, verschijnt het doorgaans niet in de inbox. Het bericht komt ook niet noodzakelijk in de map Ongewenste e-mail of Verwijderde items terecht.

De afzender ontvangt in plaats daarvan een zogenoemde NDR (Non-Delivery Report), ook wel een bouncebericht genoemd. Daarin staat dat de e-mail niet kon worden afgeleverd.

De ontvanger krijgt deze foutmelding niet automatisch te zien. Daardoor kan het gebeuren dat iemand dagenlang of zelfs wekenlang niet weet dat bepaalde berichten hem nooit hebben bereikt.

Dat kan vooral voor bedrijven, zelfstandigen en organisaties vervelende gevolgen hebben.

Denk bijvoorbeeld aan:

• Klanten die offertes, bestellingen of belangrijke documenten versturen.
• Leveranciers die facturen of betalingsherinneringen proberen af te leveren.
• Bedrijven die afspraken of bevestigingen per e-mail versturen.
• Sollicitanten die hun sollicitatie naar een Outlook.com-adres sturen.
• Organisaties die belangrijke informatie naar klanten communiceren.
• Particulieren die wachten op bevestigingen van reserveringen, accounts of andere diensten.

Een afzender kan denken dat een bericht gewoon is verzonden, terwijl de ontvangende Microsoft-server het bericht daadwerkelijk heeft geweigerd.

Het is daarom mogelijk dat sommige gebruikers belangrijke communicatie missen zonder dat zij daarvan op de hoogte zijn.

Heeft Microsoft de e-mailbeveiliging aangepast?

Op dit moment is er geen bevestigde informatie waaruit blijkt dat Microsoft bewust een nieuwe beveiligingsinstelling heeft ingevoerd die deze specifieke problemen veroorzaakt.

Microsoft stelt al langer eisen aan de authenticatie van e-mailberichten. Die eisen zijn bedoeld om de betrouwbaarheid van het e-mailsysteem te verbeteren en misbruik door spam- en phishingverzenders tegen te gaan.

Vooral organisaties die grote hoeveelheden e-mail versturen, moeten rekening houden met strengere authenticatievereisten.

Microsoft heeft bijvoorbeeld aanvullende eisen voor domeinen die dagelijks meer dan 5.000 berichten naar zijn persoonlijke e-maildiensten versturen. Daarbij spelen SPF, DKIM en DMARC een belangrijke rol.

Deze bestaande beleidsregels mogen echter niet zonder meer worden gezien als verklaring voor de huidige problemen.

De meldingen zijn namelijk niet beperkt tot grote verzenders. Ook kleinere organisaties en gebruikers die aanzienlijk minder berichten versturen, zeggen met dezelfde foutmeldingen te worden geconfronteerd.

Daarom is het op dit moment niet verantwoord om te concluderen dat alle getroffen berichten worden geweigerd vanwege het bestaande beleid voor bulkverzenders.

Een tijdelijke storing, een probleem met de verwerking van authenticatiegegevens of een wijziging in de serverinfrastructuur zijn mogelijke verklaringen. Microsoft heeft de precieze oorzaak van de gemelde problemen voor zover bekend nog niet publiekelijk bevestigd.

Waarom werkt het opnieuw versturen van een e-mail soms wel?

Een opvallend verschijnsel is dat verschillende gebruikers melden dat een e-mail na een nieuwe verzendpoging wel wordt afgeleverd. Dat kan verschillende technische oorzaken hebben.

E-mail wordt niet rechtstreeks van de computer van de afzender naar de inbox van de ontvanger verstuurd. Het bericht passeert doorgaans meerdere servers en beveiligingscontroles.

Afhankelijk van de gebruikte infrastructuur kan een nieuwe verzendpoging via een andere server verlopen of op een ander moment worden verwerkt.

Ook kan het zijn dat een tijdelijke DNS-storing of een probleem met het ophalen van authenticatiegegevens inmiddels is verdwenen.

Verder kan een ontvangende server bepaalde berichten anders verwerken dan een andere server binnen dezelfde infrastructuur. Dat zou kunnen verklaren waarom een bericht eerst wordt afgewezen en enkele minuten later wel wordt geaccepteerd.

Het opnieuw versturen van een bericht is daarom een mogelijke tijdelijke oplossing, maar geen structurele oplossing voor het onderliggende probleem.

Bovendien moet worden voorkomen dat ontvangers dubbele berichten krijgen wanneer de eerste verzendpoging uiteindelijk alsnog wordt afgeleverd.

Wat kun je doen als je geen e-mails ontvangt op Outlook.com of Hotmail?

Wanneer je vermoedt dat je Outlook.com- of Hotmail-account berichten mist, is het verstandig om eerst vast te stellen of de afzender daadwerkelijk een foutmelding heeft ontvangen.

Controleer daarvoor niet alleen je inbox, maar ook:

• De map Ongewenste e-mail.
• De map Verwijderde items.
• De overige beschikbare mappen en eventuele ingestelde regels.
• Eventuele blokkadelijsten en filters.
• De instellingen voor automatisch doorsturen.

Als een bericht nergens terug te vinden is, vraag de afzender dan of de e-mail daadwerkelijk is verzonden en of er een bouncebericht is teruggekomen.

Wanneer de afzender een foutmelding met code 550 5.7.1 of 550 5.7.23 ontvangt, is het belangrijk dat deze melding volledig wordt bewaard.

Daarin staan mogelijk aanvullende gegevens waarmee de oorzaak kan worden onderzocht.

Vraag de afzender eventueel om het volgende te doen:

1. De volledige foutmelding en eventuele aanvullende foutcode te bewaren.
2. Te controleren of het SPF-record van het verzendende domein correct is ingesteld.
3. Te controleren of DKIM daadwerkelijk actief is en de digitale handtekening geldig is.
4. Te controleren of er een geldig DMARC-record bestaat.
5. Na te gaan of de verzendende server daadwerkelijk is opgenomen in de SPF-configuratie.
6. De volledige e-mailheaders en relevante verzendlogboeken te bewaren.
7. De e-mail na enkele minuten opnieuw te versturen en te controleren of deze dan wel wordt afgeleverd.

Als de instellingen aantoonbaar correct zijn en berichten toch worden geweigerd, is het verstandig om de foutmelding samen met de relevante loggegevens voor te leggen aan de e-mailprovider of Microsoft Support.

Wat kunnen bedrijven en systeembeheerders doen?

Voor organisaties die afhankelijk zijn van e-mailcommunicatie is het belangrijk om niet uitsluitend af te gaan op de melding dat een bericht succesvol is verzonden.

Een verzendactie betekent namelijk niet automatisch dat het bericht ook daadwerkelijk bij de ontvanger is aangekomen.

Systeembeheerders kunnen het beste de volgende controles uitvoeren:

1. Controleer de SPF-configuratie

Controleer of het SPF-record alle servers en diensten bevat die namens het domein e-mail versturen.

Let daarbij op externe diensten zoals CRM-systemen, nieuwsbrieftools, facturatieplatforms en andere applicaties die e-mail namens de organisatie verzenden.

Een onvolledig SPF-record kan ertoe leiden dat berichten van bepaalde systemen niet worden geauthenticeerd.

2. Controleer DKIM

Controleer of de verzendende e-maildienst berichten daadwerkelijk ondertekent met DKIM.

Controleer ook of de bijbehorende publieke sleutel in DNS beschikbaar is en overeenkomt met de gebruikte ondertekeningssleutel.

3. Controleer DMARC

Controleer of het domein een geldig DMARC-record heeft.

Een DMARC-beleid met p=none kan worden gebruikt om authenticatieresultaten te monitoren zonder dat het beleid ontvangers opdraagt om berichten te weigeren of in quarantaine te plaatsen.

Dit is echter geen gegarandeerde oplossing voor een foutmelding van Microsoft. Als een ontvangende server een bericht expliciet weigert vanwege ontbrekende of ongeldige authenticatiegegevens, moet eerst worden vastgesteld welke controle precies faalt.

4. Onderzoek de volledige foutmelding

De SMTP-foutcode, aanvullende Microsoft-code, het tijdstip van verzending en de betrokken ontvangende server zijn belangrijke gegevens.

Zonder die informatie is het lastig om onderscheid te maken tussen een fout in de eigen configuratie en een mogelijk probleem aan de ontvangende kant.

5. Test verschillende e-mailproviders

Wanneer berichten naar Gmail of andere e-maildiensten wel aankomen, maar naar Outlook.com of Hotmail worden geweigerd, kan dat een aanwijzing zijn dat het probleem specifiek samenhangt met de verwerking door Microsoft.

Het bewijst echter niet automatisch dat Microsoft de oorzaak is.

6. Houd afleveringsproblemen bij

Bewaar bounceberichten en registreer welke berichten worden geweigerd, op welke tijdstippen dit gebeurt en of nieuwe verzendpogingen wel slagen.

Op die manier kan worden vastgesteld of er sprake is van een incidenteel probleem of een structureel afleveringsprobleem.

Is er inmiddels een oplossing?

Vooralsnog is er geen algemeen bevestigde oplossing voor alle gemelde problemen.

Het opnieuw versturen van een geweigerde e-mail lijkt in sommige gevallen te werken. Ook melden enkele gebruikers dat zij na het controleren en aanpassen van hun DNS-authenticatie-instellingen geen nieuwe problemen meer hebben ondervonden.

Zo gaf een gebruiker aan dat zijn organisatie een ontbrekend DMARC-record ontdekte en vervolgens een record met het beleid p=none toevoegde. Daarna zouden nieuwe testberichten zonder problemen zijn afgeleverd.

Dat is nuttige informatie, maar het bewijst niet dat een ontbrekend DMARC-record de oorzaak is van alle meldingen.

Er zijn namelijk ook organisaties die aangeven dat hun SPF-, DKIM- en DMARC-configuratie al correct was voordat de problemen begonnen.

Het is daarom belangrijk om niet zomaar DNS-records aan te passen zonder eerst de bestaande configuratie en de daadwerkelijke foutmeldingen te controleren. Een onnodige wijziging kan de e-mailbezorging juist verder verstoren.

Door: Drifter