Configuratie Exchange als onderdeel van Office 365

[wheel]

Ik overweeg over te stappen naar Office 365 en daarbij een migratie van een hosted Exchange-account (versie 2010) naar Exchange Online (als onderdeel van Office 365 Business Premium).

Mijn vraag
Hoe configureer ik Office 365/Exchange Online voor gebruik zodanig dat ik POP-accounts en Exchange-accounts kan combineren?

Huidige situatie
Binnen mijn domein worden op dit moment POP-boxen en (hosted) Exchange-accounts door elkaar gebruikt. Om die reden heeft domein.net MX-record(s) naar server A voor de POP-boxen en heeft exchange.domein.net MX-record(s) naar server B voor de Exchange-accounts. Met een forwarder wordt mail van [e-mail] doorgestuurd naar [e-mail]. Met een CNAME-record voor autodiscover en 2 MX-records (en een include in het SPF-record) werkt dit technisch gezien prima. Ik heb dus géén MX-records op domein.net die verwijzen naar de Exchange-server.

Gewenste situatie
Ik was hetzelfde van plan in de toekomstige situatie, maar loop vast hoe Office 365 te configureren. Het lijkt erop dat ik een MX-record op domein.net moet toevoegen - en die moet ook de laagste waarde (dus hoogste prioriteit) hebben.

Wat ik al gevonden of geprobeerd heb

• Toevoegen van domein.net. Hiervoor heb ik DNS-records toegevoegd: een TXT-record voor validatie eigenaarschap domeinnaam, een extra include in het SPF-record, het MX-record met de laagste prioriteit naar O365 verwezen (en ongedaan gemaakt vanwege verstoring) en een CNAME-record voor autodiscover.
• Gebruiker [e-mail] aangemaakt. Mailen naar binnen domein.net levert een bounce op. Mailen naar Gmail levert geen bounce, maar ook geen ontvangen mail.
• Toevoegen van office365.domein.net. Hiervoor heb ik DNS-records toegevoegd: een extra include in het SPF-record, het (enige) MX-record naar O365 verwezen en een CNAME-record voor autodiscover.
• Gebruiker [e-mail] aangemaakt. Mailen naar binnen office365.domein.net lukt, mailen naar Gmail levert geen bounce, maar ook geen ontvangen mail.
• De configuratie van elke andere FQDN werkt vlekkeloos - zonder noodzaak subdomein.

Obstakels

• Als ik daar domein.net toevoeg, moet ik een MX-record naar O365 met de hoogste prio toevoegen. Dat zorgt ervoor dat de POP-boxen niet meer werken. Dit is juist waarom ik Exchange altijd via een subdomein liet lopen.
• Als ik office365.domein.net toevoeg, zie ik niet hoe ik mailaccounts als [e-mail] kan aanmaken.

Geraadpleegd
https://docs.microsoft.co...ple-domains-to-office-365

Wie helpt mij even verder? Of is wat ik wil niet mogelijk?

[maratropa]

Dus je wilt die pop accounts niet hosten in office365 zelf? Want dan kun je toch gewoon POP toegang voor bepaalde accounts aanzetten en al dat DNS gedoe skippen?

[Piebas]

Waarom doe je het nu op deze manier?
Heb je nu 1 of meerdere domeinen voor de mail? (buiten het subdomein).
Het lijkt dat je het ingewikkelder maakt als nodig is.

[wheel]

Dank voor jullie reacties!

maratropa schreef op zaterdag 18 mei 2019 @ 15:45:
Dus je wilt die pop accounts niet hosten in office365 zelf? Want dan kun je toch gewoon POP toegang voor bepaalde accounts aanzetten en al dat DNS gedoe skippen?

Nee, niet perse, tenzij dat kan zonder licentie (en dus kosten). Zo te zien kan ik gebruikers aanmaken zonder licentie, maar kan ik dan wel POP-toegang krijgen? Ik vermoed van niet, aangezien ik POP3 alleen kan deactiveren als er wél een licentie gekoppeld is. Zou wel ideaal zijn

Piebas schreef op zaterdag 18 mei 2019 @ 15:52:
Waarom doe je het nu op deze manier?
Heb je nu 1 of meerdere domeinen voor de mail? (buiten het subdomein).
Het lijkt dat je het ingewikkelder maakt als nodig is.

Zowel de pop- als Exchange-accounts op domein.net. Het is ooit zo ingericht op aangeven van de leverancier van de Exchange-accounts; dit zou de manier zijn om POP- en Exchange-accounts op 1 domein te combineren - en het werkt met 3 records (totaal) en een forwarder (per Exchange-account). Hoe zou het eenvoudiger kunnen, volgens jou?

[ Voor 10% gewijzigd door wheel op 18-05-2019 17:23 ]

[Piebas]

Wat is nu precies de setup?
Wat doe je met een exchange account en wat met pop?

[wheel]

Piebas schreef op zaterdag 18 mei 2019 @ 19:41:
Wat is nu precies de setup?
Wat doe je met een exchange account en wat met pop?

Domeinnaam geregistreerd bij partij A. Hier DNS ingesteld: A-record verwijst naar partij B, een CNAME voor autodiscover, MX-records voor domein.net naar @ (bij B dus) en MX-records voor exchange.domein.net naar C.

