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



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 HTTPS på mta-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.

Slik fungerer MTA‑STS – i to minutter
Du legger inn en DNS TXT på
_mta-sts.<domene>
for å signalisere at domenet bruker MTA‑STS og hvilken policy‑ID som er gjeldende.Avsenders MTA henter policyfilen via HTTPS fra
https://mta-sts.<domene>/.well-known/mta-sts.txt
.Filen sier hvilken modus (none/testing/enforce) som gjelder, hvilke MX‑verter som er autorisert, og hvor lenge (max_age) policyen kan caches.
Ved levering sjekker avsender at
mottakers MX matcher policyen,
STARTTLS tilbys, og
sertifikatet er gyldig og passer til vertsnavnet.
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 énmx:
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.
Host policyfilen – enklest med Azure Static Web Apps (automatisk TLS for
mta-sts.<domene>
). Alternativt Azure Functions + eget sertifikat.Lag policyfilen med innhold som over (start
testing
).Legg til CNAME/A for
mta-sts.<domene>
til hostingløsningen din og sørg for gyldig TLS‑sertifikat.Opprett DNS TXT på
_mta-sts.<domene>
medv=STSv1; id=<timestamp>
.Valider konfigurasjonen med en ekstern sjekk. Når alt ser bra ut: endre
mode: enforce
+ bumpid
.Aktiver TLS‑RPT på
_smtp._tls.<domene>
for løpende innsikt.
Eksempel policy for Exchange Online:
Steg‑for‑steg: Google Workspace (Gmail)
Sjekk status og få anbefalt oppsett.
Lag policyfilen (start
testing
). Eksempel påmx:
for Google kan væreaspmx.l.google.com
og backup‑ene (alt1/alt2/alt3/alt4.aspmx.l.google.com
).Publiser policyfilen på
https://mta-sts.<domene>/.well-known/mta-sts.txt
.Opprett DNS TXT på
_mta-sts.<domene>
medv=STSv1; id=<timestamp>
.Aktiver TLS‑RPT på
_smtp._tls.<domene>
.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 sertifikat på
mta-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 HTTPSPubliser
_mta-sts.<domene>
TXT:v=STSv1; id=<timestamp>
Legg inn gyldige
mx:
‑linjer i policyfilenSett
mode: testing
ogmax_age: 604800
Publiser
_smtp._tls.<domene>
TXT:v=TLSRPTv1; rua=mailto:<epost>
Valider med ekstern tester, fiks avvik
Bytt til
mode: enforce
, økmax_age
, bumpid
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 HTTPS på mta-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.

Slik fungerer MTA‑STS – i to minutter
Du legger inn en DNS TXT på
_mta-sts.<domene>
for å signalisere at domenet bruker MTA‑STS og hvilken policy‑ID som er gjeldende.Avsenders MTA henter policyfilen via HTTPS fra
https://mta-sts.<domene>/.well-known/mta-sts.txt
.Filen sier hvilken modus (none/testing/enforce) som gjelder, hvilke MX‑verter som er autorisert, og hvor lenge (max_age) policyen kan caches.
Ved levering sjekker avsender at
mottakers MX matcher policyen,
STARTTLS tilbys, og
sertifikatet er gyldig og passer til vertsnavnet.
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 énmx:
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.
Host policyfilen – enklest med Azure Static Web Apps (automatisk TLS for
mta-sts.<domene>
). Alternativt Azure Functions + eget sertifikat.Lag policyfilen med innhold som over (start
testing
).Legg til CNAME/A for
mta-sts.<domene>
til hostingløsningen din og sørg for gyldig TLS‑sertifikat.Opprett DNS TXT på
_mta-sts.<domene>
medv=STSv1; id=<timestamp>
.Valider konfigurasjonen med en ekstern sjekk. Når alt ser bra ut: endre
mode: enforce
+ bumpid
.Aktiver TLS‑RPT på
_smtp._tls.<domene>
for løpende innsikt.
Eksempel policy for Exchange Online:
Steg‑for‑steg: Google Workspace (Gmail)
Sjekk status og få anbefalt oppsett.
Lag policyfilen (start
testing
). Eksempel påmx:
for Google kan væreaspmx.l.google.com
og backup‑ene (alt1/alt2/alt3/alt4.aspmx.l.google.com
).Publiser policyfilen på
https://mta-sts.<domene>/.well-known/mta-sts.txt
.Opprett DNS TXT på
_mta-sts.<domene>
medv=STSv1; id=<timestamp>
.Aktiver TLS‑RPT på
_smtp._tls.<domene>
.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 sertifikat på
mta-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 HTTPSPubliser
_mta-sts.<domene>
TXT:v=STSv1; id=<timestamp>
Legg inn gyldige
mx:
‑linjer i policyfilenSett
mode: testing
ogmax_age: 604800
Publiser
_smtp._tls.<domene>
TXT:v=TLSRPTv1; rua=mailto:<epost>
Valider med ekstern tester, fiks avvik
Bytt til
mode: enforce
, økmax_age
, bumpid
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 HTTPS på mta-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.

Slik fungerer MTA‑STS – i to minutter
Du legger inn en DNS TXT på
_mta-sts.<domene>
for å signalisere at domenet bruker MTA‑STS og hvilken policy‑ID som er gjeldende.Avsenders MTA henter policyfilen via HTTPS fra
https://mta-sts.<domene>/.well-known/mta-sts.txt
.Filen sier hvilken modus (none/testing/enforce) som gjelder, hvilke MX‑verter som er autorisert, og hvor lenge (max_age) policyen kan caches.
Ved levering sjekker avsender at
mottakers MX matcher policyen,
STARTTLS tilbys, og
sertifikatet er gyldig og passer til vertsnavnet.
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 énmx:
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.
Host policyfilen – enklest med Azure Static Web Apps (automatisk TLS for
mta-sts.<domene>
). Alternativt Azure Functions + eget sertifikat.Lag policyfilen med innhold som over (start
testing
).Legg til CNAME/A for
mta-sts.<domene>
til hostingløsningen din og sørg for gyldig TLS‑sertifikat.Opprett DNS TXT på
_mta-sts.<domene>
medv=STSv1; id=<timestamp>
.Valider konfigurasjonen med en ekstern sjekk. Når alt ser bra ut: endre
mode: enforce
+ bumpid
.Aktiver TLS‑RPT på
_smtp._tls.<domene>
for løpende innsikt.
Eksempel policy for Exchange Online:
Steg‑for‑steg: Google Workspace (Gmail)
Sjekk status og få anbefalt oppsett.
Lag policyfilen (start
testing
). Eksempel påmx:
for Google kan væreaspmx.l.google.com
og backup‑ene (alt1/alt2/alt3/alt4.aspmx.l.google.com
).Publiser policyfilen på
https://mta-sts.<domene>/.well-known/mta-sts.txt
.Opprett DNS TXT på
_mta-sts.<domene>
medv=STSv1; id=<timestamp>
.Aktiver TLS‑RPT på
_smtp._tls.<domene>
.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 sertifikat på
mta-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 HTTPSPubliser
_mta-sts.<domene>
TXT:v=STSv1; id=<timestamp>
Legg inn gyldige
mx:
‑linjer i policyfilenSett
mode: testing
ogmax_age: 604800
Publiser
_smtp._tls.<domene>
TXT:v=TLSRPTv1; rua=mailto:<epost>
Valider med ekstern tester, fiks avvik
Bytt til
mode: enforce
, økmax_age
, bumpid
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
Recent posts

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

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

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