SPF, DKIM og DMARC er tre DNS-poster som avgjør to ting: om e-posten du sender havner i innboksen, og om noen andre kan sende e-post som ser ut til å komme fra deg. Gmail, Yahoo og Outlook.com krever nå alle tre av alle som sender i store volum, og for alle andre er det større sjanse for at meldinger uten dem havner i søppelposten.
Postene er korte, men det er lett å få dem litt feil, og de slutter å virke uten forvarsel når et nytt verktøy begynner å sende for deg. Denne guiden forklarer hva hver av dem gjør, hvordan du setter dem opp i riktig rekkefølge, og hvordan du holder dem i orden.
Slik henger de sammen
Hver e-post har to avsenderadresser: konvoluttavsenderen, som e-postservere bruker til å returnere sprett, og From-adressen mottakeren ser. Svindel utnytter gapet mellom dem: hvem som helst kan skrive hvilken som helst From-adresse. De tre postene tetter det gapet.
SPF (Sender Policy Framework) lister opp serverne som har lov til å sende e-post for domenet ditt.
DKIM (DomainKeys Identified Mail) legger til en kryptografisk signatur på hver melding, som mottakerne verifiserer mot en offentlig nøkkel i DNS-en din.
DMARC (Domain-based Message Authentication, Reporting and Conformance) knytter dem til den synlige From-adressen og forteller mottakerne hva de skal gjøre med e-post som feiler.
SPF: hvem som får sende
En SPF-post er en TXT-post på domenet ditt. Den lister opp tjenestene og serverne som sender e-post for deg, og avslutter med hva som skal skje med alt annet:
example.com. TXT «v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.25 ~all»
include: legger til SPF-posten til et annet domene, den vanlige måten å godkjenne en e-posttjeneste på.
ip4: og ip6: godkjenner bestemte adresser, for eksempel din egen e-postserver.
~all (soft fail) eller -all (fail) sier hva som skjer med alle som ikke står på listen. Bruk aldri +all, som godkjenner hele internett.
To regler er det de fleste domener snubler i:
Bare én post. Et domene må ha nøyaktig én SPF-post. Med to returnerer mottakerne en permanent feil, og SPF feiler for hver eneste melding. Når en ny tjeneste ber deg «legge til denne SPF-posten», legger du heller dens include inn i posten du allerede har.
Maks 10 DNS-oppslag. Hver include, a, mx og redirect koster et oppslag, og include inni include teller også. Over 10 feiler SPF. En post med Google Workspace, et nyhetsbrevverktøy, et CRM og en helpdesk kan gå over grensen uten at noen merker det.
SPF har en svakhet: den sjekker konvoluttavsenderen, ikke From-adressen mottakeren ser, og den slutter å virke når e-post videresendes. Derfor er den ikke nok alene.
DKIM: en signatur på hver melding
Med DKIM signerer e-posttjenesten din hver melding med en privat nøkkel. Den offentlige nøkkelen ligger i DNS, under et navn som kalles en selector:
google._domainkey.example.com. TXT «v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC…»
Mottakeren leser selectoren fra meldingens DKIM-Signature-header, slår opp nøkkelen og sjekker at meldingen ikke er endret underveis. En DKIM-signatur overlever videresending, og det gjør den til den mest pålitelige av de to.
Hver tjeneste som sender for deg, trenger sitt eget DKIM-oppsett, som regel i administrasjonsinnstillingene under «autentisering» eller «verifisert domene». Bruk 2048-bits nøkler der tjenesten tilbyr det; 1024-bits nøkler virker fortsatt, men er minimum, og kortere nøkler avvises. Når en tjeneste roterer nøklene sine, må den nye selectoren ligge i DNS-en din før den tas i bruk, ellers feiler signaturene.
DMARC: knytt det til From-adressen
DMARC er en TXT-post på _dmarc under domenet ditt:
_dmarc.example.com. TXT «v=DMARC1; p=none; rua=mailto:dmarc@example.com»
Den gjør to ting som SPF og DKIM ikke klarer alene.
For det første krever den samsvar (alignment). En melding består DMARC bare når SPF eller DKIM består for samme domene som den synlige From-adressen. Et nyhetsbrev sendt gjennom en tjeneste som signerer med sitt eget domene, består DKIM, men ikke for ditt domene, og feiler derfor DMARC. Det er grunnen til at hver tjeneste må signere med ditt domene.
For det andre setter den en policy for e-post som feiler:
p=none: lever den som vanlig. Ingenting endres, men mottakerne kan sende deg rapporter.
p=quarantine: legg den i søppelposten.
p=reject: avvis den.
rua-taggen ber mottakerne sende daglige samlerapporter til en adresse du velger. De viser hvilke servere som sendte e-post i domenets navn, og om den besto, og det er slik du finner avsendere du hadde glemt.
Sett dem opp i riktig rekkefølge
Å gå rett til p=reject er den klassiske måten å stoppe dine egne fakturaer eller tilbakestillinger av passord på. Ta det i trinn:
List opp alt som sender i domenets navn. E-postleverandøren, nyhetsbrevverktøyet, CRM-et, helpdesken, bookingsystemet, nettbutikkplattformen, kontaktskjemaet på nettstedet og alle servere som sender varsler.
Sett opp DKIM for hver av dem med ditt eget domene, etter instruksjonene fra hver tjeneste.
Bygg én SPF-post med tjenestene som trenger det, under 10 oppslag, som slutter med ~all.
Publiser DMARC med p=none og en rua-adresse, og la den stå i to til fire uker.
Rett opp hver legitime avsender som feiler, som regel en tjeneste som fortsatt signerer med sitt eget domene.
Gå over til p=quarantine, gjerne med pct=25 for å starte med en fjerdedel av e-posten som feiler, og deretter til p=reject når ingenting legitimt feiler lenger.
Domener som aldri sender e-post, fortjener også beskyttelse, siden de er lette å forfalske. Gi dem en post som sier nettopp det:
example.org. TXT «v=spf1 -all»
_dmarc.example.org. TXT «v=DMARC1; p=reject»
Feil som i det stille ødelegger e-posten
En ekstra SPF-post lagt til for en ny tjeneste, i stedet for en include i den første.
En SPF-post som gikk over 10 oppslag da enda et verktøy ble lagt til.
Et nyhetsbrev eller CRM som sender med sitt eget DKIM-domene, slik at DMARC feiler til tross for en gyldig signatur.
En DKIM-nøkkel som er rotert hos leverandøren, men aldri publisert i DNS.
En DMARC-post med en skrivefeil, for eksempel p=rejected, som mottakerne ignorerer.
Å gå over til p=reject før du har sjekket at alle avsendere består.
En endret MX-post eller en e-postserver som havner på en svarteliste, noe som skader leveringen uansett hva postene sier.
Ingen av disse gir en feilmelding du ser. E-posten begynner rett og slett å havne i søppelposten, og du hører om det uker senere når en kunde sier at fakturaen aldri kom.
Sjekk postene dine
Du kan sjekke domenet ditt med en gang med vår gratis SPF-, DKIM- og DMARC-sjekker. Den leser postene fra DNS, teller SPF-oppslagene, ser etter DKIM-nøkler under vanlige selectorer og forklarer hva du må rette, med posten du kan lime inn.
Poster som er riktige i dag, slutter å virke når noen legger til en tjeneste neste måned. Uptimechecks overvåking av e-postautentisering sjekker SPF, DKIM og DMARC på domeneovervåkingene dine to ganger om dagen, forklarer hvert problem med enkle ord, gir deg DNS-posten som løser det, og varsler deg bare når et nytt problem dukker opp. Den slår også opp e-postserverne du drifter selv på svartelister, slik at en oppføring ikke går upåaktet hen. Legg den til domeneovervåkingen som allerede sier fra før selve domenet utløper.
Sjekkliste
List opp hver tjeneste som sender e-post i domenets navn.
Sett opp DKIM med ditt eget domene i hver av dem, 2048-bits der det er mulig.
Ha én SPF-post, under 10 oppslag, som slutter med ~all eller -all.
Publiser DMARC med p=none og en rapportadresse.
Rett opp hver legitime avsender som ikke har samsvar.
Gå over til p=quarantine, deretter p=reject.
Beskytt domener som ikke sender, med v=spf1 -all og p=reject.
Sjekk postene jevnlig, og hver gang et nytt verktøy begynner å sende for deg.