Bij partij B draaien POP-accounts. Hier ook forwarder ingesteld voor [e-mail] naar [e-mail] (per Exchange-user een forwarder).

Bij partij C draaien hosted Exchange-accounts. Daar mail ik inkomend en uitgaand als [e-mail].

In de gewenste situatie wordt (alleen) partij C vervangen door O365.

[maratropa]

@wheel Maarrrr als je nu al betaald voor pop hosting? Dan kun je die accounts ook voor 4,xx per maand overzetten naar exchange met pop toegang? Of gaat het om erg veel accounts of te duah?

[Yeebo]

Als je binnen de 2GB storage blijft kan je ook uit met Exchange Online Kiosk (biedt ook POP3) en kost 1,40.

Anders, waarom niet alles laten binnenkomen en dan d.m.v. een mailrule de nodige mails laten relayen naar de POP mailserver.

[wheel]

maratropa schreef op zaterdag 18 mei 2019 @ 21:20:
@wheel Maarrrr als je nu al betaald voor pop hosting? Dan kun je die accounts ook voor 4,xx per maand overzetten naar exchange met pop toegang? Of gaat het om erg veel accounts of te duah?

De pop-boxen zijn inbegrepen bij bestaande webhosting. Als ik de POP-boxen ga omzetten naar Exchange leidt dat tot additionele kosten.

Het gaat om accounts van familieleden. Liefst verander ik zo weinig mogelijk tegen zo laag mogelijke kosten; het zijn geen veeleisende gebruikers.

daupie schreef op zaterdag 18 mei 2019 @ 21:24:
Als je binnen de 2GB storage blijft kan je ook uit met Exchange Online Kiosk (biedt ook POP3) en kost 1,40.

Anders, waarom niet alles laten binnenkomen en dan d.m.v. een mailrule de nodige mails laten relayen naar de POP mailserver.

Limiet van 2gb is geen probleem. Maar ik kan op office.com niets vinden over Online Kiosk of een licentie van 1,40. Bij derden wel iets te vinden, maar lijkt geen optie i.c.m. Outlook cliënt (alleen web).

Kun je je laatste suggestie verder toelichten?

[ Voor 59% gewijzigd door wheel op 18-05-2019 22:15 ]

[Piebas]

Je stuurt dus de mail vanuit de pop-box door naar exchange?
Om hoeveel mailboxen gaat het?
Wat is het doel van deze ingewikkelde setup?

[maratropa]

@wheel als ik bij office 365 admin op "purchase services" klik staat er bij "other plans" oa Exchange Online Kiosk tussen voor 1,69 met de functionaliteit die @daupie beschrijft.

[wheel]

Piebas schreef op zaterdag 18 mei 2019 @ 22:25:
Je stuurt dus de mail vanuit de pop-box door naar exchange?
Om hoeveel mailboxen gaat het?
Wat is het doel van deze ingewikkelde setup?

Nee. Er zijn POP-boxen voor bepaalde gebruikers en forwarders voor de Exchange-accounts voor andere gebruikers. POP en Exchange suiten elkaar hier uit. Die forwarders zorgen en m.i. voor dat de MX-records van het subdomein gebruikt worden en de afhandeling dus door Exchange gebeurt. Dat zou ik dus ook graag zo oplossen, maar dan in combinatie met O365 i.p.v. de huidige hosted Exchange-dienst. Of op een andere manier, als het makkelijker kan. Elke gebruiker kan dan zelf kiezen tussen POP zonder kosten of Exchange-account mét kosten.

Het verbaast me een beetje dat het zo exotisch lijkt. Zo vreemd is het m.i. niet om 2 soorten mailaccounts te combineren, toch? En complex? Het zijn 2 of 3 records en een forwarder in DirectAdmin - valt mee.

Is het op geen manier mogelijk om in O365 [e-mail] als alias aan de gebruiker [e-mail] toe te voegen én deze als primair adres toe te wijzen? Volgens mij zou dat moeten doen wat ik voor ogen heb, is het niet?

maratropa schreef op zaterdag 18 mei 2019 @ 22:32:
@wheel als ik bij office 365 admin op "purchase services" klik staat er bij "other plans" oa Exchange Online Kiosk tussen voor 1,69 met de functionaliteit die @daupie beschrijft.

Ik keek op de publieke website. Daar vond ik 'm niet. Ingelogd wel gevonden. Link naar meer informatie verwijst via https://aka.ms/office-365/1008 naar Office 365 F1 (met andere kosten). Is het qua specificaties hetzelfde?

[ Voor 81% gewijzigd door wheel op 19-05-2019 09:12 . Reden: Multi quote ]

[Yeebo]

wheel schreef op zondag 19 mei 2019 @ 07:40:
Ik keek op de publieke website. Daar vond ik 'm niet. Ingelogd wel gevonden. Link naar meer informatie verwijst via https://aka.ms/office-365/1008 naar Office 365 F1 (met andere kosten). Is het qua specificaties hetzelfde?

Ik kijk meestal op deze site:
https://www.dsaict.nl/mic...nge/exchange-online-kiosk

