SPF vs DKIM vs DMARC: vad är skillnaden?

Vad gör SPF?

SPF besvarar en fråga: får servern som levererade det här meddelandet skicka för domänen? Domänägaren publicerar en TXT-post som börjar med v=spf1 och listar tillåtna källor, till exempel include:_spf.protonmail.ch för Proton Mail. En mottagare jämför den anslutande IP-adressen med listan och får ett resultat: pass, fail, softfail eller neutral, beroende på kvalificeraren i slutet (-all, ~all eller ?all).

SPF kontrollerar kuvertavsändaren (MAIL FROM) och HELO-namnet, inte From-adressen som läsaren ser. Det gapet är skälet till att DMARC finns. SPF har också hårda gränser: en domän får bara ha en SPF-post, och utvärderingen avbryts med ett permanent fel efter 10 DNS-frågande termer (include, a, mx, ptr, exists, redirect). Hela metoden finns i guiden om hur du skapar en SPF-post.

Vad gör DKIM?

DKIM besvarar en annan fråga: var meddelandet signerat av den domän det säger sig komma från, och kom det fram oförändrat? Avsändande servern signerar utvalda rubriker och innehållet med en privat nyckel. Mottagaren läser signerande domänen (d=) och selektorn (s=) från DKIM-Signature-rubriken, hämtar den publika nyckeln på selector._domainkey.domän i DNS och kontrollerar signaturen.

Eftersom signaturen följer med meddelandet överlever DKIM en vidarebefordran som lämnar meddelandet intakt, vilket SPF inte gör, eftersom en vidarebefordrare skickar från sin egen IP-adress. RFC 6376 säger att signerare måste använda RSA-nycklar på minst 1024 bitar för långlivade nycklar, och rekommenderar nya selektorer när nycklarna ändras. Leverantörerna publicerar nycklarna åt dig: tre CNAME-poster för Proton Mail och Fastmail, fyra för Mailbox.org. Detaljerna finns i guiden om hur du ställer in DKIM.

Vad gör DMARC?

DMARC kopplar SPF och DKIM till den synliga From-domänen och talar om för mottagare vad de ska göra när ingen kontroll stämmer överens. Ett meddelande klarar DMARC när SPF eller DKIM godkänns och domänen de autentiserade matchar From-domänen. Överensstämmelsen är avslappnad som standard (samma organisatoriska domän) och strikt när den ställs in med aspf=s eller adkim=s.

Posten ligger på _dmarc.dindomän och bär en policy: p=none (endast övervakning), p=quarantine (behandla som misstänkt) eller p=reject (vägra). En rua-adress tar emot sammanställda rapporter, som visar vem som skickar post i ditt namn. RFC 9989, publicerad i maj 2026, är den gällande specifikationen; den ersätter RFC 7489, tar bort taggen pct och lägger till en testflagga t. Övergången från övervakning till avvisning finns i guiden om hur du ställer in DMARC.

Behöver jag alla tre?

Ja: en egen domän som skickar post bör publicera SPF, DKIM och DMARC, eftersom de största mottagarna kräver dem. Googles riktlinjer för avsändare kräver SPF, DKIM och en DMARC-post (policyn none räcker) för avsändare över 5 000 meddelanden per dag till Gmail-konton. Microsoft kräver samma tre av Outlook.com-avsändare över 5 000 per dag, från 5 maj 2025, och Yahoo kräver SPF, DKIM och DMARC även för massutskick.

En personlig brevlåda skickar betydligt färre meddelanden, så gränserna binder dig inte. Posterna avgör ändå om din post når inkorgen, och de hindrar andra från att förfalska din adress. Enligt Postelva:s räkning per den 12 november 2026 från leverantörernas hjälpsidor kräver en fullständig Proton Mail-installation 8 DNS-poster och en fullständig Mailbox.org-installation 11, varav 3 respektive 4 är DKIM-nycklar. MX-posterna behandlas i vad en MX-post är.

Vilka misstag förstör de tre posterna?

Tre misstag orsakar de flesta fel: en andra SPF-post, fler än 10 uppslag och en DMARC-policy som är för strikt för tidigt. En domän med två SPF-poster ger ett permanent fel, så lägg till den nya leverantörens include i den befintliga posten. Om man staplar en mailvärd, ett nyhetsverktyg och en helpdesk kan uppslagen passera 10, och posten misslyckas då för varje avsändare. Mailbox.org och Proton rår båda att börja DMARC med p=none, och Mailbox.org varnar för att en strikt policy som tillämpas för tidigt kan studsa legitim post.

Ett fjärde misstag är att behålla den tidigare leverantörens DKIM- och SPF-poster i månader. De skadar inte leveransen, men de vidgar listan över servrar som får tala för dig. Ta bort dem när flytten har bekräftats.

Hur samverkar de tre i ett och samma meddelande?

Mottagaren kör SPF och DKIM, och sedan kombinerar DMARC resultaten. Ta ett meddelande från [email protected] skickat via Proton Mail. SPF godkänns om den anslutande servern finns i listan _spf.protonmail.ch. DKIM godkänns om signaturen gjord med nyckeln under dittnamn.com verifieras. DMARC frågar sedan om minst en av de två godkändes med dittnamn.com som den överensstämmande identifieraren. Om ja godkänns meddelandet; om inte tillämpar mottagaren din policy och för in resultatet i nästa sammanställda rapport.

RFC 9989 noterar att en domän med p=reject inte får förlita sig på enbart SPF och bör signera med DKIM, eftersom SPF går sönder vid vidarebefordran. ARC (RFC 8617), en experimentell standard, låter vidarebefordrare registrera de ursprungliga resultaten, men det ingår inte i din egen installation. Efter publicering av posterna, kontrollera dem med dig innan du skärper någon policy.

En citerbar definition: SPF auktoriserar servrar, DKIM autentiserar meddelanden, och DMARC verkställer överensstämmelsen med From-domänen och rapporterar resultatet.