MTA-STS, TLS-RPT og BIMI: neste steg etter DMARC

2026-09-26 · 8 min lesetid · Av MailWatch-teamet

MTA-STS, TLS-RPT og BIMI er de tre naturlige stegene etter at SPF, DKIM og DMARC er på plass. MTA-STS tvinger andre e-postservere til å bruke kryptert og verifisert TLS når de leverer e-post til deg, TLS-RPT gir deg rapporter når slik levering feiler, og BIMI lar logoen din vises ved siden av e-posten i innboksen – men bare når DMARC håndheves med quarantine eller reject. Her ser du hva hver standard gjør, hvilke DNS-poster og filer du trenger, og i hvilken rekkefølge det lønner seg å innføre dem.

Hvorfor trenger du mer enn DMARC?

SPF (RFC 7208), DKIM (RFC 6376) og DMARC (RFC 7489) handler om utgående e-post: de beviser at meldinger som utgir seg for å komme fra firma.no, faktisk gjør det. Hvis du ikke har dette på plass ennå, start med hva er DMARC og DMARC steg for steg.

Men DMARC sier ingenting om hvordan e-post til deg blir transportert. SMTP ble laget uten kryptering, og STARTTLS – utvidelsen som krypterer forbindelsen mellom e-postservere – er i utgangspunktet frivillig. En angriper som kan manipulere nettverkstrafikken, kan fjerne STARTTLS-tilbudet (et såkalt nedgraderingsangrep) eller peke avsenderen til en falsk MX-server. Avsenderen leverer da e-posten i klartekst eller til feil mottaker, uten at noen merker det. Det er dette MTA-STS løser.

Slik fungerer MTA-STS

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) består av to deler:

1. En TXT-post på _mta-sts.firma.no som forteller at domenet har en policy, og hvilken versjon den har.
2. En policyfil som hentes over HTTPS fra https://mta-sts.firma.no/.well-known/mta-sts.txt. Den lister opp hvilke MX-servere som er gyldige, og om TLS skal håndheves.

En avsenderserver som støtter MTA-STS – blant annet Gmail og Microsoft 365 – ser TXT-posten, henter policyen og mellomlagrer den. Ved senere leveranser krever den at MX-serveren har et gyldig TLS-sertifikat som stemmer med vertsnavnet. Hvis ikke, og policyen står i enforce, leveres ikke e-posten. Fordi policyen hentes over HTTPS med sertifikatvalidering, kan en angriper ikke bare forfalske den via DNS.

Steg 1: Lag policyfilen

Filen er ren tekst. For et domene som bruker Microsoft 365, kan den se slik ut:

version: STSv1
mode: testing
mx: *.mail.protection.outlook.com
max_age: 604800

For Google Workspace lister du Googles MX-verter i stedet, for eksempel:

version: STSv1
mode: testing
mx: smtp.google.com
mx: aspmx.l.google.com
mx: *.aspmx.l.google.com
max_age: 604800

Feltene betyr:

• mode: testing (feil rapporteres, men e-post leveres likevel), enforce (levering avbrytes ved feil) eller none (policyen trekkes tilbake).
• mx: én linje per gyldig MX-vert. Jokertegn er lov for ett nivå, som *.mail.protection.outlook.com.
• max_age: hvor lenge avsendere kan mellomlagre policyen, i sekunder. Maksimum er 31557600 (omtrent ett år). En uke (604800) er fornuftig mens du tester; mange går opp til flere måneder når policyen er stabil.

Steg 2: Publiser filen over HTTPS

Filen må ligge på nøyaktig https://mta-sts.firma.no/.well-known/mta-sts.txt, med et gyldig TLS-sertifikat for mta-sts.firma.no og innholdstypen text/plain. Du trenger altså et underdomene som peker til en webserver. Det kan være ditt eget webhotell, en statisk hosting-tjeneste eller en tjeneste som leverer MTA-STS for deg. Omdirigeringer (redirects) er ikke tillatt.

Steg 3: Publiser TXT-posten

_mta-sts.firma.no.  TXT  "v=STSv1; id=20260926T120000"

id er en unik verdi (opptil 32 bokstaver og tall) som avsendere bruker for å se om policyen er endret. Hver gang du endrer policyfilen, må du også endre id – ellers fortsetter avsenderne å bruke den mellomlagrede versjonen til max_age utløper. En tidsstempel-id som over gjør det enkelt.

TLS-RPT: rapporter om TLS-feil

TLS-RPT (SMTP TLS Reporting, RFC 8460) er for MTA-STS det rua-rapportene er for DMARC. Du publiserer én TXT-post, og avsendere som støtter standarden sender deg en daglig rapport om hvor mange forbindelser som lyktes, og hvilke som feilet – og hvorfor.

_smtp._tls.firma.no.  TXT  "v=TLSRPTv1; rua=mailto:tls-rapporter@firma.no"

Rapportene er JSON-filer (ofte gzip-komprimert) med feiltyper som certificate-expired, certificate-host-mismatch, starttls-not-supported eller sts-policy-fetch-error. De avslører for eksempel at sertifikatet på en backup-MX har gått ut, eller at policyfilen ikke kan hentes.

