Stop med at gætte på din DNS: en udviklervenlig gennemgang af MX, SPF, DKIM og DMARC

Hvorfor DNS-records til e-mail betyder noget nu

E-mailgodkendelse plejede at være valgfrit. I 2026 er det et grundkrav. Gmail og Outlook håndhæver begge SPF og DKIM for masseafsendere, og DMARC er hurtigt ved at blive obligatorisk for ethvert domæne, der sender transaktionsmail. Hvis dine DNS-records er forkerte, når dine e-mails ikke frem—ingen bounce, ingen advarsel, kun stilhed.

Problemet er, at disse records er dokumenteret som RFC'er, ikke som værktøjer. De fleste udviklere copy-paster eksempler fra deres e-mailudbyders opsætningsguide og håber på det bedste. Det virker, indtil du skal fejlfinde, tilføje en anden afsendelsestjeneste eller forklare en kunde, hvorfor e-mails fra deres kontaktformular ender i spam.

Denne guide gennemgår MX, SPF, DKIM og DMARC i den rækkefølge, du faktisk møder dem, med nok detaljer til at konfigurere dem korrekt og nok kontekst til at debugge dem, når de går i stykker.

MX-records: hvor indgående e-mail sendes hen

MX-records fortæller internettet, hvilke mailservere der modtager e-mail for dit domæne. De er de enkleste af de fire, men også de letteste at fejlkonfigurere.

En MX-record har to dele: et prioritetsnummer og et hostname. Lavere prioritetsnumre prøves først. Hvis du bruger Google Workspace, kan dine MX-records se sådan ud:

example.com.  MX  1  aspmx.l.google.com.
example.com.  MX  5  alt1.aspmx.l.google.com.
example.com.  MX  5  alt2.aspmx.l.google.com.

De afsluttende punktummer betyder noget—de signalerer, at hostnamet er fuldt kvalificeret. De fleste DNS-udbydere tilføjer dem automatisk, men ikke alle.

Almindelige fejl: at pege MX-records på en A-record i stedet for et hostname, at sætte alle prioriteter til samme tal (hvilket underminerer formålet med backups), eller at glemme at fjerne gamle MX-records, når du migrerer udbyder. Forældede MX-records ligger ikke bare der uden at gøre skade—de kan forårsage mail-loops eller delt levering på tværs af to indbakker.

Hvis du driver din egen kontaktformular og vil undgå spam uden at være afhængig af tredjepartstjenester, er det at forstå, hvordan formularer bliver spamvektorer et nyttigt udgangspunkt.

SPF: hvilke servere må sende som dig

SPF (Sender Policy Framework) er en TXT-record, der oplister de IP-adresser og domæner, som er autoriseret til at sende e-mail på vegne af dit domæne. Det er den første kontrol, de fleste mailservere udfører, når de modtager en besked, der hævder at komme fra dig.

En grundlæggende SPF-record ser sådan ud:

v=spf1 include:_spf.google.com ~all

Delt op:

• v=spf1 angiver SPF-versionen
• include:_spf.google.com delegerer til Googles SPF-record
• ~all er et soft fail—afvis mail fra kilder, der ikke er angivet, men vær ikke for streng

Du kan også bruge ip4: eller ip6: til at whitelist’e specifikke adresser, eller a og mx til at referere til dit domænes A- og MX-records. all-mekanismen til sidst styrer, hvad der sker med mail fra kilder, du ikke har angivet: -all er et hard fail (afvis), ~all er soft fail (markér som mistænkelig), ?all er neutral (ingen holdning), og +all er frit slag (brug ikke dette).

SPF har to skarpe kanter. For det første går det i stykker, når e-mail videresendes, fordi videresendelsesserveren ikke står i din SPF-record. For det andet har SPF-records en grænse på ti DNS-opslag. Hvis du inkluderer for mange tredjepartstjenester, overskrider du grænsen, og SPF holder op med at virke. Løsningen er at udflade din SPF-record—erstatte include:-direktiver med de faktiske IP-intervaller—men det kræver vedligeholdelse, når udbydere ændrer deres IP'er.

DKIM: kryptografisk bevis for afsenderidentitet

DKIM (DomainKeys Identified Mail) tilføjer en digital signatur til din udgående e-mail. Den modtagende server kontrollerer signaturen mod en offentlig nøgle, der er publiceret i din DNS. Hvis signaturen er gyldig, og beskeden ikke er blevet manipuleret, består DKIM.

I modsætning til SPF overlever DKIM videresendelse, fordi signaturen følger med beskeden. Det er også mere fleksibelt—du kan have flere DKIM-nøgler til forskellige afsendelsestjenester, hver med sin egen selector.

En DKIM DNS-record ser sådan ud:

default._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