Is hij makkelijk te vinden. Outlook Access is mogelijk via POP3, niet via MAPI (synchronisatie). En wat betreft die 1,40, ik kom er alleen zakelijk mee in aanraking dus ik denk in ex BTW prijzen .

Je kan in Office 365 ook "Externe Mail Users" aanmaken. Je kan dan zeggen (zonder licentie) mail voor [e-mail] moet worden doorgestuurd naar [e-mail]. Zou je dan niet dat als alias kunnen toevoegen op je POP mailserver?
Daarnaast kan je via een mailrule Office 365 laten weten dat gespecificeerde users hun mail afgeleverd moeten krijgen op een bepaald IP-adres, dat van je POP mailserver.

[ Voor 33% gewijzigd door Yeebo op 19-05-2019 12:16 ]

[Piebas]

Dan zul je domein.net ook als domein moeten opvoeren in O365.
Je kunt de melding dat het mx-record niet juist is skippen en verder gaan met de installatie.
En dan zet je het domein.net als default domein en dan verstuur je de mail vanaf het juiste domein.
De forwards vanuit de pop-boxen kun je naar het subdomein doen of naar het onmicrosoft.com adres van de exchange boxen.

[wheel]

Dank weer voor jullie reacties en hulp!

daupie schreef op zondag 19 mei 2019 @ 12:13:
[...]


Ik kijk meestal op deze site:
https://www.dsaict.nl/mic...nge/exchange-online-kiosk

Is hij makkelijk te vinden. Outlook Access is mogelijk via POP3, niet via MAPI (synchronisatie). En wat betreft die 1,40, ik kom er alleen zakelijk mee in aanraking dus ik denk in ex BTW prijzen .

Je kan in Office 365 ook "Externe Mail Users" aanmaken. Je kan dan zeggen (zonder licentie) mail voor [e-mail] moet worden doorgestuurd naar [e-mail]. Zou je dan niet dat als alias kunnen toevoegen op je POP mailserver?
Daarnaast kan je via een mailrule Office 365 laten weten dat gespecificeerde users hun mail afgeleverd moeten krijgen op een bepaald IP-adres, dat van je POP mailserver.

Hier ga ik nog even verder naar kijken!

Piebas schreef op zondag 19 mei 2019 @ 14:33:
Dan zul je domein.net ook als domein moeten opvoeren in O365.
Je kunt de melding dat het mx-record niet juist is skippen en verder gaan met de installatie.
En dan zet je het domein.net als default domein en dan verstuur je de mail vanaf het juiste domein.
De forwards vanuit de pop-boxen kun je naar het subdomein doen of naar het onmicrosoft.com adres van de exchange boxen.

Klinkt hoopgevend! De waarschuwing over niet-correcte DNS negeren - als het toch zo eenvoudig is

Huidige situatie:

• Domeinnaam domein.net geeft een waarschuwing over ontbrekende MX-records. Dat klopt. De andere record zijn correct. Dit domein als default ingesteld.
• Domeinnaam office365.domein.net volledig 'op groen'.
• Heb het mailadres van het test-account aangepast naar [e-mail] en een forwarder aangemaakt van [e-mail] naar [e-mail]. Dat leidde tot een bounce. Kan het zijn dat er tijd overheen gaat voor de aanpassing van het mailadres volledig werkend/doorgevoerd is?
• Heb het mailadres van het test-account (terug) aangepast naar [e-mail]. Forwarder aangepast naar dat adres en dat werkt wel!

Mail van [e-mail] naar [e-mail] wordt afgeleverd. Mail van [e-mail] naar Gmail komt niet aan (en geen foutmelding). Zie ik daarvoor nog iets over 't hoofd?

[ Voor 23% gewijzigd door wheel op 19-05-2019 17:30 ]

[Piebas]

wheel schreef op zondag 19 mei 2019 @ 17:27:
Dank weer voor jullie reacties en hulp!


[...]

Hier ga ik nog even verder naar kijken!


[...]

Klinkt hoopgevend! De waarschuwing over niet-correcte DNS negeren - als het toch zo eenvoudig is

Huidige situatie:

• Domeinnaam domein.net geeft een waarschuwing over ontbrekende MX-records. Dat klopt. De andere record zijn correct. Dit domein als default ingesteld.
• Domeinnaam office365.domein.net volledig 'op groen'.
• Heb het mailadres van het test-account aangepast naar [e-mail] en een forwarder aangemaakt van [e-mail] naar [e-mail]. Dat leidde tot een bounce. Kan het zijn dat er tijd overheen gaat voor de aanpassing van het mailadres volledig werkend/doorgevoerd is?
• Heb het mailadres van het test-account (terug) aangepast naar [e-mail]. Forwarder aangepast naar dat adres en dat werkt wel!

Mail van [e-mail] naar [e-mail] wordt afgeleverd. Mail van [e-mail] naar Gmail komt niet aan (en geen foutmelding). Zie ik daarvoor nog iets over 't hoofd?

Post de inhoud van de bounce eens.

En wat gebeurd er als je een mail stuurt naar het onmicrosoft.com adres van de test user stuurt?

[wheel]

Piebas schreef op maandag 20 mei 2019 @ 10:06:
[...]

