MX-record

Et MX-record er en post i DNS, der angiver, hvilke mailservere der skal modtage e-mail for et domæne. MX står for Mail Exchange. Når nogen sender til navn@firma.dk, slår afsenderens mailsystem domænets MX-poster op for at finde den rigtige modtager.

Posten indeholder normalt et værtsnavn og en prioritet. Eksempelvis kan prioritet 10 pege på mail1.udbyder.dk, mens prioritet 20 peger på en sekundær server. Det laveste tal har normalt højeste prioritet. Hvis den første ikke kan nås, kan afsenderen forsøge den næste.

Et MX-record er ikke en postkasse og gemmer ikke e-mails. Det er en vejviser til den server, der håndterer modtagelsen. Selve postkasser, spamfiltre og regler ligger hos mailudbyderen. MX-posten fortæller blot andre systemer, hvor de skal banke på.

MX hænger sammen med SMTP, som er protokollen mailservere bruger til at overføre beskeder. DNS finder destinationen, og SMTP står for selve samtalen mellem serverne. De to dele skal begge fungere, før en ekstern e-mail når frem.

Webhosting og mail kan sagtens ligge forskellige steder. En virksomheds hjemmeside kan pege på et webhotel, mens MX-poster peger på Microsoft 365 eller Google Workspace. Derfor må en webflytning ikke automatisk overskrive mailposterne.

Få de officielle værdier fra mailudbyderen. Kopiér værtsnavne og prioriteter nøjagtigt. Gæt ikke på mail.domæne.dk, fordi det ser logisk ud. Moderne tjenester bruger ofte specifikke navne, der knytter domænet til deres infrastruktur.

Opret MX-posterne i den autoritative DNS-zone, som styres af domænets nameservere. Det hjælper ikke at ændre poster i et gammelt webhotel, hvis nameserverne peger et andet sted. Kontrollér først, hvilken DNS-udbyder der faktisk svarer.

Brug kun de poster, den aktive mailudbyder kræver. Ved en migration skal gamle og nye poster håndteres efter en plan. Hvis to uafhængige udbydere står med samme prioritet, kan mail blive leveret tilfældigt til den ene eller den anden.

Tilføj også de tilhørende TXT-poster for SPF, DKIM og DMARC efter udbyderens vejledning. De er ikke MX-records, men de hjælper modtagere med at vurdere, om afsendte mails er legitime. En korrekt modtagelsesvej løser ikke automatisk troværdigheden af udgående mail.

Test efter ændringen fra en ekstern konto, ikke kun internt mellem to brugere i samme system. Send fra flere tjenester, svar tilbage, og kontrollér eventuelle fejlmeddelelser. Interne mails kan virke, selv om offentlige MX-poster er forkerte.

Dokumentér dato, gamle værdier, nye værdier og ansvarlig. Hvis migreringen skal rulles tilbage, er det afgørende at vide, hvad der stod før. Et screenshot kan være en hjælp, men en fuld liste er bedre.

En virksomhed flytter fra et almindeligt webhotel til Microsoft 365. Den nye mailudbyder angiver én MX-værdi med prioritet 0. Den gamle zone har to MX-poster til webhotellets mailservere med prioritet 10 og 20.

Administrator tilføjer den nye post, men lader de gamle stå. Fordi den nye har lavest prioritet, går det meste mail korrekt til Microsoft 365. Når den nye server midlertidigt ikke kan kontaktes, forsøger afsendere dog de gamle servere, hvor postkasserne stadig eksisterer som tomme konti.

Nogle beskeder lander derfor i den gamle webmail og bliver ikke set. Fejlen opdages først, da en kunde ringer. De gamle MX-poster fjernes, og de gamle postkasser lukkes efter en kontrolleret overgang. Herefter går alle nye leveringsforsøg til den aktive tjeneste.

Et andet eksempel er et domæne uden MX-poster. Nogle servere kan forsøge domænets A-record som fallback efter ældre regler, men det er ikke en fornuftig moderne opsætning. Brug eksplicitte MX-poster fra mailudbyderen.

Når en ny domæneadresse oprettes til en kampagne, er det derfor ikke nok at købe navnet og lægge en landingsside op. Skal domænet også modtage svar, skal mailtjenesten og dens DNS-poster være etableret.

Den klassiske fejl er at indtaste en IP-adresse direkte i MX-feltet. MX skal pege på et værtsnavn, som selv kan slås op til en adresse. Følg udbyderens værdi i stedet for at omgå strukturen.

