E-mail komt niet aan ("is niet gevonden")

[Eagle Creek]

Hi,

Ik heb een probleem met een gebruiker in mijn 0365-tenant. De gebruiker is ergens afgelopen week aangemaakt, zit netjes in een groep en heeft relevante licenties toegewezen gekregen.

De gebruiker kan mail versturen naar de buitenwereld, en ontvangen vanuit het tenant-domein. Als iemand echter vanuit de buitenwereld een e-mail stuurt, komt er een NDR terug met de melding "X is niet gevonden in Y.nl."

Your message was rejected by the recipient's domain because the recipient's email address isn't listed in the domain's directory. It might be misspelled or it might not exist. Try to fix the problem by doing one or more of the following:

DB3EUR04FT052.mail.protection.outlook.com gave this error:
Recipient address rejected: Access denied. AS(201806281) [DB3EUR04FT052.eop-eur04.prod.protection.outlook.com 2023-05-03T15:08:04.868Z 08DB4B8AF9D93BB8]

Statuscode: 550 5.4.1

Foutdetails
Fout: 550 5.4.1 Recipient address rejected: Access denied. AS(201806281) [VI1EUR04FT054.eop-eur04.prod.protection.outlook.com 2023-05-03T15:00:34.759Z 08DB4BD584B90229]
Bericht geweigerd door: VI1EUR04FT054.mail.protection.outlook.com


Meldingsdetails
Verzonden door: AS8PR03MB10126.eurprd03.prod.outlook.com

https://learn.microsoft.c...5-1-10-in-exchange-online

Aan de gebruiker z'n instellingen kan ik geen afwijkingen terugvinden. Microsoft documentatie schrijft de foutcode veelal toe aan mailflows, DNS-settings en MX-records, aparte connectors, etc. allemaal zaken waar ik niet aan heb gezeten en die voor andere gebruikers m.i. dan ook een probleem zouden moeten zijn.

Als afzender naar de gebruiker heb ik verschillende adressen gebruikt, o.a. outlook.com en twee verschillende andere adressen.

Het probleem doet zich nu al enkele dagen voor en lijkt niet uit zichzelf weg te gaan.
Als ik de Reports > Mail flow > Non-delivery report erbij pak, lijkt de e-mail überhaupt niet binnengekomen te zijn. Of ik moet in de verkeerde hoek zoeken maar er is geen spoor van de e-mail te vinden.

Het e-mailadres is uiteraard juist getypt (en niet onthouden), de gebruiker bestaat en heeft geen forwarding-regel ingesteld. Het betreft geen hybride omgeving.


Wie kan mij een duwtje in de juiste richting geven?

[ Voor 7% gewijzigd door Eagle Creek op 03-05-2023 17:20 ]

[mrmrmr]

Als de Microsoft MX server aan de buitenwereld laat weten de gebruiker niet te kennen gebeurt dat waarschijnlijk als foutmelding gedurende een SMTP sessie. De Microsoft mail server neemt de mail niet aan en weigert het. Het is vervolgens aan de verzendende mail server om terug te rapporteren aan de verzender dat er een probleem is.

Als de verzender een non-delivery bericht ontvangt van de eigen mail server, waarin staat dat de gebruiker onbekend is, is de gebruiker waarschijnlijk niet aanwezig in de database die de Microsoft MX server gebruikt. Mogelijk is er iets mis gegaan met de registratie, of is er een restore gedaan waarbij de gebruiker gedeeltelijk aanwezig is. Of heeft de gebruiker niet de benodigde rechten/permissies. Zie ook:
https://support.exclaimer...s-rejected-Access-denied-

Generieke troubleshooting (selfservice):
Je kan een testgebruiker aanmaken en kijken of die dezelfde problemen heeft. Zo weet je of het een structureel probleem is. Als die testgebruiker geen probleem heeft, dan zou je kunnen overwegen de bestaande berichten van de gebruiker te exporteren, de gebruiker te verwijderen, en opnieuw aan te maken. Dit niet al te snel achter elkaar. Daarna kun je de geexporteerde berichten weer importeren.

Als dat niet wenselijk is, zou ik verder zoeken op internet of contact opnemen met Microsoft.

[akimosan]

Ik neig toch naar de meest logische optie, dat er een stom klein typfoutje is geslopen bij het aanmaken van het SMTP adres van de gebruiker, op wat voor manier dan ook.

Bijvoorbeeld een punt of spatie aan begin of eind die niet opvalt

