E-postsikkerhet: MTA‑STS - Slik sikrer du e‑postdomenet ditt i 2025

lupe over e-post og lås-ikon
lupe over e-post og lås-ikon
lupe over e-post og lås-ikon

Security

E-postsikkerhet: MTA‑STS - Slik sikrer du e‑postdomenet ditt i 2025

September 11, 2025

I serien vår om e-postsikkerhet har vi til nå tatt for oss DMARC, DKIM og SPF.

Neste ut → MTA‑STS


Kortversjon (TL;DR): MTA‑STS tvinger frem kryptert og autentisert SMTP‑levering til domenet ditt. Du publiserer ett DNS‑oppslag (_mta-sts), én policyfil over HTTPSmta-sts.<ditt-domene>/.well-known/mta-sts.txt, og (anbefalt) TLS‑rapporter med DNS‑oppslaget _smtp._tls. Start i testing, gå over til enforce når alt ser bra ut.


Hvorfor ?

SMTP er designet for å levere e‑post «best effort». Uten ekstra tiltak er forbindelsen sårbar for downgrade og man‑in‑the‑middle‑angrep. De fleste store leverandører (f.eks. Google og Microsoft) støtter i dag MTA‑STS og TLS‑rapportering. For deg som domeneeier betyr det:

  • Kryptert i transitt: meldinger til domenet ditt leveres kun over TLS til godkjente MX‑verter.

  • Riktig sertifikat: avsender nekter levering hvis sertifikatet er ugyldig eller feil.

  • Innsikt: daglige TLS‑rapporter viser mislykkede forsøk, feil og mangler.

Resultatet er færre leveringsfeil, bedre personvern og lavere risiko.

illlustrasjon av MTA-STS sammen med SPF, DKIM og DMARC


Slik fungerer MTA‑STS – i to minutter

  1. Du legger inn en DNS TXT_mta-sts.<domene> for å signalisere at domenet bruker MTA‑STS og hvilken policy‑ID som er gjeldende.

  2. Avsenders MTA henter policyfilen via HTTPS fra https://mta-sts.<domene>/.well-known/mta-sts.txt.

  3. Filen sier hvilken modus (none/testing/enforce) som gjelder, hvilke MX‑verter som er autorisert, og hvor lenge (max_age) policyen kan caches.

  4. Ved levering sjekker avsender at

    • mottakers MX matcher policyen,

    • STARTTLS tilbys, og

    • sertifikatet er gyldig og passer til vertsnavnet.

  5. Hvis noe feiler og policyen er i enforce, leveres ikke meldingen.


Komponentene du trenger

1) DNS‑oppføring for MTA‑STS


Tips: Øk id (ofte et tidsstempel) hver gang du endrer policyfilen, slik at avsendere henter den på nytt.

2) Policyfilen på HTTPS

URL: https://mta-sts.example.no/.well-known/mta-sts.txt

Eksempel (start i testing):


Når alt er stabilt, bytt til enforce og (valgfritt) øk max_age (f.eks. 2592000 = 30 dager):


Wildcard: mx: kan bruke jokertegn på venstre label (f.eks. *.example.com). Oppgi én mx: per tillatt MX‑mønster.

3) (Anbefalt) TLS‑rapportering (TLS‑RPT)

Publiser en DNS TXT på _smtp._tls.<domene> for å få aggregerte JSON‑rapporter om TLS/MTA‑STS:


Du kan ha flere mottakere, separert med komma.


Steg‑for‑steg: Microsoft 365 (Exchange Online)

Mål: Beskytte domener hostet i Exchange Online. Microsoft hoster ikke policyfilen for deg, så du må publisere den selv.

  1. Host policyfilen – enklest med Azure Static Web Apps (automatisk TLS for mta-sts.<domene>). Alternativt Azure Functions + eget sertifikat.

  2. Lag policyfilen med innhold som over (start testing).

  3. Legg til CNAME/A for mta-sts.<domene> til hostingløsningen din og sørg for gyldig TLS‑sertifikat.

  4. Opprett DNS TXT_mta-sts.<domene> med v=STSv1; id=<timestamp>.

  5. Valider konfigurasjonen med en ekstern sjekk. Når alt ser bra ut: endre mode: enforce + bump id.

  6. Aktiver TLS‑RPT_smtp._tls.<domene> for løpende innsikt.

