De beslissing: de mailbox houden, het MX-record wijzigen
Van e-mailomgeving veranderen en van bescherming veranderen zijn twee verschillende projecten. Het eerste verhuist de mailboxen, de geschiedenis, de agenda’s en de accounts op de telefoons. Het tweede raakt alleen de route van de inkomende post.
Die route zit in één DNS-record: het MX-record, dat verzendende servers vertelt waar ze de post van uw domein moeten afleveren. Wanneer het de gateway aanwijst, ontvangt die het bericht, analyseert het en draagt het daarna over aan de mailboxserver. Dat geldt voor:
- Microsoft 365 (Exchange Online);
- Google Workspace;
- Exchange, bij u geïnstalleerd of gehost;
- elke andere e-mailserver die via SMTP ontvangt;
- Klytic Mail, dat slechts een geval tussen de andere is, geen voorwaarde.
Deze gids behandelt het geval waarin u de mailbox houdt. Als u ook van server verandert, beschrijven de gidsen migreren van Microsoft 365 en migreren van Google Workspace dat project.
Wie wijzigt wat
| Instelling | Waar | Wie |
|---|
| MX-record van het domein | DNS-zone, bij de registrar of de DNS-host | De persoon die de DNS beheert, of de dienstverlener aan wie dat is gedelegeerd |
| Aanmelding van de gateway bij de e-mailomgeving | Beheerconsole van Microsoft 365, Google Workspace of de server | De beheerder van de e-mailomgeving |
| SPF, DKIM en DMARC | DNS-zone | De DNS-beheerder, na een inventaris van de servers die voor het domein verzenden |
| Domeinen en afleverserver | Gateway | De leverancier van de gateway, die de configuratie voorbereidt |
Het principe bij Microsoft 365
De documentatie van Microsoft over filtering door een externe dienst is duidelijk: het MX-record van het domein moet die dienst aanwijzen, die daarna aan Exchange Online aflevert. Microsoft raadt een inkomende connector van het type “partner” aan, die post kan weigeren die niet via de dienst is binnengekomen. Het raadt ook aan verbeterde filtering voor connectors te activeren, zodat zijn eigen analyse de echte afzender beoordeelt en niet het adres van de gateway. Het raadt af zijn filtering gewoon te omzeilen voor de adressen van de externe dienst.
Het principe bij Google Workspace
Google beschrijft een “gateway voor inkomende e-mail”: het MX-record wijst de gateway aan, daarna geeft de beheerder de IP-adressen ervan op in de console. Gmail gebruikt die om het echte adres van de afzender in de headers terug te vinden, waarvan SPF en zijn spambeoordeling afhangen. U kunt ook post weigeren die niet van de gateway komt. Google preciseert dat het het DMARC-beleid van de afzender niet toepast op post die via een opgegeven gateway is ontvangen: die controle komt dan bij de gateway te liggen.
Deze gids neemt de schermen van die consoles niet over, want ze veranderen. Volg op het moment van de instelling de officiële pagina die onderaan wordt vermeld.
Meerdere servers achter één gateway
Een vaak voorkomend geval in een groep: het moederbedrijf op Microsoft 365, een dochteronderneming op Google Workspace, een derde op een oudere server. Eén gateway kan vóór alle drie staan.
Het principe is routering per domein. Het MX-record van elk domein wijst naar de gateway. Per domein weet de gateway aan welke server ze de post na de analyse moet overdragen. De analyse is gemeenschappelijk, de bestemming verschilt.
Voordeel: eenzelfde filterbeleid, of verschillende instellingen per domein, en alle beslissingen op één plek te lezen. Voor te bereiden: bij een domein waarvan de mailboxen over twee servers zijn verdeeld, moet u per adres weten waar af te leveren. Dat geval bestudeert u vóór de omschakeling.
Wat verandert, en wat niet
Verandert niet: de adressen, de mailboxen, de geschiedenis, het e-mailprogramma, de webmail, de telefoons. De ingebouwde filter van de e-mailomgeving blijft werken. De rechten en de interne gedeelde items blijven die van het platform.
Verandert:
- De eerste server die de post ontvangt. Die ziet de oorspronkelijke verbinding en controleert de authenticatie van de afzender.
- De mailboxserver ziet de afzender niet meer rechtstreeks, maar de gateway. Vandaar de hierboven beschreven aanmelding.
- De berichten dragen de beslissingsheaders van de gateway: een beheerder kan er lezen waarom een bericht is afgeleverd of apart gezet.
- Als de gateway ook de uitgaande post doorgeeft, moet het SPF-record van het domein haar toestaan en moet de DKIM-handtekening voor haar worden gepubliceerd. De betekenis van deze mechanismen wordt uitgelegd in SPF, DKIM en DMARC.
Op de dag dat u ook van mailboxserver verandert, kan de gateway blijven staan: alleen haar afleverserver verandert. De gids e-mail migreren zonder onderbreking blijft voor die dag de referentie, ook voor SPF, DKIM en DMARC.
De ingebruikname, in volgorde
- Inventaris: domeinen, de mailboxserver van elk domein, toepassingen die post in naam van het domein verzenden.
- Voorbereiding van de gateway door de leverancier: aanvaarde domeinen, afleverserver, beginregels.
- Aanmelding van de gateway in de e-mailomgeving (inkomende connector of inkomende gateway), als het platform dat voorziet.
- Vooraf de TTL van het MX-record verlagen, daarna het MX-record wijzigen. Zolang de DNS-cache duurt, levert een deel van de afzenders nog rechtstreeks aan de mailboxserver af: dat is normaal.
- Controle: een bericht dat vanaf een extern adres wordt verzonden, moet aankomen met de beslissingsheaders van de gateway.
- De quarantaine de eerste dagen in de gaten houden, om valspositieven vrij te geven en de regels bij te stellen.
Teruggaan is eenvoudig: het oude MX-record terugzetten. U bereidt het voor zoals bij een migratie, met iemand die bevoegd is om erover te beslissen.
Wat de gateway niet doet
Ze ziet de post die door haar heen gaat, en alleen die. Ze ziet geen berichten die worden uitgewisseld tussen twee mailboxen van hetzelfde platform zonder dat platform te verlaten, geen bestanden die in online opslag worden gedeeld, en geen aanmeldingen van gebruikers.
Ze vervangt dus niet de interne instellingen van Microsoft 365 of Google Workspace: rechten, tweestapsverificatie, aanmeldingswaarschuwingen, regels voor automatisch doorsturen. Een gestolen account blijft in de eerste plaats een zaak van de e-mailomgeving. De gids spam, phishing, malware en gecompromitteerd account maakt het onderscheid.
Ten slotte kan een afzender die het technische adres van de mailboxserver kent, proberen er rechtstreeks aan af te leveren, buiten het MX-record om. Dat is de reden voor de vergrendeling die Microsoft (partnerconnector) en Google (weigering van post buiten de gateway) aanbieden.
Veelgestelde vragen
Moeten de gebruikers worden verwittigd?
Hun adressen veranderen niet. Laat hun wel weten dat ze quarantainemeldingen kunnen ontvangen: zie Quarantaine, valspositieven en meldingen.
Moet de filter van Microsoft 365 of Google worden uitgeschakeld?
Nee. Microsoft raadt aan zijn analyse actief te laten en ze zo in te stellen dat ze de echte afzender ziet, in plaats van ze te omzeilen.
Hoe lang duurt de omschakeling?
De wijziging van het MX-record zelf wordt van kracht op het ritme van de DNS-cache. De voorbereiding hangt af van het aantal domeinen en servers. Voor Klytic MTA, zie de volgende sectie.
Verandert een gateway ervoor de afleverbaarheid van onze verzendingen?
Alleen als ze ook de uitgaande post doorgeeft. In dat geval moeten SPF en DKIM daar rekening mee houden: zie SPF, DKIM en DMARC.
Waarom niet gewoon van e-mailomgeving veranderen?
Dat is een andere beslissing, met andere criteria. Ze wordt behandeld in een Europese zakelijke e-maildienst kiezen.
Waar Klytic staat
Klytic MTA staat vóór de e-mailomgeving die u hebt: Microsoft 365, Google Workspace, Exchange, Klytic Mail of elke andere server. Het veronderstelt geen Klytic-mailbox.
- Ingebruikname: doorgaans 24 tot 48 uur. Klytic bereidt de configuratie voor; u wijzigt het MX-record van uw domein, of Klytic doet het voor u. De aanmelding van de gateway in de console van Microsoft 365 of Google Workspace gebeurt door de beheerder van die e-mailomgeving, en wordt bij de ingebruikname met Klytic voorbereid.
- Implementatie: Klytic-cloud, dedicated instantie of servers van de klant. Voor bijzondere behoeften worden met Klytic andere architecturen uitgewerkt, bijvoorbeeld filtering in de cloud en een relay bij u geïnstalleerd, of meerdere regio’s.
- Formules: Essential en Advanced. Essential dekt authenticatie, antispam, antivirus, phishing, lookalike-domeinen, quarantaine, DKIM-ondertekening van verzendingen en terughalen vóór verzending. Advanced voegt financiële fraude, bescherming bij het klikken, de DMARC-console en de export van logbestanden naar een SIEM toe.
- Proefperiode: 30 dagen gratis, zonder van e-mailomgeving te veranderen.
Klytic MTA beheert de rechten en accounts van uw huidige e-mailomgeving niet, en belooft geen gelijkwaardigheid met de beveiligingstools die in Microsoft 365 of Google Workspace zijn ingebouwd: het komt ervoor.
Deze pagina beschrijft een principe. De consoles van Microsoft en Google evolueren: hun officiële documentatie is bepalend voor de handeling.
Bronnen
Geraadpleegd in oktober 2026.
- Microsoft Learn, “Manage mail flow using a third-party cloud service with Exchange Online”: het MX-record moet de externe dienst aanwijzen; inkomende connector van het type partner; verbeterde filtering voor connectors in plaats van het omzeilen van de filtering. learn.microsoft.com
- Google Workspace Help, “Set up an inbound mail gateway”: MX-record naar de gateway, opgave van de IP-adressen ervan, mogelijke weigering van post buiten de gateway; het DMARC-beleid van de afzender wordt door Gmail niet toegepast op post die via de gateway is ontvangen. knowledge.workspace.google.com
- RFC 5321, SMTP: tussenliggende hosts worden doorgaans aangewezen door het MX-record in de DNS. rfc-editor.org
- Klytic, pagina Klytic MTA: modules van de formules Essential en Advanced, opties, implementatievormen, ingebruikname via het MX-record. klytic.com