Post de inhoud van de bounce eens.

En wat gebeurd er als je een mail stuurt naar het onmicrosoft.com adres van de test user stuurt?

Het betrof een bounce van O365 dat het adres niet bestaat (Status code 550 5.1.10). Het lijkt erop dat het wijzigen van het mailadres niet direct effectief is. De bounce komt nu niet meer, namelij

Heb ondertussen meer documentatie gevonden: https://docs.microsoft.co...ow-for-multiple-locations en https://docs.microsoft.co...-connectors-to-route-mail.

Dat is precies hoe ik het voor ogen heb (waarbij 'on premise' in dit geval een andere hoster is). Lijkt toch wat complexer dan m 'n huidige situatie

Is dat wat jij bedoelde met 'laten relayen', @daupie?

Het valideren van een connector van Office 365 naar mijn 'on premise'-server loopt slaagt niet: 450 4.4.316 Connection refused. Is dit daadwerkelijk nodig of bedoel je met relayen iets anders? Is dit überhaupt een optie op een shared hosting server

[Yeebo]

@wheel Je kan in Office 365 aangeven dat bepaalde ontvangers (bijvoorbeeld een bepaalde groep) hun mail moet worden afgeleverd op een andere mailserver (in dit geval je POP mailserver).

Zie deze pagina voor een uitleg:
https://www.quora.com/How...-with-a-local-mail-server

[wheel]

daupie schreef op maandag 20 mei 2019 @ 21:12:
@wheel Je kan in Office 365 aangeven dat bepaalde ontvangers (bijvoorbeeld een bepaalde groep) hun mail moet worden afgeleverd op een andere mailserver (in dit geval je POP mailserver).

Zie deze pagina voor een uitleg:
https://www.quora.com/How...-with-a-local-mail-server

Die info lijkt (grotendeels) hetzelfde als https://docs.microsoft.co...ow-for-multiple-locations. Connectors dus. En daar loop ik op vast.

Begrijp ik je goed dat als de MX-records naar O365 verwijzen, O365 zo ingesteld kan worden dat - afhankelijk van de geadresseerde) bepaald kan worden waar mail afgeleverd wordt? Dus [e-mail] doorsturen naar (CNAME) mail.domein.net (met als value een IP-adres van hosting A) en een deel in een O365-mailbox laten terechtkomen? Dat zou prima zijn!

Als ik onder Rules/Regels (onder Mail flow/E-mailstroom) een regel probeer aan te maken op recipient, kan dat alleen voor accounts waar een O365-licentie aan gekoppeld is. En dát wil ik dan weer niet.

[ Voor 35% gewijzigd door wheel op 21-05-2019 10:20 ]

[Yeebo]

@wheel Je begrijpt me goed.

1. Je stelt een Connector in vanaf Office 365 naar Mailserver van uw organisatie.
2. Je kiest voor alleen gebruiken als transportregel actief is.
3. Geef het IP op van de andere mailserver.
4. Je maakt een transportregel, met daarin 'als de ontvanger is ..." dan "bericht omleiden naar connector". (Let erop dat je op meer opties moet drukken onderaan voordat deze optie verschijnt. Bij "de ontvanger is" kan je de e-mailadressen intikken in het onderste veld en dan op "namen controleren". De gebruikers hoeven dus niet te bestaan in Office 365.
5. Stel het domein in als Intern Relais (via geaccepteerde domeinen).
6. Klaar!

[ Voor 5% gewijzigd door Yeebo op 22-05-2019 10:49 . Reden: Stap vergeten ]

[wheel]

@daupie Bedankt voor dit heldere stappenplan. Stap 1 en stap 2 lukken, maar bij het valideren/stap 3 loop ik (nog steeds) vast. Het valideren kent twee stappen:

1) Verbinden met de mailserver middels het IP werkt. Ik heb in plaats van het IP-adres mail.domein.net ingevoerd (een CNAME naar @). In combinatie met een A-record op @ dat naar het juiste IP verwijst lijkt dat me handiger, omdat bij een IP-wijziging maar op 1 plek een wijziging nodig is. Het verbinden met de server slaagt ook op deze manier:

Resolve 'mail.domen.net' - Succeeded - OK - Resolved to 'xxx.xx.xxx.xx'
Connect to 'xxx.xx.xxx.xx' from Office 365 - Succeeded - OK - 220 Connection Successful
SMTP EHLO to 'mail.domein.net' - Succeeded - OK - 220
Smtp TLS - Succeeded - OK - Supports TLS and certificate is ok

2) Het versturen van een testmail faalt pertinent. Het MX-record verwees i.v.m. configuratie van het domein binnen O365 naar Office 365. (en dus niet naar de server waar de POP-box op draait). Ook met een MX-record (hoogste prio, laagste waarde) naar de server met de POP-boxen faalt deze stap.

[e-mail] - Failed - 550 5.1.10 RESOLVER.ADR.RecipientNotFound; Recipient [e-mail] not found by SMTP address lookup

De opgevoerde POP-box ontvangt wel gewoon mails vanaf extern (en er is ook nog een catch all actief).

De uitgebreide log:

