Du har netop skiftet webhost. Hjemmesiden virker, alt ser fint ud - og så opdager du to dage senere, at du ikke har modtaget en eneste e-mail siden flytningen. Kunder har skrevet, samarbejdspartnere har sendt tilbud, og en vigtig ordre er gået tabt. Årsagen er næsten altid den samme: MX-records, der peger det forkerte sted hen.
MX-records er en af de mest kritiske DNS-konfigurationer for et domæne, og alligevel er de den del af DNS-opsætningen, der oftest glemmes ved en migration. Denne artikel forklarer præcis, hvad MX-records er, hvordan de fungerer trin for trin, og hvilke fejl der forårsager de problemer, du oplever.
Hvad er en MX-record?
En MX-record (Mail Exchanger record) er en DNS-post, der fortæller verden, hvilken mailserver der er ansvarlig for at modtage e-mails på vegne af dit domæne. Når nogen sender en e-mail til dig@ditdomæne.dk, slår afsenderens mailserver op i DNS og spørger: "Hvem modtager mail for dette domæne?" Svaret er din MX-record.
MX-records er altså ikke en teknisk detalje - de er fundamentet for al indgående e-mail. Uden en korrekt MX-record er dit domæne reelt ude af stand til at modtage beskeder, uanset hvor godt resten af din opsætning er konfigureret. Du kan læse mere om de øvrige DNS-recordtyper i artiklen DNS-recordtyper forklaret: A, AAAA, CNAME, MX, TXT, NS og mere.
Prioritetstallet - og hvorfor det betyder noget
En MX-record består af to dele: et prioritetstal og et hostnavn på mailserveren. Prioritetstallet afgør, hvilken server der forsøges først. Her gælder en simpel regel: laveste tal = højeste prioritet.
Et typisk setup med primær og backup-server kan se sådan ud:
ditdomæne.dk. MX 10 mail1.udbyder.dk.
ditdomæne.dk. MX 20 mail2.udbyder.dk.Afsenderens mailserver vil altid forsøge den server med lavest prioritetstal først. Kun hvis den er utilgængelig, falder den tilbage på serveren med prioritet 20. Dette giver redundans - men kun hvis begge records peger på fungerende servere. Har du to records med samme prioritetstal, fordeler afsendende servere normalt trafikken tilfældigt mellem dem, hvilket kan bruges til belastningsfordeling.
Prioritetstallet i sig selv stopper ikke mail, men et forkert hostnavn gør. Og det er netop her, fejlene opstår.
Sådan leveres en e-mail trin for trin
Forløbet fra afsender til modtager involverer flere præcise trin, og MX-recorden spiller en central rolle:
Afsender initierer levering: Afsenderens mailserver modtager beskeden og skal nu finde ud af, hvor den skal leveres.
DNS-opslag efter MX-record: Serveren forespørger DNS for domænets MX-records og modtager en liste med mailservere sorteret efter prioritet.
DNS-opslag efter A-record: Mailserveren er angivet som et hostnavn (fx mail.udbyder.dk). Afsenderens server laver nu endnu et DNS-opslag for at finde IP-adressen på det hostnavn.
SMTP-forbindelse etableres: Afsenderens server opretter en forbindelse til modtagerens mailserver på port 25 via SMTP og leverer beskeden.
Kvittering og arkivering: Modtagerens mailserver bekræfter modtagelsen, og e-mailen placeres i den relevante postkasse.
Fejler et enkelt trin i denne kæde - typisk trin 2 eller 3 - ender e-mailen enten i en bounce hos afsender eller i en kø, der aldrig tømmes.
De mest udbredte MX-setups i Danmark
Afhængigt af hvilken e-mailudbyder du bruger, ser dine MX-records typisk sådan ud:
Microsoft 365: MX-records peger på ditdomæne-dk.mail.protection.outlook.com med prioritet 0. Præcis hostnavn varierer og genereres automatisk af Microsoft.
Google Workspace: Fem MX-records der alle peger på Googles servere - aspmx.l.google.com med prioritet 1 er den primære, efterfulgt af fire backup-servere med stigende prioritetstal.
Simply.com: Typisk mail.simply.com med prioritet 10.
One.com: Typisk mx1.one.com og mx2.one.com med henholdsvis prioritet 10 og 20.
DanDomain: Bruger egne mailservere, og MX-records angives i kontrolpanelet ved oprettelse af e-mailkonti.
Fælles for dem alle er, at MX-recorden altid peger på et hostnavn - aldrig direkte på en IP-adresse. Det er ikke blot en konvention, det er et krav i DNS-standarden.
De 5 hyppigste MX-fejl - og hvad de koster dig
MX-record peger på en IP-adresse i stedet for et hostnavn
Dette er en af de mest grundlæggende fejl og skyldes som regel en misforståelse af DNS. En MX-record skal pege på et hostnavn (en A-record), ikke en IP-adresse. Mange mailservere afviser simpelthen leveringsforsøg, når MX-records indeholder en IP, fordi det er i strid med RFC 5321. Resultatet er, at indgående mail bouncer med en kryptisk fejlbesked hos afsender.
MX-record mangler helt
Hvis et domæne slet ingen MX-records har, vil afsendende mailservere som regel falde tilbage på domænets A-record og forsøge at levere mail direkte til hjemmesidens IP-adresse. Denne server kører næsten aldrig en mailserver, og leveringen fejler. Konsekvensen er enten en bounce eller en lang venteperiode, inden afsenders mailserver opgiver og sender en fejlmeddelelse.
Forkert prioritetstal efter flytning
Prioritetstallet i sig selv er sjældent problemet - men det kan skabe forvirring, hvis du har en gammel og en ny record med samme lave prioritet. Afsendende servere vælger da tilfældigt mellem dem, og halvdelen af din indgående mail kan havne hos den forkerte server.
Gammel MX-record fra tidligere udbyder er ikke slettet
Dette er det klassiske migrationsproblem. Du opretter korrekte MX-records hos din nye udbyder, men glemmer at slette den gamle record. Nu har dit domæne to sæt MX-records, der peger på to forskellige mailservere. Noget mail leveres korrekt til den nye server, andet ender hos den gamle - der måske ikke længere har din postkasse. Denne fejl er særligt lumsk, fordi alt tilsyneladende virker.
TTL er så høj at ændringer ikke slår igennem i dagevis
TTL (Time To Live) bestemmer, hvor længe DNS-resolvere rundt om i verden cacher din record. Har din MX-record en TTL på 86400 sekunder (24 timer), kan det tage op til et døgn, før en ændring er fuldt propageret. Har du ikke sænket TTL-værdien i god tid inden en migration - typisk til 300-600 sekunder 24 timer i forvejen - risikerer du, at afsendende servere verden over stadig leverer til den gamle adresse, længe efter du troede problemet var løst.
Sådan tjekker du dine MX-records
Den hurtigste måde at verificere dine MX-records på er via DNSinfos DNS opslag. Indtast dit domænenavn, vælg recordtype "MX", og du får øjeblikkeligt vist alle aktive MX-records med tilhørende prioritetstal og TTL-værdier. Du kan se, om der er gamle records der ikke er slettet, og om hostnavn-formatet er korrekt.
Bruger du Microsoft 365, er DNSinfos Microsoft 365-værktøj særligt relevant. Det tjekker ikke blot dine MX-records, men validerer hele din Microsoft 365-mailopsætning inklusiv SPF, DKIM og Autodiscover - og markerer præcist, hvad der mangler eller er forkert konfigureret. Det sparer dig for at gennemgå hver record manuelt.
Vil du gå et skridt videre og sikre, at din e-mail ikke blot modtages, men også leveres korrekt fra dit domæne, bør du efterfølgende tjekke din SPF-opsætning. SPF-records fortæller modtagerens mailserver, hvilke servere der har lov til at sende på vegne af dit domæne - og en forkert SPF-record kan sende din udgående mail direkte i spam. Læs mere i Sådan fungerer SPF-records, og hvorfor de er vigtige for din e-mail-sikkerhed.
MX-records er forudsætningen for alt andet
Mange webmastere og IT-ansvarlige bruger tid på at konfigurere SPF, DKIM og DMARC - og det er rigtigt og vigtigt. Men ingen af disse mekanismer hjælper, hvis MX-recorden er forkert. De handler om autentificering af e-mail, ikke om leveringsadressen. En forkert MX-record betyder, at e-mailen aldrig ankommer - uanset hvor velpoleret resten af opsætningen er.
Når du skifter webhost, DNS-udbyder eller e-mailplatform, er MX-records det første du skal kontrollere og det sidste du skal ændre - fordi en forkert ændring med høj TTL kan koste dig dages indgående kommunikation. Sænk TTL i god tid, dokumenter dine eksisterende records inden du ændrer noget, og verificer resultatet med et DNS-opslag, inden du erklærer migrationen for færdig.
En korrekt MX-record er ikke blot en teknisk konfiguration. Den er forudsætningen for, at din e-mail overhovedet eksisterer.
