Slutt å gjette på DNS-en din: en utviklervennlig gjennomgang av MX, SPF, DKIM og DMARC

Hvorfor DNS-oppføringer for e-post er viktige nå

E-postautentisering pleide å være valgfritt. I 2026 er det en grunnforutsetning. Gmail og Outlook håndhever begge SPF og DKIM for masseutsendere, og DMARC er raskt i ferd med å bli obligatorisk for alle domener som sender transaksjons-e-post. Hvis DNS-oppføringene dine er feil, kommer ikke e-postene dine frem — ingen returmelding, ingen advarsel, bare stillhet.

Problemet er at disse oppføringene er dokumentert som RFC-er, ikke som verktøy. De fleste utviklere kopierer og limer inn eksempler fra oppsettsveiledningen til e-postleverandøren og håper på det beste. Det fungerer helt til du må feilsøke, legge til en ekstra sendetjeneste eller forklare en kunde hvorfor e-postene fra kontaktskjemaet deres havner i søppelpost.

Denne guiden går gjennom MX, SPF, DKIM og DMARC i den rekkefølgen du faktisk vil møte dem, med nok detaljer til å konfigurere dem riktig og nok kontekst til å feilsøke dem når de slutter å fungere.

MX-oppføringer: hvor innkommende e-post skal gå

MX-oppføringer forteller internett hvilke e-postservere som tar imot e-post for domenet ditt. De er de enkleste av de fire, men også de letteste å feilkonfigurere.

En MX-oppføring har to deler: et prioritetsnummer og et vertsnavn. Lavere prioritetsnumre prøves først. Hvis du bruker Google Workspace, kan MX-oppføringene dine se slik ut:

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.

Punktene på slutten er viktige — de viser at vertsnavnet er fullt kvalifisert. De fleste DNS-leverandører legger dem til automatisk, men ikke alle.

Vanlige feil: å peke MX-oppføringer til en A-oppføring i stedet for et vertsnavn, sette alle prioriteter til samme tall (som undergraver poenget med å ha reservealternativer), eller glemme å fjerne gamle MX-oppføringer når du bytter leverandør. Utdaterte MX-oppføringer ligger ikke bare der uten å gjøre skade — de kan forårsake e-postsløyfer eller delt levering på tvers av to innbokser.

Hvis du kjører ditt eget kontaktskjema og vil unngå spam uten å være avhengig av tredjepartstjenester, er å forstå hvordan skjemaer blir spamvektorer et nyttig utgangspunkt.

SPF: hvilke servere som har lov til å sende som deg

SPF (Sender Policy Framework) er en TXT-oppføring som lister IP-adressene og domenene som er autorisert til å sende e-post på vegne av domenet ditt. Det er den første kontrollen de fleste e-postservere utfører når de mottar en melding som hevder å være fra deg.

En enkel SPF-oppføring ser slik ut:

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

Delt opp betyr det:

• v=spf1 deklarerer SPF-versjonen
• include:_spf.google.com delegerer til Googles SPF-oppføring
• ~all er en myk feil — avvis e-post fra kilder som ikke er listet, men ikke vær for streng

Du kan også bruke ip4: eller ip6: for å hviteliste bestemte adresser, eller a og mx for å referere til domenets A- og MX-oppføringer. all-mekanismen på slutten styrer hva som skjer med e-post fra kilder du ikke har listet: -all er en hard feil (avvis), ~all er en myk feil (marker som mistenkelig), ?all er nøytral (ingen mening), og +all er fritt frem (ikke bruk dette).

SPF har to skarpe kanter. For det første bryter det ved videresending av e-post, fordi videresendingsserveren ikke står i SPF-oppføringen din. For det andre har SPF-oppføringer en oppslagsgrense på ti DNS-forespørsler. Hvis du inkluderer for mange tredjepartstjenester, overskrider du grensen, og SPF slutter å fungere. Løsningen er å flate ut SPF-oppføringen — erstatte include:-direktiver med de faktiske IP-områdene — men dette krever vedlikehold når leverandører endrer IP-ene sine.

DKIM: kryptografisk bevis på avsenderidentitet

DKIM (DomainKeys Identified Mail) legger til en digital signatur i utgående e-post. Mottakerserveren sjekker signaturen mot en offentlig nøkkel publisert i DNS-en din. Hvis signaturen er gyldig og meldingen ikke er tuklet med, består DKIM.

I motsetning til SPF overlever DKIM videresending, fordi signaturen følger meldingen. Det er også mer fleksibelt — du kan ha flere DKIM-nøkler for ulike sendetjenester, hver med sin egen selector.

En DKIM DNS-oppføring ser slik ut:

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