Selectoren (default i dette eksempel) er vilkårlig—din e-mailudbyder vælger den. p=-værdien er den offentlige nøgle, normalt en lang base64-kodet streng. Din e-mailudbyder genererer den private nøgle og bruger den til at signere udgående beskeder.

DKIM-opsætning håndteres næsten altid af din e-mailudbyder. Din opgave er at kopiere den TXT-record, de giver dig, og indsætte den i din DNS. Det vanskelige er, at nogle DNS-udbydere ikke håndterer lange TXT-records godt—de afkorter dem enten eller kræver, at du opdeler værdien i flere citerede strenge.

For at verificere, at DKIM virker, skal du sende en testmail til en Gmail-adresse og tjekke headerne. Kig efter dkim=pass i Authentication-Results-headeren.

DMARC: håndhævelse af politik og rapportering

DMARC (Domain-based Message Authentication, Reporting and Conformance) binder SPF og DKIM sammen og fortæller modtagende servere, hvad de skal gøre, når godkendelse fejler. Det aktiverer også rapportering, så du kan se, hvem der sender e-mail som dit domæne—både legitime og spoofede afsendere.

En minimal DMARC-record ser sådan ud:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• p=none betyder kun overvågning—afvis eller sæt ikke fejlede beskeder i karantæne
• rua=mailto:[email protected] angiver, hvor aggregerede rapporter skal sendes hen

Når du er sikker på, at SPF og DKIM virker, kan du stramme politikken til p=quarantine (send fejl til spam) eller p=reject (bounce dem direkte). Du kan også sætte en subdomænepolitik med sp= og angive en procentdel af beskeder, som politikken skal anvendes på, med pct=.

DMARC-rapporter er XML-filer, der sendes dagligt af større modtagere. De er udførlige og svære at læse råt, men de fortæller dig præcist, hvilke beskeder der bestod eller fejlede godkendelse, og hvorfor. Hvis du ser legitim mail blive afvist, viser rapporterne dig, hvilken SPF- eller DKIM-kontrol der fejler.

En faldgrube: DMARC kræver alignment. For SPF skal domænet i Return-Path-headeren matche domænet i From-headeren (eller være et subdomæne). For DKIM skal d=-domænet i DKIM-signaturen matche From-domænet. Hvis du bruger en tredjeparts afsendelsestjeneste, skal den understøtte brugerdefinerede return paths eller DKIM-signering med dit domæne, ikke deres.

Sådan auditerer du din nuværende opsætning

De fleste DNS-problemer er usynlige, indtil de skaber et problem. Sådan tjekker du dine records, før noget går i stykker:

1. Forespørg dine MX-records: dig MX example.com bør returnere dine mailserveres hostnames og prioriteter. Kontrollér, at de matcher din e-mailudbyders dokumentation.

1. Tjek SPF-syntaks: dig TXT example.com og kig efter v=spf1-recorden. Kør den gennem en SPF-validator for at fange syntaksfejl og overtrædelser af grænsen for opslag.

1. Verificér DKIM-nøgler: Send en testmail, og inspicér DKIM-Signature-headeren. Udtræk selector og domæne, og forespørg derefter dig TXT selector._domainkey.example.com for at bekræfte, at den offentlige nøgle findes.

1. Validér DMARC-politik: dig TXT _dmarc.example.com bør returnere din DMARC-record. Sørg for, at rua= peger på en adresse, du faktisk overvåger.

1. Test end-to-end: Brug en tjeneste som mail-tester.com, eller send til en Gmail-adresse og tjek de fulde headers. Kig efter spf=pass, dkim=pass og dmarc=pass i Authentication-Results-headeren.

Hvis du debugger, hvorfor e-mails ikke når frem, er headerne dit bedste værktøj. De fleste mailklienter lader dig se rå headers—I Gmail skal du åbne beskeden, klikke på de tre prikker og vælge 'Vis original'. Authentication-Results-headeren fortæller dig præcist, hvilken kontrol der fejlede, og hvorfor.

Hvornår du skal bruge subdomænepolitikker

Hvis du sender e-mail fra flere subdomæner—f.eks. newsletter.example.com til marketing og app.example.com til transaktionsmail—kan du sætte DMARC-politikker pr. subdomæne. Det lader dig håndhæve strenge politikker på subdomæner, du kontrollerer, mens du holder en mere lempelig politik på dit hoveddomæne.

Afvejningen er kompleksitet. Hvert subdomæne har brug for sine egne SPF-, DKIM- og DMARC-records, og du skal holde styr på, hvilke afsendelsestjenester der er autoriseret for hvilke subdomæner. For de fleste små teams er ét velkonfigureret domæne enklere og lige så sikkert.

Hvad du skal gøre, når godkendelse går i stykker

