Forside›Guider›E-mailsikkerhed

E-mailsikkerhed · Forstå

Beskyt det e-mailsystem, I allerede har

Ja, I kan styrke beskyttelsen af Microsoft 365, Google Workspace, Exchange eller en anden server uden at skifte e-mailsystem. Domænets MX peger på gatewayen, der analyserer posten og derefter leverer den til den nuværende server. Brugerne beholder deres postkasser; den, der administrerer DNS, og administratoren af e-mailsystemet skal hver foretage én indstilling.

Opdateret i oktober 20267 min. læsningOfficielle kilder angivet

Beslutningen: behold postkassen, skift MX

At skifte e-mailsystem og at skifte beskyttelse er to forskellige projekter. Det første flytter postkasser, historik, kalendere og konti på telefonerne. Det andet berører kun den vej, den indgående post tager.

Denne vej ligger i én DNS-post: MX, der fortæller afsenderservere, hvor posten til jeres domæne skal leveres. Når den peger på gatewayen, modtager gatewayen e-mailen, analyserer den og afleverer den derefter til postkasseserveren. Det gælder for:

  • Microsoft 365 (Exchange Online);
  • Google Workspace;
  • Exchange installeret hos jer eller hostet;
  • enhver anden e-mailserver, der modtager via SMTP;
  • Klytic Mail, der kun er ét tilfælde blandt andre, ikke en forudsætning.

Denne vejledning handler om det tilfælde, hvor postkassen bevares. Skifter I også server, beskriver vejledningerne skift fra Microsoft 365 og skift fra Google Workspace det projekt.

Hvem ændrer hvad

IndstillingHvorHvem
Domænets MX-postDNS-zonen hos domæneregistratoren eller DNS-udbyderenDen person, der administrerer DNS, eller den leverandør, der har fået det overdraget
Opsætning af gatewayen i e-mailsystemetAdministrationskonsollen i Microsoft 365, Google Workspace eller serverenAdministratoren af e-mailsystemet
SPF, DKIM og DMARCDNS-zonenDNS-administratoren, efter en kortlægning af de servere, der sender for domænet
Domæner og leveringsserverGatewayenLeverandøren af gatewayen, der forbereder konfigurationen

Princippet i Microsoft 365

Microsofts dokumentation om filtrering via en tredjepartstjeneste er klar: domænets MX skal pege på denne tjeneste, der derefter leverer til Exchange Online. Microsoft anbefaler en indgående connector af typen »partner«, der kan afvise post, som ikke er kommet via tjenesten. Microsoft anbefaler også at aktivere udvidet filtrering for connectors (Enhanced Filtering), så Microsofts egen analyse vurderer den reelle afsender og ikke gatewayens adresse. Microsoft fraråder blot at omgå sin filtrering for tredjepartstjenestens adresser.

Princippet i Google Workspace

Google beskriver en »indgående mailgateway«: MX peger på gatewayen, og administratoren angiver dens IP-adresser i konsollen. Gmail bruger dem til at finde afsenderens reelle adresse i headerne, som SPF og Googles spamvurdering afhænger af. Man kan også afvise post, der ikke kommer fra gatewayen. Google præciserer, at Gmail ikke anvender afsenderens DMARC-politik på post, der modtages via en angivet gateway: den kontrol overgår da til gatewayen.

Denne vejledning gengiver ikke skærmbillederne i disse konsoller, da de ændrer sig. Følg den officielle side, der er nævnt nederst, når indstillingen foretages.

Flere servere bag én gateway

Et hyppigt tilfælde i en koncern: moderselskabet på Microsoft 365, et datterselskab på Google Workspace, et tredje selskab på en ældre server. Én gateway kan stå foran alle tre.

Princippet er routing pr. domæne. Hvert domænes MX peger på gatewayen. For hvert domæne ved gatewayen, hvilken server posten skal afleveres til efter analysen. Analysen er fælles, destinationen varierer.

Fordelen: den samme filterpolitik eller forskellige indstillinger pr. domæne, og alle beslutninger kan læses samme sted. Det, der skal forberedes: et domæne, hvis postkasser er fordelt på to servere, kræver, at man ved, adresse for adresse, hvor der skal leveres. Det tilfælde undersøges før omlægningen.

Hvad der ændres, og hvad der ikke ændres

Ændres ikke: adresserne, postkasserne, historikken, e-mailprogrammet, webmailen, telefonerne. E-mailsystemets indbyggede filter fungerer fortsat. Rettigheder og interne delinger er fortsat platformens.

Ændres:

  • Den første server, der modtager posten. Det er den, der ser den oprindelige forbindelse og kontrollerer afsenderens godkendelse.
  • Postkasseserveren ser ikke længere afsenderen direkte, men gatewayen. Deraf den opsætning, der er beskrevet ovenfor.
  • E-mails bærer gatewayens beslutningsheadere: en administrator kan der læse, hvorfor en e-mail blev leveret eller lagt til side.
  • Videresender gatewayen også den udgående post, skal domænets SPF-post godkende den, og DKIM-signaturen skal offentliggøres for den. Betydningen af disse mekanismer forklares i SPF, DKIM og DMARC: hvad beskytter de, og hvad beskytter de ikke.

Den dag, I også skifter postkasseserver, kan gatewayen blive: kun dens leveringsserver ændres. Vejledningen skift e-mailsystem uden afbrydelse er fortsat referencen for den dag, også for SPF, DKIM og DMARC.