Controleer en vervang voor de zekerheid het SMTP adres nogmaals via de relevante admin console.
Wacht even op eventuele replicatie
Laat gebruiker een testmail versturen naar een test email adres buiten de organisatie domein naam.
Stuur een reply vanaf dat testadres.
Komt reply aan? Mooi, opgelost
Komt reply niet aan? Analyseer headers van bericht zoals aangekomen op het testadres (mxtoolbox.com kan hierbij helpen)

[Cergorach]

Heeft de gebruiker al eens aangemeld op de O365 webmail, ik heb vaker gezien dat als je dat niet deed bij een nieuw account de mailbox gewoon nog niet provisioned was en de mailserver er ook niets naartoe kan sturen. Gezien je zegt dat de gebruiker wel kan versturen zou het zo kunnen zijn dat dit is gebeurd nadat de eerste mailtjes zijn gefaald, je kan dat checken in de mailflow van wanneer de gebruiker de eerste mail zelf heeft gestuurd. En vergelijk dat met of dat emailtje voor of na die datum is gestuurd. Vaak hebben (grote) organisaties dan weer een beveiliging dat ze niet twee keer een email sturen naar hetzelfde adres.

Kan het zijn dat jullie een user provisioning systeem hebben? Het gebeurt wel eens dat de naam niet goed is opgegeven, dat verkeerd wordt aangemaakt en op dag #1 zegt gebruiker (of leiding gevende eerder): Naam klopt niet! Naam wordt aangepast, maar niet overal correct. Dit kunnen lastig op te merken veranderingen zijn zoals voornaam en achternaam omgedraait een i als een l of een hoofdletter I als een kleine l...

De kans is gewoon groot dat het inderdaad een typfoutje is, maar voordat je in die hoek gaat kijken, ga eerst zelf testen. Pak een niet-Microsoft email dienst (zoals Google Mail) en email naar dat email adres en kijk of het dan wel netjes binnenkomt (volg de mailflow aan de Exchange Online kant). Als dit niet goed gaat, check eens je MX records.

Als dat netjes binnenkomt, even checken of je ergens in de mailflow een email van diezelfde persoon/organisatie je binnen ziet komen om een ander email adres in de organisatie. Of vraag of de verzender die de bounce krijgt jou wil mailen (op hetzelfde domein op je O365 tenant) met een testmail. Als dat ook werkt weet je dat het ook niet geblokt wordt door MS voor een andere reden op jou domein.

Dan zou je de verzender wellicht exact het email adres kunnen mailen zoals deze in je admin interface staat (copy/paste).

Als dat ook niet werkt, wellicht even contact zoeken met de beheerder van hun email server/domein, dan kan je mogelijk mail flows naast elkaar leggen om te vergelijken.

Een hoop mensen voelen alsof dat heel onprofessioneel overkomt, zeker aan de klant kant (verzender), maar als je dat netjes communiceert en weet op te lossen is dat vaak juist een heel goede en persoonlijke indruk van je organisatie. Maar zorg er voor dat je eerst aan je eigen kant alles heb gecheckt, voordat je bij de eindklant gaat checken.

[Eagle Creek]

mrmrmr schreef op woensdag 3 mei 2023 @ 17:37:
Als de verzender een non-delivery bericht ontvangt van de eigen mail server, waarin staat dat de gebruiker onbekend is, is de gebruiker waarschijnlijk niet aanwezig in de database die de Microsoft MX server gebruikt. Mogelijk is er iets mis gegaan met de registratie, of is er een restore gedaan waarbij de gebruiker gedeeltelijk aanwezig is. Of heeft de gebruiker niet de benodigde rechten/permissies. Zie ook:
https://support.exclaimer...s-rejected-Access-denied-

De gebruiker is via het reguliere proces aangemaakt (portal.azure.com) zoals alle andere gebruikers ook zijn aangemaakt. De gebruiker is niet gerestored.

mrmrmr schreef op woensdag 3 mei 2023 @ 17:37:
Generieke troubleshooting (selfservice):
Je kan een testgebruiker aanmaken en kijken of die dezelfde problemen heeft. Zo weet je of het een structureel probleem is. Als die testgebruiker geen probleem heeft, dan zou je kunnen overwegen de bestaande berichten van de gebruiker te exporteren, de gebruiker te verwijderen, en opnieuw aan te maken. Dit niet al te snel achter elkaar. Daarna kun je de geexporteerde berichten weer importeren.

Als dat niet wenselijk is, zou ik verder zoeken op internet of contact opnemen met Microsoft.

