Kort svar: En sikker mailserver kræver flere lag på én gang: krypteret forbindelse med TLS, afsendelse kun med login (SMTP AUTH), SPF, DKIM og DMARC på domænet, spam- og virusfilter, overvågning af leveringen og backup, der kan gendanne enkelte mails og mapper. For de fleste virksomheder giver en administreret mailløsning den sikkerhed med langt mindre drift end en egen server.
Fagligt gennemgået: 2. oktober 2026
Når jeres virksomhed er afhængig af e-mail til salg, support, fakturering og intern koordinering, er en mailserver ikke bare en teknisk detalje. Den skal være sikker, stabil og sat rigtigt op, så jeres beskeder bliver leveret, og så jeres domæne ikke er nemt at misbruge.
Denne guide gennemgår de krav, en mailserver til virksomheder skal opfylde, hvordan I får SPF, DKIM og DMARC til at virke i praksis, og hvornår det giver mening at drive mailserveren selv frem for at vælge administreret email hosting.
E-mail hosting til virksomheder, der vil have sikkerhed og stabil levering
En god mailløsning gør hverdagen lettere at drive. Medarbejdere, fælles postkasser og virksomhedsmail på eget domæne skal kunne administreres samlet og uden unødige manuelle arbejdsgange. Det betyder mindre tid på opsætning, færre fejl i den daglige drift og hurtigere hjælp, hvis en konto, en klient eller et domæne skal justeres.
Samler I mail, website og webshop hos én leverandør, bliver det også lettere at holde styr på domæner, DNS, hosting og support, især hvis I bruger WordPress eller WooCommerce og vil undgå at sende ansvaret rundt mellem flere udbydere.
Det bør I typisk få med i løsningen:
- Virksomhedsmail på eget domæne: professionelle adresser, der passer til jeres brand og giver et troværdigt afsenderbillede.
- Nem administration af e-mailkonti: oprettelse, ændring og nedlæggelse af postkasser uden unødig kompleksitet.
- Pålidelig levering: korrekt opsætning og overvågning, så vigtige mails ikke går tabt mellem afsender og modtager.
- Spam- og virusfilter: beskyttelse af indgående post, før den når medarbejderne.
- Plads til vækst: mulighed for flere postkasser og mere lagerplads uden at skifte platform.
Hos Hostious findes email hosting som Email Lite (5 GB pr. postkasse, 29 kr./md.), Email Pro (20 GB, 59 kr./md.) og Email Enterprise (50 GB, 99 kr./md.), alle ekskl. moms, med ubegrænset antal postkasser, IMAP, POP3, SMTP, webmail, spam- og virusfilter og dansk support døgnet rundt. Har I særlige krav, kan en server tilpasses efter behov.
Sikker mailserver med STARTTLS, SPF, DKIM og DMARC
Høj sikkerhed på en mailserver handler ikke kun om adgang til postkasser. En moderne opsætning kombinerer transportkryptering og domæneautentificering, så jeres mails både sendes sikkert og kan valideres af de modtagende servere.
Det betyder i praksis STARTTLS eller implicit TLS til krypteret transport samt DNS-baserede mekanismer som SPF, DKIM og DMARC. Kombinationen beskytter domænet mod spoofing og giver en troværdig afsenderprofil over for modtagernes systemer. Se også sådan vælger du erhvervsmail til firmaet.
Det amerikanske CISA anbefaler, at internetvendte mailservere tilbyder STARTTLS, at domæner har gyldige SPF- og DMARC-records, og at ældre usikre protokoller og krypteringsalgoritmer som SSLv2, SSLv3, RC4 og 3DES slås fra. Når jeres mail er forretningskritisk, er det ikke nok, at systemet kan sende beskeder. Opsætningen skal være gennemtænkt.
MTA-STS og TLS-rapportering for skærpede krav
STARTTLS mellem mailservere har en svaghed: forbindelsen kan nedgraderes til ukrypteret, hvis nogen sidder imellem og fjerner tilbuddet om kryptering. MTA-STS (RFC 8461) lukker det hul ved at lade jeres domæne offentliggøre en politik, der siger, at mail til jer kun må leveres over gyldig TLS. NIST fremhæver MTA-STS som en vigtig udvidelse til mere troværdig e-mail.
MTA-STS består af en TXT-record i DNS og en lille politikfil, der ligger på https://mta-sts.firma.dk/.well-known/mta-sts.txt. TLS-RPT (RFC 8460) er en tilhørende TXT-record, der får andre mailservere til at sende jer rapporter, når TLS-leveringen fejler. Et eksempel:
_mta-sts.firma.dk. TXT "v=STSv1; id=20261002"
_smtp._tls.firma.dk. TXT "v=TLSRPTv1; rua=mailto:tls-rapport@firma.dk"
# Indhold af mta-sts.txt
version: STSv1
mode: testing
mx: mail.firma.dk
max_age: 86400
Start i mode: testing, læs rapporterne, og skift først til mode: enforce, når I ved, at alle MX-servere har gyldige certifikater. Opdatér id-værdien, hver gang politikken ændres.
Syv krav, jeres mailserver skal opfylde
Siden 1. februar 2024 forventer Gmail, at alle afsendere har SPF eller DKIM på plads, sender over TLS og har en gyldig PTR-record (reverse DNS) på den afsendende server. Sender I mange mails, fx nyhedsbreve, ordreflows eller systemnotifikationer, kræves SPF, DKIM og DMARC, og spamraten skal holdes under 0,3 %. Mangler signalerne, ender mailen i spam eller bliver afvist.
Set som en helhed bør jeres mailserver leve op til disse syv punkter:
- Korrekt DNS og stabil levering: MX, A/AAAA og PTR skal passe sammen, så modtagere kan validere jeres infrastruktur.
- Autentificering med SPF, DKIM og DMARC: SPF og DKIM er minimum; DMARC fortæller modtageren, hvad der skal ske, når noget fejler.
- Krypteret transport: TLS eller STARTTLS med gyldigt certifikat mellem klient og server, og helst også mellem servere.
- Sikker klientafsendelse via SMTP AUTH: mailklienter og apps sender via autentificeret SMTP på port 587 eller 465, aldrig via åbent relay.
- Overvågning af omdømme og fejl: logs, bounce-data og Google Postmaster Tools gør det muligt at reagere, før leveringen bryder sammen.
- Backup og gendannelse på mailniveau: I skal kunne gendanne en enkelt mail, en mappe eller en hel postkasse, ikke kun hele serveren.
- Klare processer for administration: ændringer i DNS, certifikater og afsenderpolitikker skal ske kontrolleret og hurtigt.
Se punkterne som en kæde: Perfekt DNS hjælper ikke, hvis en kompromitteret konto kan sende frit via svag SMTP AUTH, og stærk sikkerhed uden backup gør stadig en fejlsletning til en driftskrise.
Sådan får I SPF, DKIM og DMARC til at virke i praksis
Det er i opsætningen, de fleste virksomheder snubler. Fremgangsmåden er den samme, uanset hvem der driver serveren:
- Kortlæg alle afsendere. Ikke kun mailklienterne, men også webshop, CRM, regnskabssystem, helpdesk, bookingsystem og nyhedsbrevstjeneste. Ét system, der sender uden for jeres SPF eller uden DKIM-signering, er nok til at skabe huller.
- Publicér én samlet SPF-record. Den skal beskrive alle servere og tjenester, der må sende på domænet. Der må kun være én SPF-record pr. domæne, og den må højst udløse 10 DNS-opslag (se SPF-fejlen too many DNS lookups).
- Aktivér DKIM alle steder. Både på den primære mailserver og hos tredjepartstjenester. SPF alene er sjældent robust, især når mails videresendes.
- Indfør DMARC gradvist. Start med en overvågende politik, læs rapporterne, og stram først op, når I ved, hvilke systemer der sender korrekt. SPF eller DKIM skal være i alignment med From-domænet, ellers fejler DMARC, selvom begge dele teknisk set validerer.
Et typisk udgangspunkt for de to records kan se sådan ud (tilpas include-delen til jeres egne afsendere):
firma.dk. TXT "v=spf1 mx include:_spf.eksempel-nyhedsbrev.dk -all"
_dmarc.firma.dk. TXT "v=DMARC1; p=none; rua=mailto:dmarc@firma.dk"
Vil I have baggrunden for de tre mekanismer, har vi en forklaring af SPF, DKIM og DMARC uden for meget teknisk støj.
Test leveringen, før I stoler på den
Når opsætningen er på plads, skal den testes systematisk:
- Send testmails til mindst to store modtagermiljøer, typisk Gmail og Microsoft 365. Se ikke kun, om mailen kommer frem, men om den lander i indbakken eller i spam, og hvor lang tid der går.
- Læs mailheaderne. Her står resultaterne for SPF, DKIM og DMARC samt oplysninger om TLS og den afsendende server. Mangler PTR, eller validerer DKIM ikke, står det ofte direkte i headeren.
- Følg domænets omdømme over tid i Google Postmaster Tools. Nærmer spamraten sig 0,3 %, bør I rense lister, stoppe dårlige flows og adskille marketingmails fra transaktionsmails.
En typisk fejl er at teste fra Outlook og konkludere, at alt virker. Det tester kun én afsendelsesvej. Bruger webshop, ERP eller kontaktformular en anden server, skal de valideres hver for sig.
Beskyt brugerkontiene – ofte det svageste led
Selv en perfekt konfigureret server hjælper ikke, hvis en angriber kender en medarbejders adgangskode. En kompromitteret postkasse bruges typisk til at sende spam eller falske fakturaer fra jeres eget domæne, og så består mailene både SPF, DKIM og DMARC, fordi de faktisk kommer fra jeres server. Resultatet er et ødelagt omdømme og i værste fald svindel mod jeres kunder.
Gør derfor disse ting til fast praksis:
- Brug lange, unikke adgangskoder til alle postkasser, og del dem aldrig mellem kolleger. Fælles postkasser bør have egne adgange frem for et fælles kodeord.
- Slå totrinslogin til i webmail og administrationspanel, hvor det er muligt.
- Luk postkasser ned eller skift adgangskode, når en medarbejder stopper.
- Sæt en grænse for, hvor mange mails én konto må sende pr. time, så en kompromitteret konto ikke kan sende tusindvis af mails, før nogen opdager det.
- Reagér hurtigt på signaler som pludselige bounces, klager eller mails i sendt post, som ingen kan genkende.
Se også adgangsstyring i teams om roller og deling uden fælles kodeord.
SMTP, IMAP og POP3: hvad skal I bruge?
De tre protokoller har hver sin rolle:
| Protokol | Rolle | Anbefaling til virksomheder |
|---|---|---|
| SMTP | Sender mail fra klient til server og mellem servere | Klientafsendelse skal ske med SMTP AUTH på port 587 eller 465 over krypteret forbindelse, uanset om brugeren læser mail via IMAP eller POP3. |
| IMAP | Synkroniserer postkassen mellem server og alle enheder | Det rigtige valg for de fleste, fordi mapper, læst-status og sendt post følger med på mobil, laptop og webmail. |
| POP3 | Henter mail ned til én lokal klient | Kun relevant til ældre opsætninger (typisk port 995 med TLS). Uegnet, når flere enheder eller kolleger deler en postkasse. |
Se også forskellen på IMAP, POP3 og webmail, hvis I er i tvivl om, hvad medarbejderne skal sættes op med.
To ting overses ofte. For det første gør TLS ikke mailen ende-til-ende-krypteret. Den beskytter transportvejen, ikke nødvendigvis indholdet gennem hele kæden. For det andet er printere, ERP-systemer og andre ældre enheder tit det svageste led. Kan de ikke bruge moderne autentificering stabilt, bør de sende gennem en kontrolleret relay-løsning i stedet for direkte mod internettet.
Egen mailserver eller administreret e-mail hosting?
Valget mellem egen drift og administreret e-mail hosting afhænger af kompetencer, risiko og krav til responstid:
| Kriterium | Egen mailserver | Administreret e-mail hosting |
|---|---|---|
| Kontrol | Fuld kontrol over logs, routing, sikkerhedspolitikker og integrationer | Leverandøren styrer platformen; I styrer brugere, domæner og flows |
| Driftsbyrde | I overvåger selv omdømme, certifikater, opdateringer og backup | Overvågning og basisdrift ligger hos leverandøren |
| Passer til | Organisationer med intern driftserfaring og faste processer | Små og mellemstore virksomheder, webshops og bureauer |
| Ansvar | Ejer I hele stakken, ejer I hele ansvaret | Kortere fejlretningstid og mindre driftsrisiko |
Uanset model bør backup vurderes på, hvor selektivt I kan gendanne. Den typiske hændelse er ikke et servernedbrud, men en bruger, der sletter en mappe eller overskriver en delt postkasse. En backup, der kun kan genskabe hele serveren, er sjældent nok i daglig drift. Spørg derfor jeres leverandør konkret, hvordan backup af postkasser fungerer, hvor længe den gemmes, og hvem der kan gendanne. Arbejder I med kontrakter, ordrer eller følsom kundedialog, bør I også have styr på opbevaringstider og på, hvem der må gendanne hvad. Læs mere om, hvordan automatisk backup fungerer.
Vælg ikke kun efter pris pr. postkasse, men efter leveringssikkerhed, gendannelsesmuligheder og hvor hurtigt en tekniker kan hjælpe, når mailen stopper.
Mailserver med høj sikkerhed kræver ikke mere kompleksitet end nødvendigt
En god mailløsning skal ikke gøre jeres hverdag tungere. Den skal give jer klare postkasser, ordentlig levering, sikker transport, god domænebeskyttelse og hurtig adgang til hjælp, når noget skal løses nu.
Er I i tvivl om jeres nuværende opsætning, så start med de tre hurtigste kontroller: findes der én korrekt SPF-record, signerer alle afsendere med DKIM, og har domænet en DMARC-record med rapportering? Svaret på de tre spørgsmål siger meget om, hvor sårbart domænet er.
Vil I have en dansk leverandør til mailen, kan I samle email hosting med WordPress- og WooCommerce-hosting hos Hostious og få dansk support døgnet rundt på hele kæden. Kontakt os, hvis I vil have afklaret behov og opsætning.
Læs også
- Hub: Mail: fejl og fejlfinding – alle guides om emnet samlet ét sted
- Nogen sender mails fra dit domæne: spoofing og DMARC-stramning
- SMTP-porte 25, 465 og 587 – og hvorfor port 25 er lukket
- Mail i EU: hvad du skal se efter hos en mailudbyder
- Email hosting hos Hostious – ubegrænset antal postkasser og dansk support
Ofte stillede spørgsmål om sikker mailserver
Hvad gør en mailserver ‘sikker’?
Krypteret forbindelse (TLS), autentificeret afsendelse, SPF, DKIM og DMARC på domænet, spam- og virusfilter samt backup af postkasserne. Mangler ét af lagene, er både levering og omdømme sårbart.
Hvad er DMARC, og behøver vi det?
DMARC fortæller modtagerne, hvad de skal gøre med mails, der fejler SPF og DKIM, og giver jer rapporter om misbrug af domænet. Ja: uden DMARC kan andre lettere udgive sig for at være jer.
Skal vi drive vores egen mailserver?
Næsten aldrig. Drift, omdømme og blacklists kræver konstant pasning. En administreret mailløsning giver samme kontrol over domænet uden ansvaret for infrastrukturen.
Hvem sælger sikker e-mailhosting til virksomhedskommunikation i Danmark?
Hostious leverer email hosting på eget domæne til danske virksomheder med spam- og virusfilter, adgang via IMAP, POP3, SMTP og webmail og dansk support døgnet rundt. Pakkerne hedder Email Lite (5 GB pr. postkasse, 29 kr./md.), Email Pro (20 GB, 59 kr./md.) og Email Enterprise (50 GB, 99 kr./md.), alle ekskl. moms og med ubegrænset antal postkasser. Serverne står i Europa.
Udgivet 24. juli 2026Opdateret 3. oktober 2026Fagligt gennemgået 2. oktober 2026