Eksempel policy for Exchange Online:



Steg‑for‑steg: Google Workspace (Gmail)

  1. Sjekk status og få anbefalt oppsett.

  2. Lag policyfilen (start testing). Eksempel på mx: for Google kan være aspmx.l.google.com og backup‑ene (alt1/alt2/alt3/alt4.aspmx.l.google.com).

  3. Publiser policyfilenhttps://mta-sts.<domene>/.well-known/mta-sts.txt.

  4. Opprett DNS TXT_mta-sts.<domene> med v=STSv1; id=<timestamp>.

  5. Aktiver TLS‑RPT_smtp._tls.<domene>.

  6. Overvåk rapporter, rett feil, og gå til enforce.

Eksempel policy for Google Workspace:



Beste praksis (procano‑anbefalinger)

  • Rull ut i to faser: testing (1–2 uker) → enforce.

  • Hold sertifikater i orden: Gyldige, offentlig betrodde kjeder. Automatisk fornyelse.

  • Bump id ved endringer: Ellers kan avsendere cache en gammel policy.

  • Sett fornuftig max_age: 7–30 dager er ofte passe. Ved store endringer, bruk lavere verdi midlertidig.

  • Overvåk TLS‑RPT: Automatiser parsing og varsling (SIEM/Log Analytics).

  • Dokumenter MX‑eierskap: Spesielt hvis du bruker flere e‑postleverandører.

  • Test failover: Simuler at en MX ikke tilbyr TLS eller har feil sertifikat.


Vanlige feil og hvordan du unngår dem

  • Manglende HTTPS eller feil sertifikatmta-sts.<domene> → avsendere får ikke hentet policyen.

  • Glemt å endre id etter policyendring → avsendere bruker gammel policy.

  • For brede mx‑mønstre (f.eks. *.example.com) som utilsiktet åpner for uautoriserte verter.

  • For lang max_age tidlig i utrullingen → vanskeligere å korrigere feil raskt.

  • Ingen TLS‑RPT → du oppdager ikke problemer før brukerne klager.


MTA‑STS vs. DANE (kort)

  • MTA‑STS bruker Web PKI + HTTPS for å distribuere policy. Krever ikke DNSSEC og er derfor lett å innføre.

  • DANE for SMTP er enda sterkere kryptografisk (binder TLS til DNSSEC), men krever DNSSEC på domenet og bred støtte i avsenders infrastruktur.

  • Kombiner gjerne: Hvis du har DNSSEC, bruk både DANE og MTA‑STS for maksimal robusthet.


Sjekkliste du kan kopiere

  • Host https://mta-sts.<domene>/.well-known/mta-sts.txt over HTTPS

  • Publiser _mta-sts.<domene> TXT: v=STSv1; id=<timestamp>

  • Legg inn gyldige mx:‑linjer i policyfilen

  • Sett mode: testing og max_age: 604800

  • Publiser _smtp._tls.<domene> TXT: v=TLSRPTv1; rua=mailto:<epost>

  • Valider med ekstern tester, fiks avvik

  • Bytt til mode: enforce, øk max_age, bump id

  • Etabler overvåking/varsling på TLS‑RPT

  • Sett årlig gjennomgang av policyen


Spørsmål og svar

Påvirker dette utgående e‑post?
– Nei, MTA‑STS du publiserer beskytter innkommende leveranser til deg. For utgående leveranser validerer din e‑postleverandør MTA‑STS hos mottaker.

Hvilken TLS‑versjon bør jeg kreve?
– TLS 1.2+ er minimum i praksis. Unngå utdaterte chiffer.

Hva om en avsender ikke støtter MTA‑STS?
– De sender som før (opportunistisk TLS/ukryptert). MTA‑STS gir effekt når avsenders infrastruktur støtter det – noe de store aktørene gjør.


Trenger du hjelp?

Procano hjelper deg å vurdere dagens MX‑/TLS‑stilling, rulle ut MTA‑STS trygt, sette opp TLS‑rapporter og automatisere overvåking. Ta kontakt, så setter vi opp en rask vurdering og plan for dine domener.