Selector-en (default i dette eksemplet) er vilkårlig — e-postleverandøren din velger den. p=-verdien er den offentlige nøkkelen, vanligvis en lang base64-kodet streng. E-postleverandøren din genererer den private nøkkelen og bruker den til å signere utgående meldinger.

DKIM-oppsett håndteres nesten alltid av e-postleverandøren din. Din jobb er å kopiere TXT-oppføringen de gir deg, og lime den inn i DNS-en din. Det vanskelige er at noen DNS-leverandører ikke håndterer lange TXT-oppføringer godt — de enten avkorter dem eller krever at du deler verdien opp i flere siterte strenger.

For å verifisere at DKIM fungerer, send en test-e-post til en Gmail-adresse og sjekk headerne. Se etter dkim=pass i Authentication-Results-headeren.

DMARC: håndheving av policy og rapportering

DMARC (Domain-based Message Authentication, Reporting and Conformance) knytter SPF og DKIM sammen og forteller mottakerservere hva de skal gjøre når autentisering mislykkes. Det aktiverer også rapportering, slik at du kan se hvem som sender e-post som domenet ditt — både legitime avsendere og forfalskede.

En minimal DMARC-oppføring ser slik ut:

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

• p=none betyr bare overvåking — ikke avvis eller sett mislykkede meldinger i karantene
• rua=mailto:[email protected] angir hvor aggregerte rapporter skal sendes

Når du er trygg på at SPF og DKIM fungerer, kan du stramme inn policyen til p=quarantine (send feil til søppelpost) eller p=reject (avvis dem direkte). Du kan også sette en subdomenepolicy med sp= og angi en prosentandel av meldingene policyen skal gjelde for med pct=.

DMARC-rapporter er XML-filer som sendes daglig av store mottakere. De er ordrike og vanskelige å lese rått, men de forteller deg nøyaktig hvilke meldinger som besto eller feilet autentisering, og hvorfor. Hvis du ser at legitim e-post blir avvist, vil rapportene vise hvilken SPF- eller DKIM-kontroll som feiler.

Én fallgruve: DMARC krever samsvar. For SPF må domenet i Return-Path-headeren samsvare med domenet i From-headeren (eller være et subdomene). For DKIM må d=-domenet i DKIM-signaturen samsvare med From-domenet. Hvis du bruker en tredjeparts sendetjeneste, må den støtte egendefinerte returadresser eller DKIM-signering med ditt domene, ikke deres.

Slik reviderer du det nåværende oppsettet ditt

De fleste DNS-problemer er usynlige helt til de skaper et problem. Slik sjekker du oppføringene dine før noe ryker:

1. Spørr MX-oppføringene dine: dig MX example.com skal returnere vertsnavnene og prioritetene til e-postserverne dine. Verifiser at de samsvarer med dokumentasjonen til e-postleverandøren din.

1. Sjekk SPF-syntaks: dig TXT example.com og se etter v=spf1-oppføringen. Kjør den gjennom en SPF-validator for å fange syntaksfeil og brudd på oppslagsgrensen.

1. Verifiser DKIM-nøkler: Send en test-e-post og inspiser DKIM-Signature-headeren. Trekk ut selector og domene, og kjør deretter dig TXT selector._domainkey.example.com for å bekrefte at den offentlige nøkkelen finnes.

1. Valider DMARC-policy: dig TXT _dmarc.example.com skal returnere DMARC-oppføringen din. Sørg for at rua= peker til en adresse du faktisk overvåker.

1. Test ende til ende: Bruk en tjeneste som mail-tester.com eller send til en Gmail-adresse og sjekk de fullstendige headerne. Se etter spf=pass, dkim=pass og dmarc=pass i Authentication-Results-headeren.

Hvis du feilsøker hvorfor e-poster ikke kommer frem, er headerne ditt beste verktøy. De fleste e-postklienter lar deg vise rå headere — i Gmail åpner du meldingen, klikker på de tre prikkene og velger 'Show original'. Authentication-Results-headeren vil fortelle deg nøyaktig hvilken kontroll som feilet, og hvorfor.

Når du bør bruke subdomenepolicyer

Hvis du sender e-post fra flere subdomener — for eksempel newsletter.example.com for markedsføring og app.example.com for transaksjons-e-post — kan du sette DMARC-policyer per subdomene. Dette lar deg håndheve strenge policyer på subdomener du kontrollerer, samtidig som du beholder en løsere policy på hoveddomenet ditt.

Avveiningen er kompleksitet. Hvert subdomene trenger sine egne SPF-, DKIM- og DMARC-oppføringer, og du må holde oversikt over hvilke sendetjenester som er autorisert for hvilke subdomener. For de fleste små team er ett godt konfigurert domene enklere og like sikkert.

