SPF: vem som får skicka
RFC 7208 utgår från ett konstaterande: ingenting i e-postprotokollet hindrar en server från att uppge vilken avsändaradress som helst. SPF gör det möjligt för ägaren av en domän att i DNS publicera listan över servrar som får skicka i dess namn, och för den mottagande servern att kontrollera den behörigheten.
Två preciseringar ändrar allt:
- SPF kontrollerar kuvertadressen (den i dialogen mellan servrarna, kallad ”MAIL FROM”) och namnet som servern uppger, inte adressen som mottagaren läser i ”Från”.
- SPF bedömer den sista servern som levererade meddelandet. När ett meddelande vidarebefordras av en annan server är det inte längre en server som ursprungsdomänen har godkänt som levererar det: kontrollen kan misslyckas fast meddelandet är legitimt.
En domän publicerar bara en enda SPF-post. Alla källor som skickar e-post ska finnas med: e-postsystemet, faktureringsprogrammet, nyhetsbrevsverktyget, CRM-systemet, kopiatorn som skannar till e-post.
DKIM: meddelandet är signerat
Enligt RFC 6376 gör DKIM det möjligt för ägaren av en signerande domän att ta på sig en del av ansvaret för ett meddelande, med hjälp av en kryptografisk signatur. Den publika nyckeln finns i DNS. Att verifiera signaturen visar att de signerade delarna inte har ändrats sedan signeringen.
Signaturen följer med meddelandet. Den klarar sig därför bättre än SPF genom ett relä eller en vidarebefordran, så länge reläet inte ändrar ämnet eller brödtexten. En e-postlista som lägger till en rad längst ner i meddelandet bryter den.
Vad DKIM inte gör, enligt samma RFC: den krypterar inte meddelandet, ett misslyckande kräver inte att det avvisas, och domänen som signerar behöver inte vara den som visas i ”Från”. Det är just den luckan som DMARC fyller.
DMARC: anpassning och policy
RFC 7489 definierar DMARC som ett sätt för ägaren av en domän att uttrycka en policy på domännivå. Mekanismen bygger på anpassning (alignment): domänen i adressen som visas i ”Från” måste stämma med domänen som validerats av SPF eller DKIM. Om ingen av dem är anpassad misslyckas DMARC.
Domänen publicerar då vad den önskar:
- none: ingen åtgärd begärs, man observerar;
- quarantine: behandla meddelandet som misstänkt;
- reject: avvisa meddelandet.
DMARC innehåller också rapporter: aggregerade rapporter, som sammanfattar vilka servrar som har skickat i domänens namn och med vilket resultat, och felrapporter, meddelande för meddelande. Det är de som gör det möjligt att upptäcka ett bortglömt verktyg som skickar åt er, eller någon som förfalskar er domän.
| Mekanism | Vad den kontrollerar | Vad den inte tittar på |
|---|
| SPF | Servern som levererar meddelandet är godkänd för kuvertdomänen | Den visade adressen, innehållet |
| DKIM | Det signerade meddelandet har inte ändrats; en domän tar ansvar för det | Den visade adressen, innehållets ärlighet |
| DMARC | Den visade domänen är anpassad med SPF eller DKIM; policy vid misslyckande | Liknande domäner, visningsnamnet, texten |
Stoppar DMARC nätfiske?
Den stoppar en del av förfalskningen av domänen, inte nätfiske i allmänhet. RFC 7489 säger det uttryckligen: DMARC behandlar varken visuellt liknande domännamn eller missbruk av visningsnamnet, och innehållsanalys ligger utanför dess omfattning. Den försöker inte lösa alla problem med bedräglig e-post.
Konkret ser DMARC inte:
- en förväxlingsbar domän: bedragaren autentiserar sin egen domän, som liknar er, helt korrekt;
- ett förfalskat visningsnamn: ”Ekonomiavdelningen” som skriver från en adress utan koppling;
- ett komprometterat konto som signerar korrekt, eftersom det är den riktiga servern som skickar;
- ett meddelande utan koppling till er domän: ett falskt meddelande från ett fraktbolag kommer från en domän som inte har något med er att göra;
- en domän utan policy: om den imiterade domänen publicerar ”none” har mottagaren ingen instruktion om att avvisa.
Dessa fall kräver andra analyser: domänlikhet, rykte, innehåll, beteende. Se spam, nätfiske, skadlig kod och komprometterat konto.
Vidarebefordran och e-postlistor: ARC
En vidarebefordran bryter ofta SPF, en lista som ändrar meddelandet bryter DKIM, och DMARC misslyckas då för ett legitimt meddelande. ARC, som beskrivs i RFC 8617 (experimentell status), gör det möjligt för varje mellanled att intyga det autentiseringsresultat det har konstaterat. Den slutliga servern kan välja att ta hänsyn till det.
Skydda sin domän, filtrera det som kommer in
Det är två frågor som ofta blandas ihop.
- Skydda domänen som skickar: publicera SPF, DKIM och DMARC för er domän, så att andra kan avvisa meddelanden som förfalskar den. Det är ni som publicerar; det är mottagarna som tillämpar.
- Filtrera det som kommer in: kontrollera andra domäners poster för den e-post ni tar emot, och tillämpa sedan alla andra analyser.
Stegvis införande
- Inventera allt som skickar i domänens namn.
- En enda SPF-post som godkänner dem; en DKIM-signatur för varje tjänst som kan signera.
- DMARC i läget ”none”, med en adress som tar emot rapporterna.
- Läs rapporterna under flera veckor; rätta till bortglömda källor.
- Gå över till ”quarantine”, och sedan till ”reject” när alla legitima utskick är anpassade.
Ett exempel, som illustration. En byrå publicerar DMARC i läget ”none” och läser sina första rapporter. Där upptäcker den tre källor: sitt e-postsystem, korrekt anpassat; sitt faktureringsprogram, som skickar fakturorna med byråns domän utan DKIM-signatur; och en okänd server utomlands som skickar hundratals meddelanden i dess namn. Byrån rättar faktureringsprogrammet, väntar på en rapportcykel utan fel och går sedan över till ”quarantine”: mottagare som tillämpar DMARC behandlar nu meddelandena från den okända servern som misstänkta.
Den dag man byter e-postsystem förbereds dessa poster före bytet av MX. Guiden migrera ett e-postsystem utan avbrott beskriver det skedet; det upprepas inte här.
Vanliga frågor
Skyddar en DMARC-policy i läget ”none”?
Nej. Den gör det möjligt att observera med hjälp av rapporterna. Skyddet börjar med ”quarantine” eller ”reject”.
Varför misslyckas DMARC för ett legitimt meddelande?
Oftast: en vidarebefordran, en e-postlista, eller en tjänst som skickar åt er utan att vara angiven i SPF eller signera med DKIM.
Vårt e-postsystem signerar inte med DKIM: vad gör vi?
En gateway som ligger på vägen för utgående e-post kan signera i dess ställe. Se Skydda det e-postsystem ni redan har.
Var läser man resultatet av dessa kontroller för ett mottaget meddelande?
I meddelandets huvuden. För Klytic MTA, se Läsa och exportera ett filterbeslut.
Var Klytic står
Klytic MTA hanterar båda frågorna, framför vilket e-postsystem som helst:
- Essential och Advanced: kontroll av SPF, DKIM och MX; DMARC-kontroll, även för vidarebefordrade meddelanden tack vare ARC; DKIM-signering av utgående e-post, även om ert e-postsystem inte gör det.
- Advanced: DMARC-konsol, med rapporterna för era domäner, larm och förslag på åtgärder, för att genomföra den stegvisa övergången till ”reject”.
DMARC är bara ett lager: Klytic MTA lägger till upptäckt av förväxlingsbara domäner, visningsnamn och bedrägerischeman, som beskrivs i Identitetsförfalskning och vd-bedrägeri.
Om ni använder Klytic Mail är SPF, DKIM och DMARC konfigurerade för er domän: det är skyddet av domänen som skickar. Klytic MTA kan däremot tecknas med eller utan Klytic Mail.
Källor
Hämtade i oktober 2026.
- RFC 7208, SPF: ägaren av en domän publicerar de värdar som får använda domänen i identiteten ”MAIL FROM” eller ”HELO”, och mottagaren kontrollerar den behörigheten. rfc-editor.org
- RFC 6376, DKIM: en domän tar ansvar för ett meddelande genom en kryptografisk signatur; ingen kryptering, inget krav på avvisning, den signerande domänen kan skilja sig från den visade avsändaren. rfc-editor.org
- RFC 7489, DMARC: anpassning av domänen i ”From” med SPF eller DKIM, policyerna none, quarantine och reject, aggregerade rapporter och felrapporter; visuellt liknande domäner, visningsnamn och innehållsanalys utanför omfattningen. rfc-editor.org
- RFC 9989 (maj 2026), som ersätter RFC 7489: samma policyvärden och samma undantag (liknande domäner, visningsnamn). rfc-editor.org
- RFC 8617, ARC (experimentell): autentiserad överföringskedja; en DMARC-mottagare kan godta de bedömningar som bärs av en giltig ARC-kedja. rfc-editor.org
- Klytic, sidan Klytic MTA: autentiseringskontroller, utgående DKIM-signering och DMARC-konsol i paketen Essential och Advanced, tillägg, driftformer, driftstart via MX. klytic.com