Idriftsættelsen, i rækkefølge

  1. Kortlægning: domæner, postkasseserver for hvert af dem, programmer, der sender post på domænets vegne.
  2. Leverandøren forbereder gatewayen: accepterede domæner, leveringsserver, startregler.
  3. Opsætning af gatewayen i e-mailsystemet (indgående connector eller indgående gateway), hvis platformen understøtter det.
  4. Sænk først TTL på MX, og ændr derefter MX. Så længe DNS-cachen gælder, leverer en del af afsenderne stadig direkte til postkasseserveren: det er normalt.
  5. Kontrol: en e-mail sendt fra en ekstern adresse skal ankomme med gatewayens beslutningsheadere.
  6. Overvågning af karantænen de første dage for at frigive falske positiver og justere reglerne.

Det er enkelt at gå tilbage: sæt den gamle MX ind igen. Det forberedes som ved en migrering, med en person, der har bemyndigelse til at beslutte det.

Hvad gatewayen ikke gør

Den ser den post, der passerer igennem den, og kun den. Den ser ikke e-mails mellem to postkasser på samme platform, som ikke forlader platformen, filer, der deles i en onlinelagring, eller brugernes logins.

Den erstatter derfor ikke de interne indstillinger i Microsoft 365 eller Google Workspace: rettigheder, totrinsgodkendelse, advarsler om logins, regler for automatisk videresendelse. En stjålet konto er først og fremmest et anliggende for e-mailsystemet. Vejledningen Spam, phishing, malware og kompromitterede konti skelner mellem tilfældene.

Endelig kan en afsender, der kender postkasseserverens tekniske adresse, forsøge at levere direkte til den uden om MX. Det er grunden til den aflåsning, som Microsoft (partner-connector) og Google (afvisning af post uden om gatewayen) tilbyder.

Ofte stillede spørgsmål

Skal brugerne orienteres?

Deres adresser ændres ikke. Fortæl dem derimod, at de kan modtage karantænemeddelelser: se Karantæne, falske positiver og indberetninger.

Skal filteret i Microsoft 365 eller Google slås fra?

Nej. Microsoft anbefaler at lade sin analyse være aktiv og indstille den, så den ser den reelle afsender, frem for at omgå den.

Hvor lang tid tager omlægningen?

Selve ændringen af MX slår igennem i takt med DNS-cachen. Forberedelsen afhænger af antallet af domæner og servere. For Klytic MTA, se næste afsnit.

Ændrer en gateway foran leveringsevnen for vores udgående post?

Kun hvis den også videresender den udgående post. I så fald skal SPF og DKIM tage højde for den: se SPF, DKIM og DMARC.

Hvorfor ikke bare skifte e-mailsystem?

Det er en anden beslutning med andre kriterier. Den behandles i vælg et europæisk professionelt e-mailsystem.

Hvor Klytic står

Klytic MTA placeres foran det e-mailsystem, I har: Microsoft 365, Google Workspace, Exchange, Klytic Mail eller enhver anden server. Den forudsætter ikke en Klytic-postkasse.

  • Idriftsættelse: normalt 24 til 48 timer. Klytic forbereder konfigurationen; I ændrer jeres domænes MX-post, eller Klytic gør det for jer. Opsætningen af gatewayen i Microsoft 365- eller Google Workspace-konsollen foretages af administratoren af dette e-mailsystem og forberedes sammen med Klytic ved idriftsættelsen.
  • Driftsform: Klytic-cloud, dedikeret instans eller kundens egne servere. Til særlige behov kan andre arkitekturer udformes sammen med Klytic, for eksempel filtrering i skyen og et relæ installeret hos jer, eller flere regioner.
  • Abonnementer: Essential og Advanced. Essential dækker godkendelse, antispam, antivirus, phishing, forvekslingsdomæner, karantæne, DKIM-signering af udgående post og tilbagekaldelse før afsendelse. Advanced tilføjer finansiel svindel, beskyttelse ved klik, DMARC-konsol og eksport af logfiler til et SIEM.
  • Prøveperiode: 30 dage gratis uden at skifte e-mailsystem.

Klytic MTA administrerer ikke rettigheder eller konti i jeres nuværende e-mailsystem og lover ikke at svare til de sikkerhedsværktøjer, der er indbygget i Microsoft 365 eller Google Workspace: den lægges foran dem.

Denne side beskriver et princip. Microsofts og Googles konsoller ændrer sig: deres officielle dokumentation er gældende for selve indstillingen.

Kilder

Gennemgået i oktober 2026.

  • Microsoft Learn, »Manage mail flow using a third-party cloud service with Exchange Online«: MX skal pege på tredjepartstjenesten; indgående connector af typen partner; udvidet filtrering for connectors frem for at omgå filtreringen. learn.microsoft.com
  • Google Workspace-hjælp, »Set up an inbound mail gateway«: MX til gatewayen, angivelse af dens IP-adresser, mulig afvisning af post uden om gatewayen; Gmail anvender ikke afsenderens DMARC-politik på post modtaget via gatewayen. knowledge.workspace.google.com
  • RFC 5321, SMTP: mellemliggende værter angives normalt af DNS-systemets MX-post. rfc-editor.org
  • Klytic, siden Klytic MTA: moduler i abonnementerne Essential og Advanced, tilvalg, driftsformer, idriftsættelse via MX. klytic.com

Beskyt jeres nuværende e-mailsystem

Gratis prøveperiode på 30 dage uden at skifte e-mailsystem: kun MX ændres.

Tal med en rådgiver →

Opdag Klytic MTA

Velkomsttilbud

30 dages gratis prøveperiode og hjælp til migrering

Uforpligtende prøvetilbud. En rådgiver ringer dig op for at forstå dine behov og klargøre dit Klytic-miljø.