SPF, DKIM och DMARC är tre DNS-poster som avgör två saker: om e-posten du skickar hamnar i inkorgen, och om någon annan kan skicka e-post som ser ut att komma från dig. Gmail, Yahoo och Outlook.com kräver numera alla tre av alla som skickar e-post i stora volymer, och meddelanden utan dem hamnar oftare i skräpposten även för alla andra.
Posterna är korta, men det är lätt att få till små fel i dem, och de slutar fungera utan förvarning när ett nytt verktyg börjar skicka e-post åt dig. Den här guiden förklarar vad var och en gör, hur du sätter upp dem i rätt ordning och hur du ser till att de fortsätter fungera.
Så hänger de ihop
Varje e-postmeddelande har två avsändaradresser: kuvertavsändaren, som e-postservrar använder för att skicka tillbaka studsar, och From-adressen som mottagaren ser. Bedrägerier bygger på glappet mellan dem: vem som helst kan skriva vilken From-adress som helst. De tre posterna täpper till det glappet.
SPF (Sender Policy Framework) listar de servrar som får skicka e-post för din domän.
DKIM (DomainKeys Identified Mail) lägger till en kryptografisk signatur i varje meddelande, som mottagaren verifierar mot en publik nyckel i din DNS.
DMARC (Domain-based Message Authentication, Reporting and Conformance) knyter dem till den synliga From-adressen och talar om för mottagarna vad de ska göra med e-post som inte klarar kontrollen.
SPF: vem som får skicka
En SPF-post är en TXT-post på din domän. Den listar de tjänster och servrar som skickar e-post åt dig och avslutas med vad som ska hända med allt annat:
example.com. TXT ”v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.25 ~all”
include: lägger till en annan domäns SPF-post, det vanliga sättet att godkänna en e-posttjänst.
ip4: och ip6: godkänner specifika adresser, till exempel din egen e-postserver.
~all (soft fail) eller -all (fail) anger vad som händer med alla som inte finns med. Använd aldrig +all, som godkänner hela internet.
Två regler är det som fäller de flesta domäner:
Bara en post. En domän får ha exakt en SPF-post. Med två returnerar mottagarna ett permanent fel och SPF misslyckas för varje meddelande. När en ny tjänst ber dig att ”lägga till den här SPF-posten” lägger du i stället till dess include i den post du redan har.
Högst 10 DNS-uppslag. Varje include, a, mx och redirect kostar ett uppslag, och include inuti include räknas också. Över 10 misslyckas SPF. En post med Google Workspace, ett nyhetsbrevsverktyg, ett CRM och ett supportsystem kan passera gränsen utan att någon märker det.
SPF har en svaghet: det kontrollerar kuvertavsändaren, inte From-adressen som mottagaren ser, och det slutar fungera när e-post vidarebefordras. Därför räcker det inte ensamt.
DKIM: en signatur på varje meddelande
Med DKIM signerar din e-posttjänst varje meddelande med en privat nyckel. Den publika nyckeln ligger i DNS, under ett namn som kallas selector:
google._domainkey.example.com. TXT ”v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC…”
Mottagaren läser selectorn från meddelandets DKIM-Signature-huvud, slår upp nyckeln och kontrollerar att meddelandet inte har ändrats på vägen. En DKIM-signatur klarar vidarebefordran, vilket gör den till den mer pålitliga av de två.
Varje tjänst som skickar åt dig behöver en egen DKIM-konfiguration, oftast i tjänstens administrationsinställningar under ”autentisering” eller ”verifierad domän”. Använd 2048-bitarsnycklar där tjänsten erbjuder dem; 1024-bitarsnycklar fungerar fortfarande men är minimum, och kortare nycklar avvisas. När en tjänst roterar sina nycklar måste den nya selectorn finnas i din DNS innan den används, annars misslyckas signaturerna.
DMARC: knyt det till From-adressen
DMARC är en TXT-post på _dmarc under din domän:
_dmarc.example.com. TXT ”v=DMARC1; p=none; rua=mailto:dmarc@example.com”
Den gör två saker som SPF och DKIM inte klarar på egen hand.
För det första kräver den alignment (samstämmighet). Ett meddelande klarar DMARC bara när SPF eller DKIM godkänns för samma domän som den synliga From-adressen. Ett nyhetsbrev som skickas via en tjänst som signerar med sin egen domän klarar DKIM, men inte för din domän, och misslyckas därför med DMARC. Det är därför varje tjänst behöver signera med din domän.
För det andra anger den en policy för e-post som inte klarar kontrollen:
p=none: leverera som vanligt. Inget förändras, men mottagarna kan skicka rapporter till dig.
p=quarantine: lägg det i skräpposten.
p=reject: avvisa det.
Taggen rua ber mottagarna att skicka dagliga sammanställda rapporter till en adress du väljer. De visar vilka servrar som har skickat e-post som din domän och om den godkändes, och det är så du hittar avsändare du har glömt bort.
Sätt upp dem i rätt ordning
Att gå direkt till p=reject är det klassiska sättet att se till att dina egna fakturor eller lösenordsåterställningar aldrig kommer fram. Gör det stegvis:
Lista allt som skickar som din domän. Din e-postleverantör, nyhetsbrevsverktyget, CRM-systemet, supportsystemet, bokningssystemet, e-handelsplattformen, kontaktformuläret på webbplatsen och alla servrar som skickar notiser.
Sätt upp DKIM för var och en av dem med din egen domän, enligt respektive tjänsts instruktioner.
Bygg en enda SPF-post med de tjänster som behöver den, under 10 uppslag, som slutar med ~all.
Publicera DMARC med p=none och en rua-adress, och låt den stå i två till fyra veckor.
Åtgärda varje legitim avsändare som inte klarar kontrollen, oftast en tjänst som fortfarande signerar med sin egen domän.
Gå över till p=quarantine, gärna med pct=25 för att börja med en fjärdedel av den e-post som inte klarar kontrollen, och sedan till p=reject när ingen legitim e-post längre fastnar.
Domäner som aldrig skickar e-post behöver också skydd, eftersom de är lätta att förfalska. Ge dem en post som säger just det:
example.org. TXT ”v=spf1 -all”
_dmarc.example.org. TXT ”v=DMARC1; p=reject”
Misstag som i det tysta förstör e-posten
En andra SPF-post som lagts till för en ny tjänst, i stället för en include i den första.
En SPF-post som passerade 10 uppslag när ännu ett verktyg lades till.
Ett nyhetsbrev eller CRM som skickar med sin egen DKIM-domän, så att DMARC misslyckas trots en giltig signatur.
En DKIM-nyckel som roterats hos leverantören men aldrig publicerats i DNS.
En DMARC-post med ett stavfel, till exempel p=rejected, som mottagarna ignorerar.
Att gå över till p=reject innan du har kontrollerat att varje avsändare godkänns.
En ändrad MX-post eller en e-postserver som hamnar på en blocklista, vilket försämrar leveransen oavsett posterna.
Inget av detta ger ett felmeddelande som du ser. E-posten börjar helt enkelt hamna i skräpposten, och du får höra det veckor senare när en kund säger att fakturan aldrig kom.
Kontrollera dina poster
Du kan kontrollera din domän direkt med vår kostnadsfria SPF-, DKIM- och DMARC-kontroll. Den läser posterna från DNS, räknar SPF-uppslagen, letar efter DKIM-nycklar under vanliga selectors och förklarar vad du behöver åtgärda, med posten att klistra in.
Poster som stämmer i dag slutar fungera när någon lägger till en tjänst nästa månad. Uptimechecks övervakning av e-postautentisering kontrollerar SPF, DKIM och DMARC på dina domänmonitorer två gånger om dagen, förklarar varje problem med enkla ord, ger dig DNS-posten som löser det och larmar bara när ett nytt problem dyker upp. Den slår också upp de e-postservrar du själv driver på blocklistor, så att en listning inte går obemärkt förbi. Lägg till den i domänövervakningen som redan varnar dig innan själva domänen löper ut.
Checklista
Lista alla tjänster som skickar e-post som din domän.
Sätt upp DKIM med din egen domän i var och en av dem, med 2048 bitar där det går.
Ha en enda SPF-post, under 10 uppslag, som slutar med ~all eller -all.
Publicera DMARC med p=none och en rapportadress.
Åtgärda varje legitim avsändare som inte klarar alignment.
Gå över till p=quarantine och sedan p=reject.
Skydda domäner som inte skickar e-post med v=spf1 -all och p=reject.
Kontrollera posterna regelbundet, och varje gång ett nytt verktyg börjar skicka e-post åt dig.