Timestamp:22/05/2019 07:54:48
EventId:RECEIVE
Source:SMTP
MessageSubject:Test email for connector validation
MessageId:<[e-mail]>
Recipients:[e-mail]
RecipientCount:1
RecipientStatus:
SourceContext:08D6DE6F5958ABC6;2019-05-22T07:54:48.452Z;0
Sender:[e-mail]
EventData:InboundTlsDetails:TLS=SP_PROT_TLS1_2_SERVER TLSCipher=CALG_AES_256 TLSKeyLength=256 TLSKeyExAlg=CALG_ECDH_EPHEM, MimeParts:Att/Emb/MPt:0/0/1, MessageValue:MediumHigh, Replication:VE1PR09MB3117, FirstForestHop:AM6PR09MB3106.eurprd09.prod.outlook.com, DeliveryPriority:Normal, OriginalFromAddress:<>, AccountForest:EURPR09A003.PROD.OUTLOOK.COM


Timestamp:22/05/2019 07:54:48
EventId:RECIPIENTINFO
Source:RESOLVER
MessageSubject:Test email for connector validation
MessageId:<[e-mail]>
Recipients:[e-mail]
RecipientCount:1
RecipientStatus:NotFound.OneOff.Resolver.CreateRecipientItems.10
SourceContext:
Sender:[e-mail]
EventData:SenderVerdict:NotFound.OneOff.Sender.10, DeliveryPriority:Normal, OriginalFromAddress:<>, AccountForest:EURPR09A003.PROD.OUTLOOK.COM


Timestamp:22/05/2019 07:54:48
EventId:BADMAIL
Source:DSN
MessageSubject:Test email for connector validation
MessageId:<[e-mail]>
Recipients:[e-mail]
RecipientCount:1
RecipientStatus:
SourceContext:
Sender:[e-mail]
EventData:BadmailReason:Suppress NDR of a rejected or expired DSN, DeliveryPriority:Normal, OriginalFromAddress:<>, AccountForest:EURPR09A003.PROD.OUTLOOK.COM


Timestamp:22/05/2019 07:54:48
EventId:AGENTINFO
Source:AGENT
MessageSubject:Test email for connector validation
MessageId:<[e-mail]>
Recipients:[e-mail]
RecipientCount:1
RecipientStatus:
SourceContext:CatHandleFail
Sender:[e-mail]
EventData:AMA:EV|engine=A|v=0|sig=201905220629|name=|file=|hash=|phash=, AMA:EV|engine=S|v=0|sig=20190521.023|name=|file=|hash=|phash=, AMA:EV|engine=M|v=0|sig=1.293.2115.0|name=|file=|hash=|phash=, SDA:SDG|MID=6141803240859|MN=AM6PR09MB3106, DeliveryPriority:Normal, OriginalFromAddress:<>, AccountForest:EURPR09A003.PROD.OUTLOOK.COM


Timestamp:22/05/2019 07:54:48
EventId:FAIL
Source:ROUTING
MessageSubject:Test email for connector validation
MessageId:<[e-mail]>
Recipients:[e-mail]
RecipientCount:1
RecipientStatus:[{LED=550 5.1.10 RESOLVER.ADR.RecipientNotFound; Recipient [e-mail] not found by SMTP address lookup};{MSG=};{FQDN=};{IP=};{LRT=}]
SourceContext:
Sender:[e-mail]
EventData:ToEntity:Unknown, FromEntity:Unknown, DeliveryPriority:Normal, OriginalFromAddress:<>, AccountForest:EURPR09A003.PROD.OUTLOOK.COM

Op https://docs.microsoft.co...hg.150)#test-email-failed staan een aantal zaken om te checken bij een mislukte validatie:

Check the email address for any simple typographical mistakes in either the user ID name or the domain name. That is, check both sides of the at sign (@).

Het adres klopt; copy/paste van een testmail vanuit Gmail

If you are validating a connector from Office 365 to your partner, and you can be sure the address exists, use it.

N.v.t.

If you are validating a connector from Office 365 to your own email server (on-premises server), check that the email address you used is for an active mailbox hosted in your own email server. Make sure you can successfully send mail to this mailbox from a different location.

Check.

Ensure that the email address is within the scope of the connector you're validating. The domain part of the test email address should match the recipient domain you entered in the connector.

Wat wordt bedoeld met 'recipient domain'? Ik geef een server op (mail.domein.net) en een mailadres ([e-mail]). Als dat wordt bedoeld, dan matcht het.

Stap 4 lukt wel gewoon maar werkt nu (uiteraard) niet:

Your message couldn't be delivered to [e-mail] because the remote server is misconfigured. See technical details below for more information.

The response from the remote server was:
550 5.4.1 [[e-mail]]: Recipient address rejected: Access denied [HE1EUR01FT064.eop-EUR01.prod.protection.outlook.com]

[ Voor 25% gewijzigd door wheel op 22-05-2019 16:10 . Reden: ontbrekend woord ]

[Yeebo]

@wheel

Ik heb zelf een zakelijke mailbox met dan een paar test mailboxen bij een cheap webhost.
Ik heb mijn configuratie nagekeken. Heb je je domein als Intern Relais ingesteld (snel via de mobiel getyped )? Was ik vergeten te vermelden in mijn vorige post, zojuist aangepast.
Hieronder mijn configuratie:







Ik dacht ook nog aan de volgende optie mocht deze methode niet willen werken, dan moet je alleen even kijken of je shared webhost de verzending van een andere naam ondersteund. Voorkeur gaat dus naar de relayoptie.

[ Voor 79% gewijzigd door Yeebo op 22-05-2019 10:54 . Reden: Screenshots van config toegevoegd ]

[wheel]

@daupie Het domein stond (nog) op Gezaghebbend (tegenover 'Interne doorgifte' zoals in jouw screenshot). Die stap lijkt voorwaardelijk om het valideren te laten werken. Ik heb het aangepast en dat brengt me een stap verder! Het valideren lukt nu :-)

Huidige situatie

• Connector A van externe server naar Office 365
• Connector B van Office 365 naar externe server
• Connector C van Office 365 naar externe server (alleen wanneer er een transportregel is ingesteld)
• Een transportregel per POP-gebruiker die o.b.v. 'aan' doorstuurt naar Connector C (eventueel te combineren)

Connector A en B schijnen allebei nodig te zijn volgens https://docs.microsoft.co...anizations-email-servers:



Het werkt nog niet, maar ik her-test straks nog even, omdat wijzigingen niet altijd direct effectief lijken te worden.

[Yeebo]

@wheel Zoals wel meer dingen in Office 365, haal even een bak koffie en probeer het daarna opnieuw. Het duurt even op wijzigingen van kracht te laten worden.
De tweede connector is alleen nodig als je ook wilt versturen via Office 365. Als je het direct laat afleveren of via de SMTP server van je provider laat lopen is die stap dus niet nodig.

Validatie slaagt nu? Dan werkt de connector in ieder geval, en denk ik dat je naar je regel moet kijken. Krijg je een NDR terug of zie je iets anders waardoor het niet werkt?

[wheel]

@daupie, kun je nog eens met me meedenken?

daupie schreef op woensdag 22 mei 2019 @ 18:45:
@wheel
Validatie slaagt nu? Dan werkt de connector in ieder geval, en denk ik dat je naar je regel moet kijken. Krijg je een NDR terug of zie je iets anders waardoor het niet werkt?

Validatie slaagt, ja!

Ik heb de volgende scenario's en de testresultaten:

1. O365 <--> O365: werkt
2. POP <--> POP: werkt
3. Exchange <--> Gmail: werkt
4. Exchange --> POP: faalt
5. POP --> Exchange: faalt

M.b.t. 4: er volgt een bounce in O365-stijl:

Het bericht aan [e-mail] kan niet worden afgeleverd.
popuser is niet gevonden in domein.net.
Onbekend Aan-adres

Het lijkt of 'ie dus op de verkeerde server probeert af te leveren en dus niet de connector pakt, of niet?

M.b.t. 5: er volgt een melding voor het verzenden (waarna verzenden dus niet mogelijk is):

SMTP-fout (550): Ontvanger "[e-mail]" kan niet toegevoegd worden (No such recipient here).

Het lijkt er dus op of 'ie niet eens bij O365 terechtkomt, of niet?

[ Voor 101% gewijzigd door wheel op 25-05-2019 13:46 ]

[Yeebo]

@wheel
Wat betreft 4 ziet het ernaar uit dat hij de regel niet oppakt. Je kan dit volgen door een message trace uit te voeren in ECP, Dan weet je in ieder geval of je regel toegepast wordt.

Wat betreft 5 is dat hij het intern probeert te herrouteren, terwijl dat adres op de POP-server niet bestaat. Dit kan je afvangen door dit adres aan te maken een een forwarder in te stellen naar de .onmicrosoft.com alias.

Heb je het volgende al getest?
Random extern emailadres --> Exchange --> POP-server

[wheel]

daupie schreef op zondag 26 mei 2019 @ 00:20:
@wheel
Wat betreft 4 ziet het ernaar uit dat hij de regel niet oppakt. Je kan dit volgen door een message trace uit te voeren in ECP, Dan weet je in ieder geval of je regel toegepast wordt.

Bedoel je de message trace via https://protection.office.com/messagetrace? Die geeft 0 resultaten van [e-mail] naar [e-mail]:

Dear customer, Your request for Message trace report - 2019-05-26T06:47:18.739Z submitted on 5/26/2019 6:47:33 AM has been processed. No data was found that matched the search criteria you specified. Please submit a new request with changed criteria if you expect to obtain valid results.

De regel:

Mail aan X of Y
If the message...
Is sent to '[e-mail]' or '[e-mail]'

Do the following...
Route the message using the connector named 'Mail aan POP-users naar Provider B'.

Rule comments
-

Rule mode
Enforce

Additional properties
Sender address matches: Header

De regel staat uiteraard op 'on'

De connector:

Mail aan POP-users naar Provider B
Mail flow scenario
From: Office 365
To: Your organization‎'s email server

Description
None

Status
On

Validation
Validate this connector
Last validation result: Successful
Last validation time: 25/05/2019 11:27

When to use the connector
Use only when I have a transport rule set up that redirects messages to this connector.

