Sluta gissa om din DNS: en utvecklarvänlig genomgång av MX, SPF, DKIM och DMARC

Varför DNS-poster för e-post spelar roll nu

E-postautentisering brukade vara valfri. År 2026 är det ett grundkrav. Gmail och Outlook kräver båda SPF och DKIM för massutskickare, och DMARC håller snabbt på att bli obligatoriskt för alla domäner som skickar transaktionsmejl. Om dina DNS-poster är fel kommer dina mejl inte fram — ingen studs, ingen varning, bara tystnad.

Problemet är att de här posterna är dokumenterade som RFC:er, inte som verktyg. De flesta utvecklare kopierar och klistrar in exempel från e-postleverantörens installationsguide och hoppas på det bästa. Det fungerar tills du behöver felsöka, lägga till en andra utskickstjänst eller förklara för en kund varför mejl från deras kontaktformulär hamnar i skräpposten.

Den här guiden går igenom MX, SPF, DKIM och DMARC i den ordning du faktiskt stöter på dem, med tillräckligt mycket detaljer för att konfigurera dem korrekt och tillräckligt mycket sammanhang för att felsöka dem när de går sönder.

MX-poster: vart inkommande e-post går

MX-poster talar om för internet vilka mailservrar som tar emot e-post för din domän. De är de enklaste av de fyra, men också de lättaste att konfigurera fel.

En MX-post har två delar: ett prioritetsnummer och ett värdnamn. Lägre prioritetsnummer provas först. Om du använder Google Workspace kan dina MX-poster se ut så här:

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.

Punkterna på slutet spelar roll — de signalerar att värdnamnet är fullständigt kvalificerat. De flesta DNS-leverantörer lägger till dem automatiskt, men inte alla.

Vanliga misstag: att peka MX-poster mot en A-post i stället för ett värdnamn, att sätta samma prioritet på alla poster (vilket motverkar syftet med reserver) eller att glömma ta bort gamla MX-poster när du migrerar mellan leverantörer. Inaktuella MX-poster ligger inte bara där utan att göra skada — de kan orsaka e-postloopar eller dela leveransen mellan två inkorgar.

Om du driver ditt eget kontaktformulär och vill undvika skräppost utan att förlita dig på tredjepartstjänster är att förstå hur formulär blir vektorer för skräppost en bra utgångspunkt.

SPF: vilka servrar får skicka som du

SPF (Sender Policy Framework) är en TXT-post som listar de IP-adresser och domäner som har behörighet att skicka e-post för din domäns räkning. Det är den första kontrollen de flesta mailservrar gör när de tar emot ett meddelande som påstår sig komma från dig.

En grundläggande SPF-post ser ut så här:

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

Uppdelat:

• v=spf1 anger SPF-versionen
• include:_spf.google.com delegerar till Googles SPF-post
• ~all är ett soft fail — avvisa e-post från källor som inte är listade, men var inte för strikt

Du kan också använda ip4: eller ip6: för att vitlista specifika adresser, eller a och mx för att hänvisa till din domäns A- och MX-poster. Mekanismen all i slutet styr vad som händer med e-post från källor du inte har listat: -all är ett hard fail (avvisa), ~all är soft fail (markera som misstänkt), ?all är neutralt (ingen åsikt) och +all är fritt fram för alla (använd inte detta).

SPF har två vassa kanter. För det första går det sönder när e-post vidarebefordras, eftersom den vidarebefordrande servern inte finns i din SPF-post. För det andra har SPF-poster en uppslagsgräns på tio DNS-frågor. Om du inkluderar för många tredjepartstjänster överskrider du gränsen och SPF slutar fungera. Lösningen är att platta ut din SPF-post — ersätt include:-direktiv med de faktiska IP-intervallen — men det kräver underhåll när leverantörer ändrar sina IP-adresser.

DKIM: kryptografiskt bevis på avsändaridentitet

DKIM (DomainKeys Identified Mail) lägger till en digital signatur i din utgående e-post. Den mottagande servern kontrollerar signaturen mot en publik nyckel som publicerats i din DNS. Om signaturen är giltig och meddelandet inte har manipulerats passerar DKIM.

Till skillnad från SPF överlever DKIM vidarebefordran, eftersom signaturen följer med meddelandet. Det är också mer flexibelt — du kan ha flera DKIM-nycklar för olika utskickstjänster, var och en med sin egen selector.

En DKIM DNS-post ser ut så här:

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