Een testgebruiker kan ik inderdaad nog aanmaken, aangezien ik nu geen setting kan bedenken die niet goed zou staan hoopte ik in eerste instantie in de goede richting geadviseerd te kunnen worden en een migratie te voorkomen.

akimosan schreef op woensdag 3 mei 2023 @ 20:02:
Ik neig toch naar de meest logische optie, dat er een stom klein typfoutje is geslopen bij het aanmaken van het SMTP adres van de gebruiker, op wat voor manier dan ook.

Dit is echt niet het geval. Dan zou deze door de gebruiker zelf verkeerd moeten worden ingetypt, en door mij en anderen vanaf vier verschillende unieke maildomeinen.

akimosan schreef op woensdag 3 mei 2023 @ 20:02:
Controleer en vervang voor de zekerheid het SMTP adres nogmaals via de relevante admin console.
Wacht even op eventuele replicatie
Laat gebruiker een testmail versturen naar een test email adres buiten de organisatie domein naam.
Stuur een reply vanaf dat testadres.
Komt reply aan? Mooi, opgelost
Komt reply niet aan? Analyseer headers van bericht zoals aangekomen op het testadres (mxtoolbox.com kan hierbij helpen)

Reply komt niet aan. Ik kan de headers analyseren, maar waarop analyseer ik is jouw advies?

Cergorach schreef op woensdag 3 mei 2023 @ 21:22:
Heeft de gebruiker al eens aangemeld op de O365 webmail

Ja.

Cergorach schreef op woensdag 3 mei 2023 @ 21:22:
Kan het zijn dat jullie een user provisioning systeem hebben? Het gebeurt wel eens dat de naam niet goed is opgegeven,

Nee, is goed aangemaakt. Interne mails komen ook aan.

Cergorach schreef op woensdag 3 mei 2023 @ 21:22:
De kans is gewoon groot dat het inderdaad een typfoutje is, maar voordat je in die hoek gaat kijken, ga eerst zelf testen. Pak een niet-Microsoft email dienst (zoals Google Mail) en email naar dat email adres en kijk of het dan wel netjes binnenkomt (volg de mailflow aan de Exchange Online kant). Als dit niet goed gaat, check eens je MX records.

