5 MX-feilkonfigurasjoner som eksponerer bedriftens e-post
MX-records styrer hvor e-post til domenet ditt skal leveres. En feilkonfigurasjon kan åpne for spam, lekkasje eller fullstendig tap av innkommende e-post. Vi viser fem vanlige feil og hvordan du sjekker ditt eget oppsett.
1. Ingen fallback-MX eller feil prioritering
MX-records har et prioritetstall: lavere tall = første valg. Har du kun én MX-post og den serveren er nede, returnerer avsenderens mailserver e-posten som ulevererbar. Mange bedrifter glemmer å legge inn en sekundær MX med høyere prioritet (f.eks. MX 10 for primær, MX 20 for fallback).
Verre: noen setter samme prioritet på alle MX-postene. Da velger avsenderen tilfeldig server, og du mister kontroll på hvilken som mottar hva.
Hvordan sjekke: Kjør dig +short MX dinbedrift.no i terminalen. Du skal se minst to linjer, der første tall er lavere enn andre (f.eks. 10 mail1.dinbedrift.no og 20 mail2.dinbedrift.no). Er det bare én linje, mangler du redundans. Er tallene like, har du kaos.
2. MX peker til CNAME i stedet for A-record
RFC 2181 forbyr at MX-poster peker til et CNAME (alias). Mailservere skal lese MX-en, få et domenavn, og gjøre et nytt oppslag direkte til A- eller AAAA-record. Peker du til et CNAME, bryter noen mailservere kommunikasjonen helt, og e-posten forsvinner uten feilmelding til avsender.
Vi ser dette oftest hos bedrifter som bruker tredjeparts-e-postleverandører (f.eks. Google Workspace, Microsoft 365) og blindt kopierer oppsettet fra en gammel konfigurasjon uten å forstå DNS-strukturen.
Hvordan sjekke: Kjør dig +short MX dinbedrift.no, noter servernavnet (f.eks. mail.dinbedrift.no), deretter dig +short mail.dinbedrift.no. Får du tilbake et annet domenenavn i stedet for en IP-adresse, peker du til CNAME. Rett løsning: MX skal peke til et navn som har direkte A-record.
3. Åpen relay: MX aksepterer e-post til hvem som helst
En åpen relay er en mailserver som mottar og videresender e-post til alle domener, ikke bare ditt eget. Spammere elsker dette: de sender via din server, og mottagerens spamfilter ser at e-posten kom fra en legitim bedrifts-IP. Resultatet er at IP-adressen din havner på blokklister, og plutselig når ingen av dine egne e-poster frem.
Gamle Exchange-servere og feilkonfigurerte Postfix-installasjoner er de vanligste synderne. Noen ganger er relay åpen ved et uhell, f.eks. fordi en integrasjon ba deg «tillate all utgående trafikk» og du tolket det bokstavelig.
Hvordan sjekke: Bruk MXToolbox Open Relay Test (mxtoolbox.com/SuperTool.aspx) eller kjør telnet direkte mot MX-serveren og prøv å sende en test-e-post til et eksternt domene. Får du 250 OK uten autentisering, er relayen åpen. En korrekt konfigurert server skal svare 550 Relaying denied.
4. Utdaterte eller glemte MX-records fra gammel leverandør
Bedriften byttet e-postleverandør for to år siden, men gamle MX-poster ligger fortsatt i DNS med lavere prioritet enn de nye. Plutselig kommer det klager på at e-post forsvinner sporadisk. Det som skjer: noen avsendere treffer den gamle, nedlagte serveren, og e-posten går i en digital sort hull.
Vi så en kunde som hadde tre MX-poster, én til Office 365 (prioritet 10), én til en nedlagt intern Exchange (prioritet 20), og én til et gammelt webhotell (prioritet 30). Rundt fem prosent av e-postene havnet hos den døde Exchange-serveren, fordi avsendernes mailsystemer prøvde fallback når Office 365 var treg.
Hvordan sjekke: List alle MX-postene med dig MX dinbedrift.no. Kjenn du igjen alle servernavnene? Hvis ikke, slett dem. Behold kun de som faktisk mottar e-post for deg nå. Test at hver server svarer med telnet server.navn 25, får du 220-svar, er den live. Ingen respons? Slett MX-posten.
5. Manglende SPF, DKIM og DMARC, ikke MX-feil, men like kritisk
MX styrer innkommende e-post. SPF, DKIM og DMARC beskytter utgående e-post mot forfalskning. Har du ikke disse, kan hvem som helst sende e-post som later som den kommer fra ditt domene. Mottagerens mailserver ser ingen MX-feil, men spamfilteret roper «phishing» og sender alt til søppel.
Av de tolv domenene vi overvåker ser syv enten ingen DMARC-policy eller en så slapp policy at den ikke stopper forfalskning. SPF-records er ofte der, men feilkonfigurert med for mange oppslag (DNS-limit er 10) eller manglende -all på slutten.
Hvordan sjekke: Kjør dig +short TXT dinbedrift.no og se etter linjer som starter med v=spf1 (SPF) og v=DMARC1 (DMARC). DKIM-signaturer sjekkes ved å sende en test-e-post til deg selv og se på headers. Sentinel har HEADERSCAN-verktøyet som automatisk leser SPF/DKIM/DMARC-status fra en e-post-header du limer inn.
Test ditt eget MX-oppsett nå
Du trenger ikke å være DNS-ekspert for å finne disse feilene. Start med:
dig MX dinbedrift.no, list alle MX-posterdig A [servernavn]for hver MX, bekreft at de peker til IP, ikke CNAME- MXToolbox SuperTool (gratis), kjør full DNS-rapport
- Telnet-test mot port 25 på hver MX, se at den svarer
220 - Send test-e-post til mail-tester.com, får du score under 8/10, har du feil
Sentinel PLUSS gir deg daglig overvåkning av domenets DNS-records, inkludert MX, SPF, DKIM, DMARC, DNSSEC og CAA. Endrer noen en MX-post uten din viten, varsler vi deg samme dag. Du kan også bruke HEADERSCAN til å analysere e-post-headers og bekrefte at SPF/DKIM/DMARC-sjekker passerer.
MX-feil oppdages sjelden før e-post allerede har forsvunnet. Da er skaden skjedd. Kjør en sjekk i dag, ikke når kunden ringer og sier «jeg sendte en viktig kontrakt for tre dager siden, har du ikke fått den?»