Beslutet: behåll brevlådan, byt MX
Att byta e-postsystem och att byta skydd är två olika projekt. Det första flyttar brevlådor, historik, kalendrar och kontona i telefonerna. Det andra rör bara vägen för inkommande e-post.
Den vägen styrs av en DNS-post: MX, som talar om för avsändande servrar var e-posten till er domän ska levereras. När den pekar ut gatewayen tar gatewayen emot, analyserar och lämnar sedan över meddelandet till brevlådeservern. Det gäller för:
- Microsoft 365 (Exchange Online);
- Google Workspace;
- Exchange installerat hos er eller hos en värdleverantör;
- alla andra e-postservrar som tar emot via SMTP;
- Klytic Mail, som bara är ett fall bland andra, inte en förutsättning.
Den här guiden behandlar fallet där man behåller brevlådan. Om ni också byter server beskriver guiderna migrera från Microsoft 365 och migrera från Google Workspace det projektet.
Vem ändrar vad
| Inställning | Var | Vem |
|---|
| Domänens MX-post | DNS-zonen, hos registraren eller DNS-leverantören | Den som sköter DNS, eller den leverantör som har fått uppdraget |
| Registrering av gatewayen i e-postsystemet | Administrationskonsolen i Microsoft 365, Google Workspace eller servern | E-postsystemets administratör |
| SPF, DKIM och DMARC | DNS-zonen | Den som sköter DNS, efter en inventering av servrarna som skickar för domänen |
| Domäner och leveransserver | Gatewayen | Gatewayens leverantör, som förbereder konfigurationen |
Principen i Microsoft 365
Microsofts dokumentation om filtrering via en tredjepartstjänst är tydlig: domänens MX ska peka ut tjänsten, som sedan levererar till Exchange Online. Microsoft rekommenderar en inkommande anslutning av typen ”partner”, som kan avvisa e-post som har kommit utan att passera tjänsten. Microsoft rekommenderar också att aktivera förbättrad filtrering för anslutningar, så att den egna analysen bedömer den verkliga avsändaren och inte gatewayens adress. Microsoft avråder från att helt enkelt kringgå sin filtrering för tredjepartstjänstens adresser.
Principen i Google Workspace
Google beskriver en ”inkommande e-postgateway”: MX pekar ut gatewayen, och administratören anger sedan dess IP-adresser i konsolen. Gmail använder dem för att hitta avsändarens verkliga adress i huvudena, något som SPF och Googles spambedömning är beroende av. Man kan också avvisa e-post som inte kommer från gatewayen. Google anger att avsändarens DMARC-policy inte tillämpas på e-post som tas emot via en registrerad gateway: den kontrollen ligger då hos gatewayen.
Den här guiden återger inte konsolernas skärmbilder, som ändras. Följ den officiella sida som anges längst ner när inställningen görs.
Flera servrar bakom en enda gateway
Ett vanligt fall i en koncern: moderbolaget på Microsoft 365, ett dotterbolag på Google Workspace, ett tredje på en äldre server. En enda gateway kan ligga framför alla tre.
Principen är routning per domän. Varje domäns MX pekar mot gatewayen. För varje domän vet gatewayen vilken server e-posten ska lämnas till efter analysen. Analysen är gemensam, destinationen varierar.
Fördel: samma filtreringspolicy, eller olika inställningar per domän, och alla beslut kan läsas på ett ställe. Att förbereda: en domän vars brevlådor är fördelade på två servrar kräver att man vet, adress för adress, vart e-posten ska levereras. Det fallet utreds före bytet.
Vad som ändras, och vad som inte ändras
Ändras inte: adresserna, brevlådorna, historiken, e-postprogrammet, webbmejlen, telefonerna. E-postsystemets inbyggda filter fortsätter att fungera. Behörigheter och intern delning är fortfarande plattformens.
Ändras:
- Den första servern som tar emot e-posten. Det är den som ser den ursprungliga anslutningen och kontrollerar avsändarens autentisering.
- Brevlådeservern ser inte längre avsändaren direkt, utan gatewayen. Därav registreringen som beskrivs ovan.
- Meddelandena får gatewayens beslutshuvuden: en administratör kan där läsa varför ett meddelande levererades eller lades åt sidan.
- Om gatewayen också vidarebefordrar utgående e-post måste domänens SPF-post godkänna den, och DKIM-signaturen måste publiceras för den. Vad dessa mekanismer innebär förklaras i SPF, DKIM och DMARC.
Den dag ni också byter brevlådeserver kan gatewayen ligga kvar: bara dess leveransserver ändras. Guiden migrera ett e-postsystem utan avbrott är fortfarande referensen för den dagen, även för SPF, DKIM och DMARC.
Införandet, i ordning
- Inventering: domäner, varje domäns brevlådeserver, applikationer som skickar e-post i domänens namn.
- Gatewayens leverantör förbereder gatewayen: godkända domäner, leveransserver, grundregler.
- Registrering av gatewayen i e-postsystemet (inkommande anslutning eller inkommande gateway), om plattformen har stöd för det.
- Sänk först MX-postens TTL, ändra sedan MX. Under DNS-cachens livstid levererar en del avsändare fortfarande direkt till brevlådeservern: det är normalt.
- Kontroll: ett meddelande som skickas från en extern adress ska komma fram med gatewayens beslutshuvuden.
- Bevaka karantänen de första dagarna, för att släppa falska positiva och justera reglerna.
Att backa är enkelt: återställ den gamla MX-posten. Det förbereds som vid en migrering, med en person som har rätt att fatta beslutet.
Vad gatewayen inte gör
Den ser den e-post som passerar genom den, och bara den. Den ser inte meddelanden mellan två brevlådor på samma plattform som aldrig lämnar plattformen, inte filer som delas i en molnlagring och inte användarnas inloggningar.
Den ersätter alltså inte de interna inställningarna i Microsoft 365 eller Google Workspace: behörigheter, tvåfaktorsautentisering, inloggningslarm, regler för automatisk vidarebefordran. Ett stulet konto är i första hand en fråga för e-postsystemet. Guiden spam, nätfiske, skadlig kod och komprometterat konto reder ut vad som är vad.
Slutligen kan en avsändare som känner till brevlådeserverns tekniska adress försöka leverera direkt till den, utan att gå via MX. Det är skälet till den låsning som Microsoft (partneranslutning) och Google (avvisning av e-post som inte kommer via gatewayen) erbjuder.
Vanliga frågor
Behöver användarna informeras?
Deras adresser ändras inte. Informera dem däremot om att de kan få karantänmeddelanden: se Karantän, falska positiva och rapporter.
Ska filtret i Microsoft 365 eller Google stängas av?
Nej. Microsoft rekommenderar att låta sin analys vara aktiv och ställa in den så att den ser den verkliga avsändaren, i stället för att kringgå den.
Hur lång tid tar bytet?
Själva MX-ändringen får effekt i takt med DNS-cachen. Förberedelserna beror på antalet domäner och servrar. För Klytic MTA, se nästa avsnitt.
Påverkar en gateway framför systemet leveransbarheten för våra utskick?
Bara om den också vidarebefordrar utgående e-post. I så fall måste SPF och DKIM ta hänsyn till den: se SPF, DKIM och DMARC.
Varför inte bara byta e-postsystem?
Det är ett annat beslut, med andra kriterier. Det behandlas i välja ett europeiskt e-postsystem för företag.
Var Klytic står
Klytic MTA placeras framför det e-postsystem ni har: Microsoft 365, Google Workspace, Exchange, Klytic Mail eller vilken annan server som helst. Den förutsätter ingen brevlåda hos Klytic.
- Driftstart: normalt 24 till 48 timmar. Klytic förbereder konfigurationen; ni ändrar er domäns MX-post, eller så gör Klytic det åt er. Registreringen av gatewayen i konsolen för Microsoft 365 eller Google Workspace görs av det e-postsystemets administratör, och förbereds tillsammans med Klytic vid driftstarten.
- Driftform: Klytics moln, dedikerad instans eller kundens servrar. För särskilda behov kan andra arkitekturer utformas tillsammans med Klytic, till exempel filtrering i molnet och ett relä installerat hos er, eller flera regioner.
- Paket: Essential och Advanced. Essential omfattar autentisering, antispam, antivirus, nätfiske, förväxlingsbara domäner, karantän, DKIM-signering av utgående e-post och återkallelse före utskick. Advanced lägger till ekonomiska bedrägerier, skydd vid klick, DMARC-konsolen och export av loggar till ett SIEM.
- Provperiod: 30 dagar gratis, utan att byta e-postsystem.
Klytic MTA hanterar inte behörigheter eller konton i ert nuvarande e-postsystem, och utlovar ingen likvärdighet med de säkerhetsverktyg som är inbyggda i Microsoft 365 eller Google Workspace: den läggs till framför dem.
Den här sidan beskriver en princip. Microsofts och Googles konsoler förändras: deras officiella dokumentation gäller för själva handgreppen.
Källor
Hämtade i oktober 2026.
- Microsoft Learn, ”Manage mail flow using a third-party cloud service with Exchange Online”: MX ska peka ut tredjepartstjänsten; inkommande anslutning av partnertyp; förbättrad filtrering för anslutningar i stället för att kringgå filtreringen. learn.microsoft.com
- Google Workspace-hjälpen, ”Set up an inbound mail gateway”: MX mot gatewayen, registrering av dess IP-adresser, möjlig avvisning av e-post som inte kommer via gatewayen; avsändarens DMARC-policy tillämpas inte av Gmail på e-post som tas emot via gatewayen. knowledge.workspace.google.com
- RFC 5321, SMTP: mellanliggande värdar anges i allmänhet av DNS-postens MX. rfc-editor.org
- Klytic, sidan Klytic MTA: moduler i paketen Essential och Advanced, tillägg, driftformer, driftstart via MX. klytic.com