TLS-RPT har ingen risiko: posten påvirker ikke leveringen, den gir bare innsyn. Derfor bør du legge den inn samtidig med MTA-STS i testing-modus. Den virker også sammen med DANE (RFC 7672), et alternativ til MTA-STS som bygger på DNSSEC.

BIMI: logoen din i innboksen

BIMI (Brand Indicators for Message Identification) lar e-postklienter vise logoen din som avatar ved siden av meldinger fra domenet. Gmail, Apple Mail, Yahoo og flere andre støtter det. BIMI er ikke en ferdig RFC, men en spesifikasjon utviklet av BIMI Group, og den bygger direkte på DMARC.

Krav før du kan bruke BIMI

• DMARC må håndheves: p=quarantine eller p=reject på organisasjonsdomenet, med pct=100 (standardverdien hvis pct utelates). p=none eller en lavere pct kvalifiserer ikke, og underdomenepolicyen (sp) kan heller ikke være none.
• SPF og DKIM må passere med alignment for meldingene som skal vise logoen.
• Logoen må være i SVG Tiny PS (Portable/Secure), en begrenset SVG-profil: kvadratisk, baseProfile="tiny-ps", et <title>-element, ingen skript, ingen eksterne referanser og ingen innebygde punktbilder.
• Et merkesertifikat – i praksis nødvendig for Gmail og Apple Mail.

VMC eller CMC?

Begge sertifikattypene kjøpes fra godkjente utstedere (blant andre DigiCert og GlobalSign), innebærer identitetskontroll av virksomheten og har en årlig kostnad. For varemerker gjelder det at registreringen må være hos et varemerkekontor som utstederne godtar – sjekk dette før du bestiller.

BIMI-posten

default._bimi.firma.no.  TXT  "v=BIMI1; l=https://firma.no/bimi/logo.svg; a=https://firma.no/bimi/vmc.pem"

l= peker til logoen og a= til sertifikatet (PEM-fil). Begge må serveres over HTTPS. Uten sertifikat kan du utelate a=, men da vil de fleste store klienter ikke vise logoen.

Anbefalt rekkefølge

1. SPF, DKIM og DMARC med p=none – grunnmuren. Se veiledningene for Microsoft 365 og Google Workspace.
2. TLS-RPT – ufarlig og gir innsikt fra dag én.
3. MTA-STS i testing – følg med på TLS-rapportene i et par uker.
4. DMARC til quarantine og reject – basert på DMARC-rapportene.
5. MTA-STS i enforce – når TLS-rapportene er rene.
6. BIMI – når DMARC håndheves på 100 % og du har logo og sertifikat klart.

Vanlige feil

• Glemt å endre id i _mta-sts-posten etter at policyfilen er oppdatert.
• Utløpt sertifikat på mta-sts-underdomenet, slik at policyen ikke kan hentes.
• MX-verter som mangler i policyen, for eksempel en backup-MX eller nye MX-navn etter et leverandørbytte.
• BIMI med DMARC p=none – logoen vises aldri.
• SVG-logo lagret som vanlig SVG fra et designprogram i stedet for SVG Tiny PS.

Vil du se hvordan domenet ditt står i dag? Sjekk domenet ditt gratis.

Ofte stilte spørsmål

Hva er MTA-STS?

MTA-STS (RFC 8461) er en standard som lar et domene kreve at andre e-postservere bruker kryptert TLS med gyldig sertifikat når de leverer e-post til domenet. Den består av en TXT-post på _mta-sts og en policyfil som publiseres over HTTPS på mta-sts-underdomenet. Den beskytter mot nedgraderingsangrep og falske MX-servere.

Hva er forskjellen på testing og enforce i MTA-STS?

I testing-modus leverer avsendere e-posten selv om TLS-kontrollen feiler, men feilene rapporteres via TLS-RPT. I enforce-modus avbrytes leveringen hvis MX-serveren ikke har gyldig TLS eller ikke står i policyen. Start alltid med testing.

Trenger jeg TLS-RPT hvis jeg har MTA-STS?

Ja, det anbefales sterkt. TLS-RPT (RFC 8460) er den eneste måten å få vite at avsendere har problemer med å levere til deg over TLS. Uten rapportene oppdager du ikke feil før e-post faktisk uteblir.

Hvilken DMARC-policy krever BIMI?

BIMI krever at DMARC håndheves med p=quarantine eller p=reject, og at policyen gjelder 100 % av meldingene. p=none kvalifiserer ikke. I tillegg må meldingene passere DMARC for at logoen skal vises.

Må jeg ha registrert varemerke for å bruke BIMI?

For et VMC-sertifikat, ja. Med et CMC-sertifikat trenger du ikke registrert varemerke, men logoen må ha vært brukt offentlig i minst 12 måneder. Gmail viser logoen med begge typer, men den blå verifisert-haken krever VMC.

Oppsummering

MTA-STS og TLS-RPT sikrer at e-post til deg leveres kryptert og at du får vite når det svikter, mens BIMI gir synlig merkevare i innboksen som belønning for et strengt DMARC-oppsett. Alt sammen hviler på DNS-poster og sertifikater som kan endres eller utløpe uten at noen merker det. MailWatch overvåker e-postoppsettet ditt kontinuerlig og varsler på e-post, SMS eller Pushover når noe endrer seg. Prøv MailWatch gratis i 30 dager.

Prøv MailWatch gratis i 30 dager · Sjekk domenet ditt gratis