Tre delar som hänger ihop
E-post kan skickas med vilken avsändaradress som helst. Protokollet kontrollerar inte att du verkligen är den du utger dig för att vara. SPF, DKIM och DMARC lägger på den kontrollen i efterhand, via DNS.
- SPF är en lista i DNS över vilka servrar och tjänster som får skicka mejl för din domän.
- DKIM är en digital signatur som sändande server lägger i varje mejl. Mottagaren kontrollerar signaturen mot en publik nyckel i din DNS.
- DMARC binder ihop de två och talar om vad mottagaren ska göra när kontrollen misslyckas. Den ber också om rapporter.
SPF och DKIM kan fungera var för sig, men de säger ingenting om adressen som människan ser i mejlprogrammet, den i fältet From. Det är där DMARC kommer in.
Alignment: varför From-adressen avgör
För att DMARC ska godkänna ett mejl räcker det inte att SPF eller DKIM går igenom. Domänen som kontrollen gäller måste också stämma med domänen i From. Det kallas alignment.
- Vid SPF jämförs domänen i Return-Path (envelope-avsändaren) med From.
- Vid DKIM jämförs domänen i signaturen (
d=) med From.
Det räcker att ett av de två är godkänt och alignat. Ett nyhetsbrevsverktyg som skickar med sin egen Return-Path och sin egen DKIM-domän kan alltså klara SPF och DKIM, och ändå misslyckas med DMARC för din domän. Lösningen är nästan alltid att konfigurera tjänsten så att den signerar med din domän.
Alignment kan vara relaxed (standard: underdomäner av samma organisationsdomän räknas som samma) eller strict (exakt samma domän). Du styr det med adkim och aspf i DMARC-posten. Standardvärdet fungerar för de flesta.
SPF i korthet
SPF är en TXT-post på domänen som börjar med v=spf1. Den räknar upp tillåtna avsändare och slutar med en regel för alla andra.
exempel.se. TXT "v=spf1 include:spf.protection.outlook.com ~all"Slutet avgör hur strängt det blir: -all betyder att andra inte får skicka, ~all betyder att de är misstänkta, ?all betyder neutral och +all betyder att alla får skicka. Med DMARC i drift är ~all vanlig och rimlig praxis.
DKIM i korthet
DKIM-nyckeln ligger som TXT eller CNAME på selector._domainkey.exempel.se. Selectorn är ett namn som tjänsten väljer, så att en domän kan ha flera nycklar samtidigt, en per avsändande tjänst. Du hittar värdet i tjänstens administrationsgränssnitt. Använd helst nycklar på 2048 bitar där DNS-leverantören klarar det.
DMARC och de tre policyerna
DMARC-posten ligger som TXT på _dmarc.exempel.se. Det viktigaste är taggen p=, policyn:
- none: övervaka bara. Mejl som misslyckas levereras som vanligt, men du får rapporter. Inget skydd mot förfalskning ännu.
- quarantine: mejl som misslyckas ska behandlas som misstänkta. Mottagare lägger dem oftast i skräppost.
- reject: mejl som misslyckas ska avvisas. Det är det starkaste skyddet.
Vad mottagaren faktiskt gör är en rekommendation från din sida. Stora mottagare följer den oftast, men det är deras beslut.
_dmarc.exempel.se. TXT "v=DMARC1; p=none; rua=mailto:[email protected]"En säker väg till reject
Gå inte direkt till p=reject om du inte vet exakt vilka som skickar mejl för din domän. Då kan du stoppa fakturor, nyhetsbrev och bokningsbekräftelser. Gör så här i stället:
- Inventera och övervaka. Publicera
p=nonemedruaoch läs rapporterna i några veckor. Du ser vilka tjänster som skickar som din domän och vilka som misslyckas. - Rätta avsändarna. Lägg till include i SPF eller aktivera DKIM-signering med din domän för varje legitim tjänst. Titta på rapporterna igen tills de legitima flödena är godkända.
- Gå till quarantine. Sätt
p=quarantine. Du kan börja medpct=25för att bara låta en del av mejlen påverkas och sedan höja till 100. - Gå till reject. När quarantine har varit tyst en tid sätter du
p=rejectmedpct=100.
Hur länge varje steg ska vara beror på hur många avsändare du har. Behåll rua hela vägen, även efter reject. Nya tjänster dyker upp, och rapporterna visar när något går sönder.
Rapporter: rua och ruf
rua är adressen dit mottagare skickar aggregerade rapporter, normalt en XML-fil per dygn och mottagare. De visar vilka IP-adresser som skickat som din domän och om SPF, DKIM och DMARC gick igenom. De innehåller inget mejlinnehåll.
ruf är adressen för felrapporter om enskilda mejl. Många stora mottagare skickar inte sådana alls, bland annat av integritetsskäl. Du kan lugnt hoppa över ruf.
Rå XML är jobbigt att läsa. De flesta använder en tjänst som tar emot rapporterna och sammanställer dem, eller en brevlåda som du bläddrar i själv. Skickar du rapporter till en adress på en annan domän måste den domänen godkänna det med en särskild DNS-post.
Subdomäner och sp=
DMARC-policyn i _dmarc.exempel.se gäller även subdomäner, om de inte har en egen post. Med sp= kan du ange en separat policy för subdomäner. Det blir ett vanligt misstag åt två håll:
- Du har
p=rejectmensp=none, och då kan någon förfalskafaktura.exempel.sefritt. - Du glömmer att en subdomän skickar legitim post (till exempel
nyhetsbrev.exempel.se) och stänger den av oavsiktligt.
Domäner som du inte skickar mejl från bör ha v=spf1 -all och en DMARC-post med p=reject. Då går de inte att missbruka.
MTA-STS, TLS-RPT och BIMI
Tre tillägg som inte handlar om förfalskning, men som ofta kommer upp i samma sammanhang.
- MTA-STS talar om för andra mejlservrar att de ska använda krypterad TLS när de skickar till dig, och till vilka servrar. Utan MTA-STS kan en angripare i nätet tvinga en anslutning att falla tillbaka till okrypterat. Du publicerar en TXT-post på
_mta-stsoch en policyfil över HTTPS påmta-sts.exempel.se. Börja gärna medmode: testingoch byt tillenforcenär allt fungerar. - TLS-RPT är en TXT-post på
_smtp._tlssom ber andra servrar att rapportera TLS-problem när de skickar till dig. Den passar ihop med MTA-STS. - BIMI låter din logotyp visas bredvid mejl hos mottagare som stöder det. Det kräver att DMARC redan ligger på quarantine eller reject, och många mottagare kräver dessutom ett betalt certifikat. Det påverkar inte säkerheten och räknas inte i betyget.
Vanliga misstag
- Flera SPF-poster. En domän får bara ha en post som börjar med
v=spf1. Har du två får SPF ett permanent fel och ingen av dem gäller. Slå ihop dem till en. - Över 10 DNS-uppslag. SPF får utlösa högst 10 uppslag (include, a, mx, ptr, exists och redirect räknas, även nästlade). Över det ger också ett permanent fel. Ta bort tjänster du inte längre använder eller byt include mot fasta
ip4-adresser där det går. - +all eller bara all. Det betyder att vem som helst får skicka som din domän. Använd
~alleller-all. - Glömda subdomäner. Se
sp=ovan. - Hoppa direkt till reject. Se den säkra vägen ovan.
- Tjänster som skickar utan egen signering. Nyhetsbrev, CRM och fakturasystem behöver egen include eller DKIM med din domän, annars misslyckas alignment.
- DMARC-post med syntaxfel. Ogiltig eller dubbel post räknas som saknad. Taggarna ska stå i ordning med
v=DMARC1först ochp=därefter.
Vad betyget på dmarccheck.se betyder
Testet ger betyg från A till F. Du börjar på A, och varje brist sätter ett tak. Det lägsta taket blir betyget. Saknad DMARC ger som mest E, p=none som mest D, och full poäng kräver bland annat p=reject, giltig SPF och DKIM. Reglerna står i klartext under Så sätts betyget. Kan vi inte nå DNS sätter vi inget betyg alls i stället för att gissa.
Testa din domän och följ åtgärderna i den ordning rapporten föreslår. Fortsätt därefter med guiderna för Microsoft 365 och Google Workspace, eller läs om felet 550 5.7.26.