Selectorn (default i det här exemplet) är godtycklig — din e-postleverantör väljer den. Värdet p= är den publika nyckeln, vanligtvis en lång base64-kodad sträng. Din e-postleverantör genererar den privata nyckeln och använder den för att signera utgående meddelanden.

DKIM-konfiguration hanteras nästan alltid av din e-postleverantör. Din uppgift är att kopiera TXT-posten de ger dig och klistra in den i din DNS. Det knepiga är att vissa DNS-leverantörer inte hanterar långa TXT-poster särskilt bra — de trunkerar dem antingen eller kräver att du delar upp värdet i flera citerade strängar.

För att verifiera att DKIM fungerar, skicka ett testmejl till en Gmail-adress och kontrollera headers. Leta efter dkim=pass i headern Authentication-Results.

DMARC: policytillämpning och rapportering

DMARC (Domain-based Message Authentication, Reporting and Conformance) binder ihop SPF och DKIM och talar om för mottagande servrar vad de ska göra när autentisering misslyckas. Det aktiverar också rapportering, så att du kan se vem som skickar e-post som din domän — både legitimt och förfalskat.

En minimal DMARC-post ser ut så här:

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

• p=none betyder endast övervakning — avvisa eller sätt inte misslyckade meddelanden i karantän
• rua=mailto:[email protected] anger vart aggregerade rapporter ska skickas

När du är säker på att SPF och DKIM fungerar kan du skärpa policyn till p=quarantine (skicka misslyckanden till skräppost) eller p=reject (studsa dem direkt). Du kan också ange en policy för underdomäner med sp= och specificera vilken procentandel av meddelanden policyn ska tillämpas på med pct=.

DMARC-rapporter är XML-filer som skickas dagligen av stora mottagare. De är utförliga och svåra att läsa råa, men de talar om exakt vilka meddelanden som klarade eller misslyckades med autentisering och varför. Om du ser legitim e-post avvisas visar rapporterna vilken SPF- eller DKIM-kontroll som misslyckas.

En hake: DMARC kräver alignment. För SPF måste domänen i headern Return-Path matcha domänen i headern From (eller vara en underdomän). För DKIM måste domänen d= i DKIM-signaturen matcha From-domänen. Om du använder en tredjepartstjänst för utskick måste den stödja anpassade return paths eller DKIM-signering med din domän, inte sin egen.

Så granskar du din nuvarande konfiguration

De flesta DNS-problem är osynliga tills de orsakar ett fel. Så här kontrollerar du dina poster innan något går sönder:

1. Fråga dina MX-poster: dig MX example.com bör returnera dina mailservrars värdnamn och prioriteter. Kontrollera att de matchar e-postleverantörens dokumentation.

1. Kontrollera SPF-syntax: dig TXT example.com och leta efter posten v=spf1. Kör den genom en SPF-validator för att fånga syntaxfel och överträdelser av uppslagsgränsen.

1. Verifiera DKIM-nycklar: Skicka ett testmejl och inspektera headern DKIM-Signature. Extrahera selectorn och domänen, fråga sedan dig TXT selector._domainkey.example.com för att bekräfta att den publika nyckeln finns.

1. Validera DMARC-policy: dig TXT _dmarc.example.com bör returnera din DMARC-post. Se till att rua= pekar på en adress du faktiskt bevakar.

1. Testa från början till slut: Använd en tjänst som mail-tester.com eller skicka till en Gmail-adress och kontrollera alla headers. Leta efter spf=pass, dkim=pass och dmarc=pass i headern Authentication-Results.

Om du felsöker varför mejl inte kommer fram är headers ditt bästa verktyg. De flesta e-postklienter låter dig visa råa headers — i Gmail öppnar du meddelandet, klickar på de tre punkterna och väljer ”Visa original”. Headern Authentication-Results talar om exakt vilken kontroll som misslyckades och varför.

När du ska använda policyer för underdomäner

Om du skickar e-post från flera underdomäner — säg newsletter.example.com för marknadsföring och app.example.com för transaktionsmejl — kan du ange DMARC-policyer per underdomän. Det låter dig tillämpa strikta policyer på underdomäner du kontrollerar, samtidigt som du behåller en lösare policy på huvuddomänen.

Avvägningen är komplexitet. Varje underdomän behöver sina egna SPF-, DKIM- och DMARC-poster, och du behöver hålla reda på vilka utskickstjänster som är auktoriserade för vilka underdomäner. För de flesta små team är en enda välkonfigurerad domän enklare och lika säker.

Vad du gör när autentisering går sönder