Routing method
Route email messages through these smart hosts: mail.domein.net

Security restrictions
Always use Transport Layer Security ‎(TLS)‎ and connect only if the recipient�s email server certificate is issued by a trusted certificate authority ‎(CA)‎.

Ik zie hier niets aan waarom deze niet zou werken

Wat betreft 5 is dat hij het intern probeert te herrouteren, terwijl dat adres op de POP-server niet bestaat. Dit kan je afvangen door dit adres aan te maken een een forwarder in te stellen naar de .onmicrosoft.com alias.

Natuurlijk . Dat werkt inderdaad/uiteraard

Heb je het volgende al getest?
Random extern emailadres --> Exchange --> POP-server

[ Voor 7% gewijzigd door wheel op 26-05-2019 09:14 ]

[Yeebo]

wheel schreef op zondag 26 mei 2019 @ 09:13:
[...]

Bedoel je de message trace via https://protection.office.com/messagetrace? Die geeft 0 resultaten van [e-mail] naar [e-mail]:

Je zou daar alle mails moeten zien, ook diegene waar een NDR voor is verstuurd. Wat als je die in ECP gebruikt (hij geeft daar een melding dat het een oude versie is, maar hij werkt nog best) en daar filtert op de afgelopen zeven dagen? Daar zou hij zeker tussen moeten staan.

[wheel]

daupie schreef op zondag 26 mei 2019 @ 14:16:
[...]


Je zou daar alle mails moeten zien, ook diegene waar een NDR voor is verstuurd. Wat als je die in ECP gebruikt (hij geeft daar een melding dat het een oude versie is, maar hij werkt nog best) en daar filtert op de afgelopen zeven dagen? Daar zou hij zeker tussen moeten staan.

Mh, op basis van de melding over de nieuwe versie had ik de oude overgeslagen. Zie net dat ik daar (uit automatisme) niet m'n fictieve domein.net ingevoerd heb, maar m'n echte domein.net - vandaar geen resultaten. Zie nu (in de oude en nieuwe interface) dus wél gewoon resultaat.

Mijn falende testmail staat er 4 keer in: eerst 3 keer met status 'Delivered' (niet bij de ontvanger aangekomen), de meest recente met status 'Failed' (gevolgd door een NDR met status 'Delivered' die inderdaad als enige daadwerkelijk afgeleverd wordt bij de verzender).

Sender: [e-mail]
Recipient: [e-mail]

Status van de 3 meldingen:

Connector name: Mail aan POP-users naar Provider B
External address: [e-mail]
Destination IP: 104.47.1.36
Destination smart host: 12play-nl.mail.protection.outlook.com
Mail flow rule: Mail aan user X of Y

Hij lijkt op basis van de ontvanger wél de (juiste) regel te pakken, maar ik heb m'n twijfels over de vetgedrukte regels; hoort hier niet mail.domein.net te staan met het bijbehorende IP-adres? Dat is immers de smart host die ik ingesteld en gevalideerd heb...

De details:

MESSAGE EVENTS
DATE (UTC) EVENT DETAIL
26/05/2019 12:41:41 Receive Message received by: DB8PR09MB3804 using TLS1.2 with AES256
26/05/2019 12:41:41 Submit The message was submitted.
26/05/2019 12:41:43 Transport rule RouteMessageUsingConnector. Transport rule: ‎'Mail aan user X of Y', ID: ‎(‎'D003812C-C974-41E7-8B3A-BA789009AD33‎')‎, DLP policy: ‎'‎', ID: ‎(00000000-0000-0000-0000-000000000000)‎.
26/05/2019 12:41:44 Send external Message sent to domein-net.mail.protection.outlook.com at 104.47.1.36 using TLS1.2 with AES256
26/05/2019 12:41:43 Spam Diagnostics

Vetgedrukte had ik ook mail.domein.net verwacht

Status van de 4e melding:

Office 365 received the message that you specified, but couldn't deliver it to the recipient ([e-mail]) due to the following error:

Error: 554 5.4.14 Hop count exceeded - possible mail loop ATTR34 [VE1EUR01FT035.eop-EUR01.prod.protection.outlook.com]

A non-delivery report (NDR) message was sent to [e-mail]. The NDR might provide more details about why the email message wasn't delivered and how to fix the issue.

Zou die overschrijding van het aantal hops komen doordat de verkeerde smart host gebruikt wordt? Ik snap dat 'ie [e-mail] uiteindelijk niet kan vinden als 'ie op de verkeerder host probeert af te leveren...


UPDATE

Ik heb mail.domein.net als host in de connector vervangen door het IP-adres en lijken testmails wél aan te komen. Ik wacht even af en zal alle combinaties later nog even her-testen. Als dat werkt, kan ik deze configuratie volgens mij eenvoudig aanpassen naar m'n echte domein.net.

@daupie Super bedankt voor je uitgebreide en behulpzame reacties. Andere reageerders ook bedankt voor het meedenken!

Eerder schreef ik al dat zowel het CNAME-record als het IP-adres allebei valideerden, dus het verbaast me ergens wel dat het met andere instellingen maar hetzelfde validatie-resultaat nu wel werkt...

Sender: [e-mail]
Recipient: [e-mail]