Hva du gjør når autentisering slutter å fungere

Den vanligste feilen er å legge til en ny sendetjeneste uten å oppdatere DNS. Hvis du begynner å bruke en ny leverandør for transaksjons-e-post, må du legge til deres SPF-include eller IP-område, konfigurere DKIM-signering med domenet ditt og verifisere DMARC-samsvar.

Det nest vanligste problemet er videresending. Hvis brukere videresender e-posten din til en annen adresse, vil SPF feile fordi videresendingsserveren ikke står i SPF-oppføringen din. DKIM overlever vanligvis videresending, så så lenge DKIM består og DMARC-policyen din tillater delvis samsvar, bør meldingen fortsatt bli levert. Hvis du ser at videresendt e-post blir avvist, sjekk DMARC-policyen din — p=reject med strengt samsvar vil ødelegge videresending.

Det tredje problemet er DNS-propagering. Endringer i DNS-oppføringer kan ta timer å propagere, og ulike e-postservere mellomlagrer oppføringer i ulik tid. Hvis du nettopp har oppdatert en oppføring og den ikke fungerer, vent noen timer og test på nytt. Du kan sjekke propagering med et verktøy som whatsmydns.net.

Viktige punkter

• MX-oppføringer ruter innkommende e-post; SPF, DKIM og DMARC autentiserer utgående e-post. De løser ulike problemer, og du trenger alle fire.
• SPF bryter ved videresending og har en grense på ti oppslag. DKIM overlever videresending, men krever konfigurasjon per tjeneste. DMARC knytter dem sammen og aktiverer rapportering.
• Start med p=none i DMARC, overvåk rapportene i noen uker, og stram deretter inn til p=quarantine eller p=reject når du er trygg på at legitim e-post består.
• DNS-feil er tause. Test konfigurasjonen din med ekte e-post og inspiser headerne for å bekrefte at SPF, DKIM og DMARC består.
• Hvis autentisering slutter å fungere etter at du har lagt til en ny sendetjeneste, sjekk SPF includes, DKIM selectors og DMARC-samsvar. Headerne vil fortelle deg hvilken kontroll som feilet.

FAQ

Q: Kan jeg ha flere SPF-oppføringer?

A: Nei. Flere SPF-oppføringer vil føre til at alle ignoreres. Hvis du må autorisere flere tjenester, bruk include:-direktiver i én enkelt SPF-oppføring, eller list IP-områder direkte. Pass på grensen på ti oppslag.

Q: Trenger jeg DMARC hvis jeg bare sender noen få e-poster om dagen?

A: Ja. DMARC handler ikke om volum — det handler om å bevise at du er den du sier du er. Selv små domener har nytte av DMARC fordi det hindrer spoofing og gir deg innsyn i leveringsproblemer. Start med p=none og en rapporteringsadresse.

Q: Hva skjer hvis både DKIM og SPF feiler, men e-posten ser legitim ut?

A: Det avhenger av DMARC-policyen din. Hvis p=none, leveres e-posten med en advarsel. Hvis p=quarantine, går den til søppelpost. Hvis p=reject, avvises den. Derfor bør du overvåke DMARC-rapporter før du håndhever en streng policy — du kan ha legitime avsendere du ikke visste om.

Q: Kan jeg bruke samme DKIM-nøkkel for flere domener?

A: Teknisk sett ja, men ikke gjør det. Hvert domene bør ha sitt eget DKIM-nøkkelpar. Deling av nøkler gjør rotasjon vanskeligere og øker skadeomfanget hvis en privat nøkkel blir kompromittert.

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

A: Det finnes ingen universell regel, men én gang i året er rimelig for de fleste domener. Hvis du mistenker at en nøkkel er kompromittert, roter umiddelbart. Sørg for å publisere den nye offentlige nøkkelen i DNS før du begynner å signere med den nye private nøkkelen, og la den gamle nøkkelen ligge i DNS i noen dager etter rotasjon for å håndtere forsinket e-post.

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

💡 Prøv dette: Undersøk den publiserte policyen for et hvilket som helst domene med DMARC Lookup for å se hvordan MX-, SPF- og DMARC-oppføringer henger sammen i praksis.

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

Kilder

• RFC 7208: Sender Policy Framework (SPF) — SPF-spesifikasjonen, inkludert syntaksregler og grensen på ti oppslag.
• RFC 6376: DomainKeys Identified Mail (DKIM) — DKIM-spesifikasjonen, som dekker generering og verifisering av signaturer.
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — DMARC-spesifikasjonen, inkludert policysyntaks og format for aggregert rapportering.
• Google Workspace: Prevent spoofing and spam — Praktisk veiledning om SPF-, DKIM- og DMARC-konfigurasjon for Google Workspace-domener.