Det vanligaste felet är att lägga till en ny utskickstjänst utan att uppdatera DNS. Om du börjar använda en ny leverantör för transaktionsmejl måste du lägga till deras SPF-include eller IP-intervall, konfigurera DKIM-signering med din domän och verifiera DMARC-alignment.

Det näst vanligaste problemet är vidarebefordran. Om användare vidarebefordrar din e-post till en annan adress misslyckas SPF eftersom den vidarebefordrande servern inte finns i din SPF-post. DKIM överlever vanligtvis vidarebefordran, så så länge DKIM passerar och din DMARC-policy tillåter partiell alignment bör meddelandet fortfarande levereras. Om du ser vidarebefordrad e-post avvisas, kontrollera din DMARC-policy — p=reject med strikt alignment kommer att bryta vidarebefordran.

Det tredje problemet är DNS-propagation. Ändringar av DNS-poster kan ta timmar att spridas, och olika mailservrar cachar poster olika länge. Om du precis har uppdaterat en post och den inte fungerar, vänta några timmar och testa igen. Du kan kontrollera propagation med ett verktyg som whatsmydns.net.

Viktiga slutsatser

• MX-poster dirigerar inkommande e-post; SPF, DKIM och DMARC autentiserar utgående e-post. De löser olika problem och du behöver alla fyra.
• SPF går sönder vid vidarebefordran och har en gräns på tio uppslag. DKIM överlever vidarebefordran men kräver konfiguration per tjänst. DMARC binder ihop dem och möjliggör rapportering.
• Börja med p=none i DMARC, övervaka rapporterna i några veckor och skärp sedan till p=quarantine eller p=reject när du är säker på att legitim e-post passerar.
• DNS-fel är tysta. Testa din konfiguration med riktig e-post och inspektera headers för att bekräfta att SPF, DKIM och DMARC passerar.
• Om autentisering går sönder efter att du har lagt till en ny utskickstjänst, kontrollera SPF-includes, DKIM-selectors och DMARC-alignment. Headers talar om vilken kontroll som misslyckades.

FAQ

Q: Kan jag ha flera SPF-poster?

A: Nej. Flera SPF-poster gör att alla ignoreras. Om du behöver auktorisera flera tjänster, använd include:-direktiv i en enda SPF-post eller lista IP-intervall direkt. Håll koll på gränsen på tio uppslag.

Q: Behöver jag DMARC om jag bara skickar några få mejl om dagen?

A: Ja. DMARC handlar inte om volym — det handlar om att bevisa att du är den du säger att du är. Även små domäner har nytta av DMARC eftersom det förhindrar spoofing och ger dig insyn i leveransproblem. Börja med p=none och en rapporteringsadress.

Q: Vad händer om DKIM och SPF båda misslyckas men mejlet ser legitimt ut?

A: Det beror på din DMARC-policy. Om p=none levereras mejlet med en varning. Om p=quarantine hamnar det i skräpposten. Om p=reject studsas det. Det är därför du bör övervaka DMARC-rapporter innan du inför en strikt policy — du kan ha legitima avsändare som du inte kände till.

Q: Kan jag använda samma DKIM-nyckel för flera domäner?

A: Tekniskt sett ja, men gör det inte. Varje domän bör ha sitt eget DKIM-nyckelpar. Att dela nycklar gör rotation svårare och ökar konsekvensområdet om en privat nyckel komprometteras.

Q: Hur ofta bör jag rotera DKIM-nycklar?

A: Det finns ingen universell regel, men en gång per år är rimligt för de flesta domäner. Om du misstänker att en nyckel har komprometterats, rotera omedelbart. Se till att publicera den nya publika nyckeln i DNS innan du börjar signera med den nya privata nyckeln, och lämna den gamla nyckeln i DNS i några dagar efter rotationen för att hantera försenad e-post.

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

💡 Prova detta: Granska den publicerade policyn för valfri domän med DMARC Lookup för att se hur MX-, SPF- och DMARC-poster hänger ihop i praktiken.

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

Källor

• RFC 7208: Sender Policy Framework (SPF) — SPF-specifikationen, inklusive syntaxregler och gränsen på tio uppslag.
• RFC 6376: DomainKeys Identified Mail (DKIM) — DKIM-specifikationen, som täcker generering och verifiering av signaturer.
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — DMARC-specifikationen, inklusive policysyntax och format för aggregerad rapportering.
• Google Workspace: Prevent spoofing and spam — Praktisk vägledning om SPF-, DKIM- och DMARC-konfiguration för Google Workspace-domäner.