I serien vår om e-postsikkerhet har vi til nå tatt for oss DMARC, DKIM og SPF.

Neste ut → MTA‑STS


Kortversjon (TL;DR): MTA‑STS tvinger frem kryptert og autentisert SMTP‑levering til domenet ditt. Du publiserer ett DNS‑oppslag (_mta-sts), én policyfil over HTTPSmta-sts.<ditt-domene>/.well-known/mta-sts.txt, og (anbefalt) TLS‑rapporter med DNS‑oppslaget _smtp._tls. Start i testing, gå over til enforce når alt ser bra ut.


Hvorfor ?

SMTP er designet for å levere e‑post «best effort». Uten ekstra tiltak er forbindelsen sårbar for downgrade og man‑in‑the‑middle‑angrep. De fleste store leverandører (f.eks. Google og Microsoft) støtter i dag MTA‑STS og TLS‑rapportering. For deg som domeneeier betyr det:

  • Kryptert i transitt: meldinger til domenet ditt leveres kun over TLS til godkjente MX‑verter.

  • Riktig sertifikat: avsender nekter levering hvis sertifikatet er ugyldig eller feil.

  • Innsikt: daglige TLS‑rapporter viser mislykkede forsøk, feil og mangler.

Resultatet er færre leveringsfeil, bedre personvern og lavere risiko.

illlustrasjon av MTA-STS sammen med SPF, DKIM og DMARC


Slik fungerer MTA‑STS – i to minutter

  1. Du legger inn en DNS TXT_mta-sts.<domene> for å signalisere at domenet bruker MTA‑STS og hvilken policy‑ID som er gjeldende.

  2. Avsenders MTA henter policyfilen via HTTPS fra https://mta-sts.<domene>/.well-known/mta-sts.txt.

  3. Filen sier hvilken modus (none/testing/enforce) som gjelder, hvilke MX‑verter som er autorisert, og hvor lenge (max_age) policyen kan caches.

  4. Ved levering sjekker avsender at

    • mottakers MX matcher policyen,

    • STARTTLS tilbys, og

    • sertifikatet er gyldig og passer til vertsnavnet.

  5. Hvis noe feiler og policyen er i enforce, leveres ikke meldingen.


Komponentene du trenger

1) DNS‑oppføring for MTA‑STS


Tips: Øk id (ofte et tidsstempel) hver gang du endrer policyfilen, slik at avsendere henter den på nytt.

2) Policyfilen på HTTPS

URL: https://mta-sts.example.no/.well-known/mta-sts.txt

Eksempel (start i testing):


Når alt er stabilt, bytt til enforce og (valgfritt) øk max_age (f.eks. 2592000 = 30 dager):


Wildcard: mx: kan bruke jokertegn på venstre label (f.eks. *.example.com). Oppgi én mx: per tillatt MX‑mønster.

3) (Anbefalt) TLS‑rapportering (TLS‑RPT)

Publiser en DNS TXT på _smtp._tls.<domene> for å få aggregerte JSON‑rapporter om TLS/MTA‑STS:


Du kan ha flere mottakere, separert med komma.


Steg‑for‑steg: Microsoft 365 (Exchange Online)

Mål: Beskytte domener hostet i Exchange Online. Microsoft hoster ikke policyfilen for deg, så du må publisere den selv.

  1. Host policyfilen – enklest med Azure Static Web Apps (automatisk TLS for mta-sts.<domene>). Alternativt Azure Functions + eget sertifikat.

  2. Lag policyfilen med innhold som over (start testing).

  3. Legg til CNAME/A for mta-sts.<domene> til hostingløsningen din og sørg for gyldig TLS‑sertifikat.

  4. Opprett DNS TXT_mta-sts.<domene> med v=STSv1; id=<timestamp>.

  5. Valider konfigurasjonen med en ekstern sjekk. Når alt ser bra ut: endre mode: enforce + bump id.

  6. Aktiver TLS‑RPT_smtp._tls.<domene> for løpende innsikt.

Eksempel policy for Exchange Online:



Steg‑for‑steg: Google Workspace (Gmail)

  1. Sjekk status og få anbefalt oppsett.

  2. Lag policyfilen (start testing). Eksempel på mx: for Google kan være aspmx.l.google.com og backup‑ene (alt1/alt2/alt3/alt4.aspmx.l.google.com).

  3. Publiser policyfilenhttps://mta-sts.<domene>/.well-known/mta-sts.txt.

  4. Opprett DNS TXT_mta-sts.<domene> med v=STSv1; id=<timestamp>.

  5. Aktiver TLS‑RPT_smtp._tls.<domene>.

  6. Overvåk rapporter, rett feil, og gå til enforce.

Eksempel policy for Google Workspace:



Beste praksis (procano‑anbefalinger)

  • Rull ut i to faser: testing (1–2 uker) → enforce.

  • Hold sertifikater i orden: Gyldige, offentlig betrodde kjeder. Automatisk fornyelse.

  • Bump id ved endringer: Ellers kan avsendere cache en gammel policy.

  • Sett fornuftig max_age: 7–30 dager er ofte passe. Ved store endringer, bruk lavere verdi midlertidig.

  • Overvåk TLS‑RPT: Automatiser parsing og varsling (SIEM/Log Analytics).

  • Dokumenter MX‑eierskap: Spesielt hvis du bruker flere e‑postleverandører.

  • Test failover: Simuler at en MX ikke tilbyr TLS eller har feil sertifikat.


Vanlige feil og hvordan du unngår dem

  • Manglende HTTPS eller feil sertifikatmta-sts.<domene> → avsendere får ikke hentet policyen.

  • Glemt å endre id etter policyendring → avsendere bruker gammel policy.

  • For brede mx‑mønstre (f.eks. *.example.com) som utilsiktet åpner for uautoriserte verter.

  • For lang max_age tidlig i utrullingen → vanskeligere å korrigere feil raskt.

  • Ingen TLS‑RPT → du oppdager ikke problemer før brukerne klager.


MTA‑STS vs. DANE (kort)

  • MTA‑STS bruker Web PKI + HTTPS for å distribuere policy. Krever ikke DNSSEC og er derfor lett å innføre.

  • DANE for SMTP er enda sterkere kryptografisk (binder TLS til DNSSEC), men krever DNSSEC på domenet og bred støtte i avsenders infrastruktur.

  • Kombiner gjerne: Hvis du har DNSSEC, bruk både DANE og MTA‑STS for maksimal robusthet.


Sjekkliste du kan kopiere

  • Host https://mta-sts.<domene>/.well-known/mta-sts.txt over HTTPS

  • Publiser _mta-sts.<domene> TXT: v=STSv1; id=<timestamp>

  • Legg inn gyldige mx:‑linjer i policyfilen

  • Sett mode: testing og max_age: 604800

  • Publiser _smtp._tls.<domene> TXT: v=TLSRPTv1; rua=mailto:<epost>

  • Valider med ekstern tester, fiks avvik

  • Bytt til mode: enforce, øk max_age, bump id

  • Etabler overvåking/varsling på TLS‑RPT

  • Sett årlig gjennomgang av policyen


Spørsmål og svar

Påvirker dette utgående e‑post?
– Nei, MTA‑STS du publiserer beskytter innkommende leveranser til deg. For utgående leveranser validerer din e‑postleverandør MTA‑STS hos mottaker.

Hvilken TLS‑versjon bør jeg kreve?
– TLS 1.2+ er minimum i praksis. Unngå utdaterte chiffer.

Hva om en avsender ikke støtter MTA‑STS?
– De sender som før (opportunistisk TLS/ukryptert). MTA‑STS gir effekt når avsenders infrastruktur støtter det – noe de store aktørene gjør.


Trenger du hjelp?

Procano hjelper deg å vurdere dagens MX‑/TLS‑stilling, rulle ut MTA‑STS trygt, sette opp TLS‑rapporter og automatisere overvåking. Ta kontakt, så setter vi opp en rask vurdering og plan for dine domener.

I serien vår om e-postsikkerhet har vi til nå tatt for oss DMARC, DKIM og SPF.

Neste ut → MTA‑STS