Office 365 used one of your organization's connectors to send the message to an external address. An admin in your organization set up a mail flow rule to route messages through that connector. Here are the details:

Connector name: Mail aan POP-users naar Provider B
External address: [e-mail]
Destination IP: xxx.xxx.xxx.xxx
Destination smart host: xxx.xxx.xxx.xxx
Mail flow rule: Mail aan user X of Y

Het liefst gebruik ik mail.domein.net in de configuratie van O365 omdat ik zo maar op 1 plaats wijzigingen hoef aan te brengen bij een DNS-change (en zo de kans op verstoring kan minimaliseren). Dus mocht iemand een idee hebben waarom mail.domein.net als smarthost niet blijkt te werken, houd ik me aanbevolen...

Ik had de volgende DNS-records:
@ A xxx.xxx.xxx.xxx
mail CNAME @

In mijn beleving verwees mail.domein.net daarmee naar hetzelfde xxx.xxx.xxx.xxx als opgenomen in het A-record

[ Voor 22% gewijzigd door wheel op 27-05-2019 09:28 ]

[Yeebo]

@wheel

Het lijkt erop (aan je voorbeelden te zien) dat die domeinnaam gericht stond naar Office 365 (doorgestuurd naar mail.protection.outlook.com) en uiteindelijk een aantal hops error (wat logisch is omdat je hem constant rondstuurt).

Kreeg je bij de validatie een test mail binnen? Dan weet je genoeg. In principe stuurt die validatie een mail en kijkt hij niet of deze ontvangen wordt, hij zag dus geaccepteerd door Office 365 en zegt validatie voltooid.

De DNS zoals je aangeeft is een juiste configuratie. Ik neem aan dat je ook het juiste IP-adres terugkrijgt als je een nslookup op mail.domein.xyz doet? (Om DNS-errors uit te sluiten)

[wheel]

daupie schreef op maandag 27 mei 2019 @ 11:23:
@wheel
Het lijkt erop (aan je voorbeelden te zien) dat die domeinnaam gericht stond naar Office 365 (doorgestuurd naar mail.protection.outlook.com) en uiteindelijk een aantal hops error (wat logisch is omdat je hem constant rondstuurt).

Ja, zo kwam het mij dus ook over, maar zo stond het m.i. dus niet ingesteld

Kreeg je bij de validatie een test mail binnen? Dan weet je genoeg. In principe stuurt die validatie een mail en kijkt hij niet of deze ontvangen wordt, hij zag dus geaccepteerd door Office 365 en zegt validatie voltooid.

Nee, die heb ik niet ontvangen. Na aanpassing van mail.domein.net naar het IP-adres wél. Die mails zie ik nu dus ook 3x op Delivered en de 4e keer op Failed in de email trace. Die (terugkoppeling op de) validatie is dus niet betrouwbaar op deze manier.

De DNS zoals je aangeeft is een juiste configuratie. Ik neem aan dat je ook het juiste IP-adres terugkrijgt als je een nslookup op mail.domein.xyz doet? (Om DNS-errors uit te sluiten)

Ja, volgens mij wel. Het resultaat voor mail.domein.net via https://ping.eu/nslookup:

mail.domein.net is an alias for domein.net.
domein.net has address xxx.xxx.xxx.xxx
domein.net mail is handled by 0 domein-net.mail.protection.outlook.com.

Dit is toch correct? Het IP op de x'jes is hetzelfde IP als wat ik nu in de connector heb ingevoerd.

[ Voor 7% gewijzigd door wheel op 27-05-2019 12:44 ]

[Yeebo]

wheel schreef op maandag 27 mei 2019 @ 12:41:
[...]
Dit is toch correct? Het IP op de x'jes is hetzelfde IP als wat ik nu in de connector heb ingevoerd.

Die DNS-configuratie klopt wel. Wat als je een nieuw record maakt bijv mailserver.domein.xyz en deze met een A/AAA-record direct doorverwijst? Deze daarna in de smarthostvalidatie zetten en kijken of de mail binnenkomt.

[wheel]

daupie schreef op maandag 27 mei 2019 @ 14:21:
[...]


Die DNS-configuratie klopt wel. Wat als je een nieuw record maakt bijv mailserver.domein.xyz en deze met een A/AAA-record direct doorverwijst? Deze daarna in de smarthostvalidatie zetten en kijken of de mail binnenkomt.

Een nieuw A-record aangemaakt (en getest) - het valideren werkt ook niet. Bij jou wel werkend met een FQDN? Ik heb de vraag bij MS Support neergelegd.

Voor nu houd ik het bij het IP-adres - komende dagen even alle scenario's doortesten

[Yeebo]

wheel schreef op maandag 27 mei 2019 @ 20:30:
[...]

Een nieuw A-record aangemaakt (en getest) - het valideren werkt ook niet. Bij jou wel werkend met een FQDN? Ik heb de vraag bij MS Support neergelegd.

Voor nu houd ik het bij het IP-adres - komende dagen even alle scenario's doortesten

Bij mij draait hij inderdaad op web.domein.xyz (web van webserver).
Je hebt geen IPv6-record ergens anders naar wijzen e.d.?