Den mest almindelige fejltilstand er at tilføje en ny afsendelsestjeneste uden at opdatere DNS. Hvis du begynder at bruge en ny udbyder af transaktionsmail, skal du tilføje deres SPF-include eller IP-interval, konfigurere DKIM-signering med dit domæne og verificere DMARC-alignment.

Det næstmest almindelige problem er videresendelse. Hvis brugere videresender din e-mail til en anden adresse, fejler SPF, fordi videresendelsesserveren ikke står i din SPF-record. DKIM overlever normalt videresendelse, så så længe DKIM består, og din DMARC-politik tillader delvis alignment, bør beskeden stadig blive leveret. Hvis du ser videresendt mail blive afvist, skal du tjekke din DMARC-politik—p=reject med strict alignment vil ødelægge videresendelse.

Det tredje problem er DNS-propagation. Ændringer i DNS-records kan tage timer om at propagere, og forskellige mailservere cacher records i forskellige tidsrum. Hvis du lige har opdateret en record, og den ikke virker, så vent et par timer og test igen. Du kan tjekke propagation med et værktøj som whatsmydns.net.

Vigtige pointer

• MX-records router indgående mail; SPF, DKIM og DMARC godkender udgående mail. De løser forskellige problemer, og du har brug for alle fire.
• SPF går i stykker ved videresendelse og har en grænse på ti opslag. DKIM overlever videresendelse, men kræver konfiguration pr. tjeneste. DMARC binder dem sammen og aktiverer rapportering.
• Start med p=none i DMARC, overvåg rapporterne i et par uger, og stram derefter til p=quarantine eller p=reject, når du er sikker på, at legitim mail består.
• DNS-fejl er tavse. Test din konfiguration med rigtig e-mail, og inspicér headerne for at bekræfte, at SPF, DKIM og DMARC består.
• Hvis godkendelse går i stykker efter tilføjelse af en ny afsendelsestjeneste, skal du tjekke SPF-includes, DKIM-selectors og DMARC-alignment. Headerne fortæller dig, hvilken kontrol der fejlede.

FAQ

Q: Kan jeg have flere SPF-records?

A: Nej. Flere SPF-records vil få dem alle til at blive ignoreret. Hvis du skal autorisere flere tjenester, skal du bruge include:-direktiver i én enkelt SPF-record eller angive IP-intervaller direkte. Hold øje med grænsen på ti opslag.

Q: Har jeg brug for DMARC, hvis jeg kun sender få e-mails om dagen?

A: Ja. DMARC handler ikke om volumen—det handler om at bevise, at du er den, du siger, du er. Selv små domæner har gavn af DMARC, fordi det forhindrer spoofing og giver dig indsigt i leveringsproblemer. Start med p=none og en rapporteringsadresse.

Q: Hvad sker der, hvis både DKIM og SPF fejler, men e-mailen ser legitim ud?

A: Det afhænger af din DMARC-politik. Hvis p=none, leveres mailen med en advarsel. Hvis p=quarantine, ryger den i spam. Hvis p=reject, bliver den bounced. Derfor bør du overvåge DMARC-rapporter, før du håndhæver en streng politik—du kan have legitime afsendere, du ikke kendte til.

Q: Kan jeg bruge den samme DKIM-nøgle til flere domæner?

A: Teknisk set ja, men lad være. Hvert domæne bør have sit eget DKIM-nøglepar. Deling af nøgler gør rotation sværere og øger skadesomfanget, hvis en privat nøgle kompromitteres.

Q: Hvor ofte bør jeg rotere DKIM-nøgler?

A: Der er ingen universel regel, men én gang om året er rimeligt for de fleste domæner. Hvis du mistænker, at en nøgle er blevet kompromitteret, skal du rotere med det samme. Sørg for at publicere den nye offentlige nøgle i DNS, før du begynder at signere med den nye private nøgle, og lad den gamle nøgle blive i DNS i nogle dage efter rotationen for at håndtere forsinket mail.

<!-- tool-cta:start -->

💡 Prøv dette: Undersøg et vilkårligt domænes offentliggjorte politik med DMARC Lookup for at se, hvordan MX-, SPF- og DMARC-poster hænger sammen i praksis.

<!-- tool-cta:end -->

Kilder

• RFC 7208: Sender Policy Framework (SPF) — SPF-specifikationen, inklusive syntaksregler og grænsen på ti opslag.
• RFC 6376: DomainKeys Identified Mail (DKIM) — DKIM-specifikationen, som dækker generering og verifikation af signaturer.
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — DMARC-specifikationen, inklusive politisk syntaks og format for aggregeret rapportering.
• Google Workspace: Prevent spoofing and spam — Praktisk vejledning i konfiguration af SPF, DKIM og DMARC for Google Workspace-domæner.