Kortversjon (TL;DR): MTA‑STS tvinger frem kryptert og autentisert SMTP‑levering til domenet ditt. Du publiserer ett DNS‑oppslag (_mta-sts), én policyfil over HTTPSmta-sts.<ditt-domene>/.well-known/mta-sts.txt, og (anbefalt) TLS‑rapporter med DNS‑oppslaget _smtp._tls. Start i testing, gå over til enforce når alt ser bra ut.


Hvorfor ?

SMTP er designet for å levere e‑post «best effort». Uten ekstra tiltak er forbindelsen sårbar for downgrade og man‑in‑the‑middle‑angrep. De fleste store leverandører (f.eks. Google og Microsoft) støtter i dag MTA‑STS og TLS‑rapportering. For deg som domeneeier betyr det:

  • Kryptert i transitt: meldinger til domenet ditt leveres kun over TLS til godkjente MX‑verter.

  • Riktig sertifikat: avsender nekter levering hvis sertifikatet er ugyldig eller feil.

  • Innsikt: daglige TLS‑rapporter viser mislykkede forsøk, feil og mangler.

Resultatet er færre leveringsfeil, bedre personvern og lavere risiko.

illlustrasjon av MTA-STS sammen med SPF, DKIM og DMARC


Slik fungerer MTA‑STS – i to minutter

  1. Du legger inn en DNS TXT_mta-sts.<domene> for å signalisere at domenet bruker MTA‑STS og hvilken policy‑ID som er gjeldende.

  2. Avsenders MTA henter policyfilen via HTTPS fra https://mta-sts.<domene>/.well-known/mta-sts.txt.

  3. Filen sier hvilken modus (none/testing/enforce) som gjelder, hvilke MX‑verter som er autorisert, og hvor lenge (max_age) policyen kan caches.

  4. Ved levering sjekker avsender at

    • mottakers MX matcher policyen,

    • STARTTLS tilbys, og

    • sertifikatet er gyldig og passer til vertsnavnet.

  5. Hvis noe feiler og policyen er i enforce, leveres ikke meldingen.


Komponentene du trenger

1) DNS‑oppføring for MTA‑STS


Tips: Øk id (ofte et tidsstempel) hver gang du endrer policyfilen, slik at avsendere henter den på nytt.

2) Policyfilen på HTTPS

URL: https://mta-sts.example.no/.well-known/mta-sts.txt

Eksempel (start i testing):


Når alt er stabilt, bytt til enforce og (valgfritt) øk max_age (f.eks. 2592000 = 30 dager):


Wildcard: mx: kan bruke jokertegn på venstre label (f.eks. *.example.com). Oppgi én mx: per tillatt MX‑mønster.

3) (Anbefalt) TLS‑rapportering (TLS‑RPT)

Publiser en DNS TXT på _smtp._tls.<domene> for å få aggregerte JSON‑rapporter om TLS/MTA‑STS:


Du kan ha flere mottakere, separert med komma.


Steg‑for‑steg: Microsoft 365 (Exchange Online)

Mål: Beskytte domener hostet i Exchange Online. Microsoft hoster ikke policyfilen for deg, så du må publisere den selv.

  1. Host policyfilen – enklest med Azure Static Web Apps (automatisk TLS for mta-sts.<domene>). Alternativt Azure Functions + eget sertifikat.

  2. Lag policyfilen med innhold som over (start testing).

  3. Legg til CNAME/A for mta-sts.<domene> til hostingløsningen din og sørg for gyldig TLS‑sertifikat.

  4. Opprett DNS TXT_mta-sts.<domene> med v=STSv1; id=<timestamp>.

  5. Valider konfigurasjonen med en ekstern sjekk. Når alt ser bra ut: endre mode: enforce + bump id.

  6. Aktiver TLS‑RPT_smtp._tls.<domene> for løpende innsikt.

Eksempel policy for Exchange Online:



Steg‑for‑steg: Google Workspace (Gmail)

  1. Sjekk status og få anbefalt oppsett.

  2. Lag policyfilen (start testing). Eksempel på mx: for Google kan være aspmx.l.google.com og backup‑ene (alt1/alt2/alt3/alt4.aspmx.l.google.com).

  3. Publiser policyfilenhttps://mta-sts.<domene>/.well-known/mta-sts.txt.

  4. Opprett DNS TXT_mta-sts.<domene> med v=STSv1; id=<timestamp>.

  5. Aktiver TLS‑RPT_smtp._tls.<domene>.

  6. Overvåk rapporter, rett feil, og gå til enforce.

Eksempel policy for Google Workspace:



Beste praksis (procano‑anbefalinger)

  • Rull ut i to faser: testing (1–2 uker) → enforce.

  • Hold sertifikater i orden: Gyldige, offentlig betrodde kjeder. Automatisk fornyelse.

  • Bump id ved endringer: Ellers kan avsendere cache en gammel policy.

  • Sett fornuftig max_age: 7–30 dager er ofte passe. Ved store endringer, bruk lavere verdi midlertidig.

  • Overvåk TLS‑RPT: Automatiser parsing og varsling (SIEM/Log Analytics).

  • Dokumenter MX‑eierskap: Spesielt hvis du bruker flere e‑postleverandører.

  • Test failover: Simuler at en MX ikke tilbyr TLS eller har feil sertifikat.


Vanlige feil og hvordan du unngår dem

  • Manglende HTTPS eller feil sertifikatmta-sts.<domene> → avsendere får ikke hentet policyen.

  • Glemt å endre id etter policyendring → avsendere bruker gammel policy.

  • For brede mx‑mønstre (f.eks. *.example.com) som utilsiktet åpner for uautoriserte verter.

  • For lang max_age tidlig i utrullingen → vanskeligere å korrigere feil raskt.

  • Ingen TLS‑RPT → du oppdager ikke problemer før brukerne klager.


MTA‑STS vs. DANE (kort)

  • MTA‑STS bruker Web PKI + HTTPS for å distribuere policy. Krever ikke DNSSEC og er derfor lett å innføre.

  • DANE for SMTP er enda sterkere kryptografisk (binder TLS til DNSSEC), men krever DNSSEC på domenet og bred støtte i avsenders infrastruktur.

  • Kombiner gjerne: Hvis du har DNSSEC, bruk både DANE og MTA‑STS for maksimal robusthet.


Sjekkliste du kan kopiere

  • Host https://mta-sts.<domene>/.well-known/mta-sts.txt over HTTPS

  • Publiser _mta-sts.<domene> TXT: v=STSv1; id=<timestamp>

  • Legg inn gyldige mx:‑linjer i policyfilen

  • Sett mode: testing og max_age: 604800

  • Publiser _smtp._tls.<domene> TXT: v=TLSRPTv1; rua=mailto:<epost>

  • Valider med ekstern tester, fiks avvik

  • Bytt til mode: enforce, øk max_age, bump id

  • Etabler overvåking/varsling på TLS‑RPT

  • Sett årlig gjennomgang av policyen


Spørsmål og svar

Påvirker dette utgående e‑post?
– Nei, MTA‑STS du publiserer beskytter innkommende leveranser til deg. For utgående leveranser validerer din e‑postleverandør MTA‑STS hos mottaker.

Hvilken TLS‑versjon bør jeg kreve?
– TLS 1.2+ er minimum i praksis. Unngå utdaterte chiffer.

Hva om en avsender ikke støtter MTA‑STS?
– De sender som før (opportunistisk TLS/ukryptert). MTA‑STS gir effekt når avsenders infrastruktur støtter det – noe de store aktørene gjør.


Trenger du hjelp?

Procano hjelper deg å vurdere dagens MX‑/TLS‑stilling, rulle ut MTA‑STS trygt, sette opp TLS‑rapporter og automatisere overvåking. Ta kontakt, så setter vi opp en rask vurdering og plan for dine domener.

This page is translated using AI

Give feedback

two people shake hands

Upgrade the everyday IT

Schedule a non-binding meeting with one of our experts and get a free review of your IT environment.

two people shake hands

Upgrade the everyday IT

Schedule a non-binding meeting with one of our experts and get a free review of your IT environment.

two people shake hands

Upgrade the everyday IT

Schedule a non-binding meeting with one of our experts and get a free review of your IT environment.