Transportkrypteringen af mail kontrolleres på tre punkter: hvilke TLS-versioner jeres mailservere tilbyder, om domænet har en MTA-STS-politik, der beder andre om at kræve kryptering, og om I modtager TLS-rapporter, der viser, hvor krypteringen fejler. Rapporterne er beviset for, at politikken virker.
Mail mellem servere bruger STARTTLS, og krypteringen er som udgangspunkt frivillig. Kan den ikke etableres, sendes mailen ofte alligevel. MTA-STS er standarden, der gør den frivillige kryptering til et krav for de afsendere, der følger politikken.
Bunden: TLS 1.2
De statslige tekniske minimumskrav siger, at mailkommunikation krypteres med mindst TLS 1.2. Ukrypteret kommunikation er tilladt, når modparten ikke understøtter kryptering, fordi en myndighed ikke kan afvise mail fra borgere. Mellem statslige myndigheder skal krypteringen være tvungen. Kravene binder kun myndighederne.
SAMSIK’s TLS-vejledning fra 11. november 2026 gælder også mailservere. I dens bilag er TLS 1.3 “God”, TLS 1.2 “Tilstrækkelig”, og TLS 1.1, 1.0 og SSL er “Utilstrækkelig”. Hvordan en servers versioner måles, står i certifikater og TLS.
MTA-STS: politikken
MTA-STS er beskrevet i RFC 8461 fra september 2018. Et domæne publicerer to ting:
- en TXT-post på _mta-sts.<domæne> med version og et id, der ændres, når politikken ændres
- en politikfil på https://mta-sts.<domæne>/.well-known/mta-sts.txt med felterne version, mode, mx og max_age
Feltet mode har tre tilstande:
- enforce. Afsendende servere må ikke levere til værter, der ikke passer med mx-listen, ikke har et gyldigt certifikat eller ikke understøtter STARTTLS.
- testing. Fejl rapporteres, men mailen leveres, som om der ingen fejl var.
- none. Behandles som ingen politik. Bruges, når politikken skal fjernes.
max_age angives i sekunder, højst 31557600, og er typisk uger eller mere. Det er den tid, afsendere husker politikken.
Rapporterne: TLSRPT
RFC 8460 beskriver rapporterne. En TXT-post på _smtp._tls.<domæne> med “rua=” angiver, hvor rapporterne skal sendes. Afsendere, der understøtter standarden, sender så rapporter om de forbindelser, de har forsøgt, og om krypteringen lykkedes.
Uden rapporterne er “testing” blind. Det er rapporterne, der viser, om en “enforce” vil stoppe legitim mail.
Fra prøve til håndhævelse
Vejen følger standardens egen logik. Først publiceres politikken i “testing” sammen med TLSRPT. Rapporterne læses, og fejl rettes, typisk et certifikat, der ikke passer med navnet på mailserveren, eller en mx, der mangler i politikken. Når rapporterne er rene, skiftes til “enforce”. Hvor lang tid der skal gå mellem trinnene, siger standarden ikke. Det er praksis og afhænger af, hvor mange modparter I har.
Gennemgangen noterer for hvert domæne med mail, hvilken tilstand politikken står i, hvor længe den har stået der, og om rapporterne bliver læst.
Modtagersiden og afsendersiden
MTA-STS beskytter mail, der sendes til jeres domæne, når afsenderen følger politikken. Det omvendte er jeres egne servere, når de sender ud. Følger de andres MTA-STS-politikker, og hvad gør de, når en modpart ikke tilbyder kryptering? Det er indstillinger i jeres mailsystem eller hos jeres udbyder, og gennemgangen noterer dem for sig. I staten er svaret givet for trafik mellem myndigheder, hvor krypteringen skal være tvungen.
Det, testværktøjer ikke viser
sikkerpånettet.dk’s mailtest måler STARTTLS, DANE og et gyldigt servercertifikat. MTA-STS står ikke blandt testens punkter. Et godt resultat dér siger derfor intet om jeres MTA-STS-politik. Hvad testen ellers dækker, står i sikkerpånettet.dk som hurtig egenkontrol.
DANE nævnes i SAMSIK’s domænevejledning som et supplerende tiltag, der forudsætter DNSSEC. Vejledningen behandler det ikke nærmere, og det gør vi heller ikke her.
Det kan driften selv
Driften kan publicere politikken i “testing” og posten for TLSRPT uden at ændre noget i mailflowet. Det kræver en lille webside på et underdomæne med et gyldigt certifikat og to DNS-poster. Sæt en postkasse op til rapporterne, og læs dem i nogle uger. Først når fejlene er rettet, er skiftet til “enforce” en beslutning, der kan tages på et grundlag.
Hvad det kræver, og hvad det koster at lade være
Det kræver adgang til DNS, et sted at lægge politikfilen og en postkasse til rapporterne. Det tunge er at læse rapporterne og rette de fejl, de viser.
Uden MTA-STS kan en mail til jer blive leveret ukrypteret, hvis krypteringen fejler undervejs, og hverken afsender eller modtager opdager det. Uden rapporterne ved I ikke, hvor ofte det sker.
Det skal I lade være med
- At gå direkte til “enforce” · fejl i certifikat eller mx-liste stopper legitim mail.
- At publicere en politik uden TLSRPT · så kan I ikke se, om den virker.
- At glemme at ændre id, når politikken ændres · afsendere henter den ellers ikke igen.
Det skal gennemgangen kunne vise
- ☐ Mailservere, der tilbyder mindst TLS 1.2.
- ☐ En MTA-STS-politik for hvert domæne med mail og dens tilstand.
- ☐ En TLSRPT-post og TLS-rapporter, som nogen læser.
- ☐ En plan fra “testing” til “enforce”.
Kilder
- SAMSIK, Vejledning til de tekniske minimumskrav til it-sikkerhed i staten (september 2025), afsnit 3.2, læst 13. november 2026.
- RFC 8461, SMTP MTA Strict Transport Security (september 2018), afsnit 3.1, 3.2 og 5, læst 13. november 2026.
- RFC 8460, SMTP TLS Reporting (september 2018), afsnit 3, læst 13. november 2026.
- SAMSIK, Sikker brug af Transport Layer Security (TLS) med bilag (november 2026), læst 13. november 2026.
- sikkerpånettet.dk, Om e-mailtesten, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Publicér en MTA-STS-politik i “testing” og en TLSRPT-post for jeres hoveddomæne, og læs rapporterne i nogle uger.
Læs også: SPF, DKIM og DMARC · Kryptering i hvile og under transport
→ Kontakt · Tlf. 70 13 63 23 · Teknisk sikkerhedsgennemgang hos Nielco IT
