Du satte opp SPF, DKIM og DMARC for ett år siden. E-postene går gjennom, domenet ditt er beskyttet mot spoofing, og IT-konsulenten nikket godkjennende. Men tre ting skjer fortsatt hver dag: meldinger sendes ukryptert mellom servere, du har null innsikt i om mottakerne faktisk respekterer DMARC-policyen din, og logoen din vises aldri i innboksen hos Gmail eller Outlook. Det er hull i sikkerhetsnettverket du trodde var komplett.
MTA-STS, TLS-RPT og BIMI er ikke nye standarder lenger. De ble lansert for å løse nøyaktig disse problemene. Likevel har under 15 prosent av norske bedriftsdomener implementert dem, ifølge Googles Transparency Report. Grunnen? De høres tekniske ut, dokumentasjonen er fragmentert, og folk tror feilaktig at implementering vil brekke e-postleveransen.
Denne artikkelen forklarer hva hver av dem gjør, hvorfor du trenger dem, og hvordan du ruller ut uten risiko.
Problemet med SPF, DKIM og DMARC alene
SPF, DKIM og DMARC autentiserer avsender. De forteller mottakeren: "Ja, denne meldingen kommer faktisk fra @firmanavn.no." Men de løser ikke tre kritiske svakheter:
- Transport-sikkerhet: E-post sendes over SMTP, et protokoll fra 1982. Standard SMTP har ingen kryptering. Selv om du har SPF/DKIM/DMARC, kan meldingen din reise i klartekst gjennom åtte mellomservere før den når mottakeren. En angripende mellommann kan lese, endre eller blokkere den.
- Policy-etterlevelse: DMARC forteller mottakeren hva de skal gjøre med falske meldinger (quarantine/reject). Men du får aldri vite om de faktisk gjør det. Noen mailservere ignorerer DMARC helt.
- Visuell tillit: Gmail og Outlook viser avsenderlogo for merkevarer de stoler på. Uten BIMI ser alle e-postene dine ut som generiske initialer i en sirkel. Kunder kan ikke skille deg fra phishing-forsøk ved første øyekast.
Her kommer MTA-STS, TLS-RPT og BIMI inn.
MTA-STS: tvungen kryptering på transport-laget
MTA-STS (Mail Transfer Agent Strict Transport Security) er HTTPS for e-post. Den publiserer en policy som sier: "All e-post til vårt domene MÅ sendes over TLS. Hvis mottaksserveren ikke støtter kryptert forbindelse, lever ikke meldingen."
Uten MTA-STS kan en angriper blokkere TLS-oppgraderingen og tvinge meldingen ned til ukryptert SMTP. Med MTA-STS vil avsendersystemet nekte å levere hvis kryptering ikke fungerer. Det høres drastisk ut, men realiteten er at 95 prosent av moderne mailservere allerede støtter TLS. Du blokkerer kun legacy-systemer som uansett ikke burde sende sensitiv e-post.
Implementering: Du publiserer en tekstfil på https://mta-sts.dittdomene.no/.well-known/mta-sts.txt med innhold som dette:
version: STSv1
mode: enforce
mx: mail.dittdomene.no
max_age: 604800
Deretter legger du til en DNS TXT-record: _mta-sts.dittdomene.no med verdi v=STSv1; id=20250101. ID-feltet endres hver gang du oppdaterer policyen, slik at mailservere vet de må hente ny versjon.
Start med mode: testing i 14 dager. Overvåk TLS-RPT-rapportene (se under) for å se om noen legitime avsendere feiler. Deretter bytt til mode: enforce.
TLS-RPT: innsikt i hva som faktisk skjer
TLS-RPT (TLS Reporting) sender deg daglige rapporter om TLS-forbindelser til ditt domene. Hver rapport viser:
- Hvor mange meldinger som ble levert over kryptert forbindelse
- Hvor mange som feilet TLS-oppgradering (og hvorfor)
- Hvilke IP-adresser/domener som hadde problemer
Uten TLS-RPT flyr du blind. Med TLS-RPT ser du nøyaktig om MTA-STS blokkerer legitime avsendere, eller om noen prøver downgrade-angrep.
Implementering: Legg til en DNS TXT-record: _smtp._tls.dittdomene.no med verdi:v=TLSRPTv1; rua=mailto:tls-reports@dittdomene.no
Rapportene kommer i JSON-format. Du kan parse dem manuelt eller bruke en tjeneste som parsedmarc. Sentinel PLUSS-abonnenter får e-post-helse-score basert på DMARC-rapporter; TLS-RPT-analyse kommer i en fremtidig oppdatering.
BIMI: vis logoen din i innboksen
BIMI (Brand Indicators for Message Identification) lar deg vise bedriftens logo ved siden av e-posten i Gmail, Yahoo og Apple Mail. Det er ikke bare kosmetikk. En synlig, verifisert logo reduserer phishing-risiko fordi kunder umiddelbart ser forskjellen mellom ekte og falske meldinger.
BIMI krever at du allerede har DMARC på quarantine eller reject. Deretter publiserer du en DNS TXT-record som peker til en SVG-logo og (valgfritt) et Verified Mark Certificate (VMC) fra en godkjent utsteder som DigiCert. VMC koster fra 1500 USD/år, men uten det vil kun noen få e-postklienter vise logoen.
Implementering uten VMC (gratis, begrenset støtte):
Lag en SVG-logo (kvadratisk, max 32 kB, ingen JavaScript). Host den på https://dittdomene.no/logo.svg. Legg til DNS TXT-record:default._bimi.dittdomene.no med verdi:v=BIMI1; l=https://dittdomene.no/logo.svg
Gmail vil ikke vise logoen uten VMC, men Yahoo og noen andre klienter vil. For SMB er dette ofte nok som første steg. Hvis e-post er kritisk for merkevaren din (finans, e-handel), vurder VMC-investeringen.
Hva skjer hvis du ikke implementerer
I praksis? Ingenting dramatisk på kort sikt. E-postene går fortsatt gjennom. Men tre ting forverres sakte:
1. Intercepted meldinger. I fjor rapporterte CISA at statsstøttede grupper aktivt utnytter ukryptert SMTP for å lese bedriftskommunikasjon. MTA-STS hadde stoppet det.
2. Tapt tillit. Kunder ser at konkurrenten din har logo i innboksen, du har ikke. De assosierer det ubevisst med legitimitet. Phishing-kampanjer som spoofinger domenet ditt blir vanskeligere å oppdage uten visuell differensiering.
3. Framtidig regulering. NIS2-direktivet nevner ikke MTA-STS eksplisitt, men krever "tilstrekkelig kryptert kommunikasjon". Tilsynsmyndigheter vil stille spørsmål om hvorfor sensitiv e-post sendes ukryptert når løsningen finnes.
Implementer uten å brekke levering
Feilen de fleste gjør er å aktivere mode: enforce på MTA-STS dag én. Gjør dette i stedet:
Uke 1: Implementer TLS-RPT først. Vent 7 dager, les rapportene. Identifiser legacy-systemer som ikke støtter TLS (ofte gamle printere med scan-to-email, eller interne CRM-er).
Uke 2: Implementer MTA-STS i mode: testing. Fortsett å lese TLS-RPT. Testing-mode blokkerer ingen meldinger, men rapporterer hva som ville blitt blokkert.
Uke 3: Fiks eventuelle TLS-problemer (oppgrader firmware, konfigurer relay-servere). Verifiser at 99%+ av inngående e-post leveres over TLS.
Uke 4: Bytt til mode: enforce. Overvåk TLS-RPT daglig i én uke til. Hvis noe brekker, reverter til testing midlertidig.
Måned 2: Implementer BIMI når MTA-STS har kjørt stabilt i 30 dager. Start uten VMC. Evaluer VMC-investering basert på bransje og e-post-volum.
Verifiser implementeringen
Bruk Sentinels MAILSCAN-verktøy for å sjekke e-post-helsetilstand, inkludert SPF, DKIM og DMARC-status. For MTA-STS og BIMI, test med eksterne verktøy som Hardenize eller CheckTLS.
Send testmeldinger til Gmail og Yahoo. Verifiser at logoen vises (BIMI) og at TLS-RPT-rapporter ankommer innen 24 timer. Hvis du er på Sentinel PLUSS, får du daglig e-post-lekkasje-overvåkning via HIBP, og kan koble det med manuell TLS-RPT-parsing inntil funksjonen rulles ut i dashboardet.
Hva du bør gjøre nå
Start med TLS-RPT i dag. Det tar fem minutter å sette opp DNS-recorden, og rapportene begynner å komme innen 24 timer. Les dem i én uke. Hvis 95 prosent av trafikken allerede kjører over TLS, implementer MTA-STS i testing-mode. Vent to uker, bytt til enforce. Deretter implementer BIMI hvis merkevaresynlighet betyr noe for virksomheten.
Hvis du vil sjekke om e-postadressene i bedriften har vært involvert i kjente datalekkasjer, bruk MAILSCAN for engangs-skanning, eller oppgrader til Sentinel PLUSS for daglig overvåkning mot Have I Been Pwned. MTA-STS stopper angripere som prøver å lese e-posten din i transitt. E-post-lekkasje-overvåkning varsler deg hvis legitimasjonen allerede er ute.