Mails vanuit outlook.com, andere 0365-tenants, én Gmail komen niet aan. (Gmail melding "550 5.4.1 recipient address rejected: access denied.) De mail verzonden vanuit Gmail is niet terug te vinden in de mailflow aan EOL-kant.

Cergorach schreef op woensdag 3 mei 2023 @ 21:22:
Als dat ook niet werkt, wellicht even contact zoeken met de beheerder van hun email server/domein, dan kan je mogelijk mail flows naast elkaar leggen om te vergelijken.

De beheerder van welk domein bedoel je? Ik beheer het domein waar de probleemgebruiker zich bevindt.

-------------------------------------------
Ik vind het nog steeds vreemd dat hoewel de mail een NDR oplevert aan de kant van de verzender, deze NDR niet wordt vastgelegd in EOL (Reports > Mail flow > Non-delivery report)..

[ Voor 49% gewijzigd door Eagle Creek op 04-05-2023 10:25 ]

[TheHamQuestion]

Cergorach schreef op woensdag 3 mei 2023 @ 21:22:
Heeft de gebruiker al eens aangemeld op de O365 webmail, ik heb vaker gezien dat als je dat niet deed bij een nieuw account de mailbox gewoon nog niet provisioned was en de mailserver er ook niets naartoe kan sturen. Gezien je zegt dat de gebruiker wel kan versturen zou het zo kunnen zijn dat dit is gebeurd nadat de eerste mailtjes zijn gefaald, je kan dat checken in de mailflow van wanneer de gebruiker de eerste mail zelf heeft gestuurd. En vergelijk dat met of dat emailtje voor of na die datum is gestuurd. Vaak hebben (grote) organisaties dan weer een beveiliging dat ze niet twee keer een email sturen naar hetzelfde adres.

Voorheen was het probleem dat de tijd niet ingesteld was, waardoor de mailbox nog niet was aangemaakt. Dit probleem zie ik heel soms nog voorkomen

[Cergorach]

Eagle Creek schreef op donderdag 4 mei 2023 @ 10:05:
De beheerder van welk domein bedoel je? Ik beheer het domein waar de probleemgebruiker zich bevindt.

Als in de vorige troubleshooting steps het issue was beperkt tot een enkel versturend domein wat issues had met het email adres van jou gebruiker. Dit is dus breder en dan is dat natuurlijk nodig, aangezien het issue duidelijk aan jou kant ligt.

Heb je het stukje "Run email delivery troubleshooter" hier al gedraaid:
https://learn.microsoft.c...ery/email-delivery-issues
Je kan ook "Support and Recovery Assistant" draaien, het zal geen Outlook issue zijn, maar het checkt ook op account issues.

Check je MX records met bv. https://mxtoolbox.com

Test je MX records
https://testconnectivity.microsoft.com/tests/o365
https://learn.microsoft.c...-admin-how-can-i-fix-this

Heb je toevallig een hybride setup met Exchange servers on-premises?
Dan zou je wel eens dit soort shenanigans kunnen hebben:
https://techlabs.blog/cat...xchange-office-365-hybrid

Ik zou ook alvast een ticket bij MS inschieten waarin je al je troubleshooting stappen documenteert, het kan soms wel eens even duren... Als je het ondertussen zelf al heb opgelost, prima, zo niet dan staat er alvast wat in de queue bij MS.

[Dr Pro]

Al geprobeerd wat een secondary smtp adres doet op de user?

[MarchelHoek]

Inderdaad wat @Dr Pro aanhaalt, een alias toevoegen en daar naar toe sturen als test

Als dit ook niet werkt een support ticket inschieten bij Microsoft.
Meerdere keren al gedaan en de support is, in mijn gevallen, snel en goed (deskundig)

[Eagle Creek]

Cergorach schreef op donderdag 4 mei 2023 @ 10:46:
[...]

Als in de vorige troubleshooting steps het issue was beperkt tot een enkel versturend domein wat issues had met het email adres van jou gebruiker. Dit is dus breder en dan is dat natuurlijk nodig, aangezien het issue duidelijk aan jou kant ligt.

Correct, maar die conclusie had ik eerder al getrokken (zie OP).

Cergorach schreef op donderdag 4 mei 2023 @ 10:46:
[...]
Heb je het stukje "Run email delivery troubleshooter" hier al gedraaid:
https://learn.microsoft.c...ery/email-delivery-issues
Je kan ook "Support and Recovery Assistant" draaien, het zal geen Outlook issue zijn, maar het checkt ook op account issues.

Nee ik heb hier nog niet gekeken.

Cergorach schreef op donderdag 4 mei 2023 @ 10:46:
[...]
Check je MX records met bv. https://mxtoolbox.com

Test je MX records
https://testconnectivity.microsoft.com/tests/o365
https://learn.microsoft.c...-admin-how-can-i-fix-this

Maar waar moet ik op checken? Ook omdat het voor alle andere gebruikers wel goed werkt en de MX records v.z.i.w. het hele domein gelden.

[quote]Cergorach schreef op donderdag 4 mei 2023 @ 10:46:
[...]
Heb je toevallig een hybride setup met Exchange servers on-premises?
Nee, zoals vermeld in OP.

Dr Pro schreef op donderdag 4 mei 2023 @ 10:51:
Al geprobeerd wat een secondary smtp adres doet op de user?

Heb ik vandaag toegevoegd, ga ik mee testen. Primaire SMTP is niet te verwijderen omdat dit gekoppeld zou zijn ("Proxy address "<email>" is used as a WindowsLiveId."), aldus de melding.

MarchelHoek schreef op donderdag 4 mei 2023 @ 10:59:
Inderdaad wat @Dr Pro aanhaalt, een alias toevoegen en daar naar toe sturen als test

Als dit ook niet werkt een support ticket inschieten bij Microsoft.
Meerdere keren al gedaan en de support is, in mijn gevallen, snel en goed (deskundig)

Ticket ga aanmaken, dank voor advies. Ik hoopte eigenlijk op een simpeler oplossing met hulp van hier.

[Psycho_Mantis]

Eagle Creek schreef op donderdag 4 mei 2023 @ 11:19:


Heb ik vandaag toegevoegd, ga ik mee testen. Primaire SMTP is niet te verwijderen omdat dit gekoppeld zou zijn ("Proxy address "<email>" is used as a WindowsLiveId."), aldus de melding.

Zo te horen is er dus een microsoft account gemaakt met hetzelfde e-mail adres. hier zit je conflict waarschijnlijk.
Volgens mij moet je die user verwijderen of loskoppelen van het microsoft account.

Ook wel eens ellende mee gehad, is wel wat uitzoek werk.

Overigens zou je de primaire niet weg hoeven te halen om een secundaire smtp toe te voegen zoals er aangegeven wordt.

[Eagle Creek]

Psycho_Mantis schreef op donderdag 4 mei 2023 @ 11:44:
[...]


Zo te horen is er dus een microsoft account gemaakt met hetzelfde e-mail adres. hier zit je conflict waarschijnlijk.

Dat is niet het geval. Daarnaast hebben alle AAD users deze property, dus het is een (verwarrende) naamgeving die losstaat van een daadwerkelijk MS-account.

Bedankt voor het meedenken.

(
Set-Mailbox <Identity> -WindowsLiveID <new Windows Live ID>
UserPrincipalName, WindowsLiveID, MicrosoftOnlineServicesID
)

[ Voor 14% gewijzigd door Eagle Creek op 04-05-2023 13:04 ]

[akimosan]

Ik bedoelde dus niet dat degene die email verstuurt naar de ontvanger bij wie het niet werkt, een typ fout maakt, maar dat de persoon die de mailbox heeft aangemaakt wellicht een fout heeft gemaakt, met name in dat wat voor de apestaart staat.

Dus je denkt dat je voor Piet Piraat van bedrijf.nl het adres [e-mail] hebt ingesteld, maar per ongeluk heb je [e-mail] ingesteld, ik noem maar een dwarsweg. Als je dan van buiten mail stuurt naar [e-mail] gaat die fout op treden.

Daarom stelde ik voor het SMTP adres nog eens in te stellen of de headers van een bericht wat Piet heeft verstuurd te analyseren en kijken wat er als FROM en REPLY-TO adres weergegeven wordt.

Ook dien je bij mailflow message trace log te bekijken op alle mail die (zeker van buiten) ontvangen is voor [e-mail] , als daar het bericht niet gevonden wordt dan bereikt het jouw mailomgeving niet eens en wordt het voor die tijd al gedropt.

Naast Exchange Admin Center & message trace kun je ook op security.microsoft.com Email & Collaboration\Explorer gebruiken, daar kun je nog gerichter en langer terugzoeken op berichten

[ralpje]

akimosan schreef op donderdag 4 mei 2023 @ 22:35:

Ook dien je bij mailflow message trace log te bekijken op alle mail die (zeker van buiten) ontvangen is voor [e-mail] , als daar het bericht niet gevonden wordt dan bereikt het jouw mailomgeving niet eens en wordt het voor die tijd al gedropt.

Aanvullend: als de oorzaak inderdaad in een typo in het adres ligt (p..piraait in plaats van p.piraat) dan ga je de mail dus ook niet terugvinden in de logs van p.piraat, aangezien die mail dus niet aan dat adres gericht is.

[Anoniem: 80910]

Heeft de mailbox wel opslag?

[HKLM_]

Doe vanuit het security center (kopje e-mail) eens een message trace op de user zijn mailbox als je een mail hebt gestuurd vanaf een extern mail adres die niet aankomt.

Run ook eens de Inkomende SMTP-e-mail Analysetool vanuit https://testconnectivity....m/tests/InboundSMTP/input

[ Voor 54% gewijzigd door HKLM_ op 05-05-2023 14:57 ]

[Oid]

Poeh lastig, volgens mij heb je zo een beetje alles wel gedaan en goed in de gaten wat je aan het doen bent.

Kan het zijn dat jullie onderscheid maken (bijv. Dmv een groep) voor mail adressen die intern alleen te mailen zijn en extern ook te mailen zijn? Dit zou dan ergens in de connectors ingesteld zijn.

Exchange Online Transport Rule Kan je eens kijken

[Eagle Creek]

Allen,

Bedankt voor het meedenken. Ik moet de situatie gok ik wijten aan een bug bij Microsoft. Veel bronnen nog nagezocht te hebben lijkt het probleem af en toe random op te treden en zitten structurele oplossingen allemaal op hoge niveau, waarbij de situatie in die gevallen niet bij één gebruiker speelt.

Ik heb het primaire SMTP-adres gewijzigd naar een ander toegevoegd adres. Mail hierop kwam aan. Hierop het primaire SMTP-adres teruggezet en de aliassen verwijderd.

De gebruiker ontvangen nu mail van buitenaf zonder problemen. Hoewel alles dus op volledige standaardwijze is verlopen tijdens aanmaak, en zowel de diverse GUI's als PowerShell de juiste SMTP-waarde hebben getoond is er ergens een bitje onderuit gegleden waardoor het systeem ervan overtuigd bleef dat het adres niet zou bestaan - maar alleen als de buitenwereld dit vroeg.

Het probleem is dus opgelost.