En anden fejl er at misforstå prioriteten og tro, at 100 er vigtigere end 10. I MX betyder et lavere tal normalt højere præference. Prioritet bruges til rækkefølge, ikke til at give serveren en kvalitetskarakter.

Pas på DNS-paneler, der automatisk tilføjer domænet. Indtastes et fuldt værtsnavn forkert, kan resultatet blive server.udbyder.dk.firma.dk. Nogle paneler kræver et afsluttende punktum, andre ikke. Kontrollér det offentlige DNS-svar efter gemning.

Endelig kan man fokusere så meget på MX, at afsendelse glemmes. En virksomhed kan modtage fint og stadig få udgående mail i spam på grund af manglende SPF, DKIM, DMARC eller forkert SMTP-opsætning. Maildrift er flere dele.

MX-poster kan have samme prioritet for at fordele eller balancere leveringsforsøg mellem servere, men den konkrete adfærd afhænger af afsendersystemet. Brug kun en sådan opsætning, hvis mailudbyderen beskriver den.

TTL bestemmer, hvor længe DNS-svar kan gemmes i cache. Før en planlagt migration kan en lavere TTL gøre skiftet mere smidigt, men den skal ændres i god tid. Når migreringen er stabil, kan værdien sættes tilbage til et fornuftigt niveau.

Fejlbeskeder fra mailservere indeholder ofte nyttige koder. “Domain not found”, “no MX” og “user unknown” beskriver forskellige problemer. Gem den fulde bounce-besked, når en tekniker skal undersøge leveringen.

Et SSL-certifikat på hjemmesiden sikrer ikke automatisk mailforbindelserne. Mailtjenesten håndterer sine egne certifikater og protokoller. Det fælles domænenavn kan få delene til at se samlet ud, men teknisk er de adskilte.

Vores guide til HTTP og HTTPS forklarer webtrafikkens protokoller. MX og SMTP udfører en anden opgave: at finde og overføre e-mail. Begge dele bruger domænet, men de følger forskellige ruter.

Ved en mailmigration bør gamle postkasser normalt holdes tilgængelige, indtil historiske beskeder er flyttet og alle klienter er opdateret. MX styrer nye leveringer, men flytter ikke indholdet i de gamle postkasser. Det er en separat migrationsopgave.

Split delivery, hvor nogle brugere ligger hos én mailudbyder og andre hos en anden, kræver en bevidst serveropsætning. Det løses ikke ved blot at have to MX-poster. Uden korrekt routing vil afsenderen vælge server efter prioritet, ikke efter hvilken medarbejder der skal have beskeden.

Et domæne, der bevidst ikke skal modtage mail, kan konfigureres med en null MX efter den relevante standard. Det signalerer tydeligt, at der ikke findes en mailserver. Det er bedre end en tilfældig manglende opsætning, men bør kun bruges, når domænet faktisk aldrig skal modtage svar.

Kontrollér også domænets stavemåder og aliaser. Hvis virksomheden bruger både firma.dk og firma.com i e-mailadresser, skal begge domæner have en fungerende mailopsætning eller en klar videresendelse. Ét korrekt MX-record på hoveddomænet hjælper ikke automatisk det andet.

Prioritet betyder ikke automatisk backup i den forstand, virksomheden forventer. Hvis den sekundære server accepterer mail, skal den vide, hvordan beskeden leveres videre til den primære tjeneste. En tilfældig gammel server med højere tal er ikke en brugbar reserve; den kan blot blive et sted, hvor mail samler støv.

Brug DNS-opslagsværktøjer fra flere netværk, hvis en ændring ser forskellig ud. Den lokale computer kan have et gammelt cachet svar, mens offentlig DNS allerede viser det nye. Genstart af mailprogrammet ændrer ikke nødvendigvis den rekursive DNS-cache hos netværket.

Ved domæneændring bør afsenderadresser, svaradresser og aliaser planlægges sammen med MX. Kunder vil fortsat svare på gamle tråde. Behold derfor relevante gamle domæner og mailaliaser i en overgang, så ændringen ikke skaber unødvendige bounces.

Hvis en virksomhed bruger en ekstern spamgateway, kan MX pege på gatewayen frem for den egentlige postkassetjeneste. Gatewayen filtrerer og videresender derefter mailen. Det er endnu en grund til ikke at “rette” værdien ud fra, hvor medarbejderne logger ind.

En webshop er særlig afhængig af stabil mail, fordi ordrebekræftelser og nulstilling af adgangskoder er en del af kundens forløb. MX-fejl kan derfor hurtigt blive et kundeserviceproblem.