Så läser ni rapporten från e-postsäkerhetskontrollen

Vad tittar e-postsäkerhetskontrollen på?

Kontrollen kombinerar två slags underlag. Det första är hur vår mottagande e-postserver bedömde det meddelande ni skickade: om SPF, DKIM och DMARC godkändes, om meddelandet bevisade att det kom från er egen domän och om det kom fram krypterat. Det andra är avsändardomänens aktuella publika konfiguration i DNS: DMARC-policyn, SPF-posten, DKIM-nyckeln, MTA-STS, TLS-rapportering, era e-postservrar, DNSSEC och BIMI.

Bara autentiseringsheaders och publik DNS analyseras. Meddelandetexten sparas aldrig, och råmeddelandet raderas så snart det har tolkats.

Eftersom kontrollen ser ett meddelande från en avsändarväg, bedömt av en mottagare, kan den inte visa alla tjänster som skickar e-post i er domäns namn, eller hur konfigurationen förändras över tid. Ett nyhetsbrevsverktyg eller ett faktureringssystem som skickar i ert namn kan vara uppsatt helt annorlunda än brevlådan ni testade med.

Vad säger det samlade betyget och sammanfattningen?

Överst anger rapporten vilken domän den gäller och visar ett Samlat betyg, en bokstav från A till F med en poäng av 100. Poängen börjar på 100 och sjunker för varje kontroll som är märkt Underkänd eller Behöver åtgärdas, och ett allvarligt problem kostar betydligt fler poäng än ett mindre. 90 poäng eller mer ger A; under 40 ger F. Kontroller märkta Kunde inte fastställas påverkar inte poängen, och därför hör betyget och listan över ofullständiga kontroller ihop.

Under Sammanfattning ges sedan en av tre bedömningar i klartext:

• ”Någon skulle kunna skicka e-post som utger sig för att vara ni.” Minst en kontroll är underkänd, oavsett i vilket avsnitt.
• ”Ni har visst skydd, men det finns luckor värda att täppa till.” Inget är underkänt, men minst en kontroll behöver åtgärdas.
• ”Meddelandet var väl skyddat.” Inga problem hittades i de kontroller som kunde slutföras för meddelandet.

Under sammanfattningen listar Högst prioriterade åtgärder upp till tre problem, det allvarligaste först, med vad ni bör göra. Har ni bara tid för några få ändringar, börja där.

Vad betyder Godkänd, Behöver åtgärdas, Underkänd, Används inte och Kunde inte fastställas?

Varje kontroll är ett kort med en fråga i klartext som rubrik, till exempel ”Finns en lista över vilka som får skicka e-post i ert namn?”, och en av fem etiketter:

• Godkänd: kontrollen hittade inget problem.
• Behöver åtgärdas: inställningen fungerar, men den är svagare än den bör vara eller kan ställa till problem senare.
• Underkänd: något är trasigt eller saknas på ett sätt som försvagar ert skydd eller kan stoppa er e-post.
• Används inte: en valfri funktion som ni inte har satt upp, eller information som kontrollen inte kan mäta utifrån ett meddelande. Den är informativ och sänker inte betyget.
• Kunde inte fastställas: kontrollen kunde inte slutföras, till exempel för att en DNS-uppslagning inte svarade i tid. Den är varken godkänd eller underkänd.

Under rubriken förklarar ”Vad detta betyder” resultatet i klartext. Kort märkta Underkänd eller Behöver åtgärdas säger också vad ni bör göra. Kontrollerna är grupperade under fem frågor, i den ordning rapporten visar dem, och en grupp utan innehåll visas inte.

Kan någon skicka e-post som utger sig för att vara ni?

Den här gruppen skyddar ert namn. Den avgör om en främling kan skriva er domän som avsändare och få meddelandet levererat. Den omfattar er DMARC-policy, om meddelandet ni skickade knöts till er egen domän, mottagarserverns samlade bedömning och er SPF-post.

• ”Får e-postsystem instruktion att stoppa falska meddelanden?” är underkänd när DMARC-post saknas, och behöver åtgärdas vid p=none, eftersom falska meddelanden då levereras som vanligt. En policy som bara gäller en del av den underkända e-posten (pct under 100), eller som undantar underdomäner med sp=none, behöver också åtgärdas. p=quarantine och p=reject godkänns båda; p=reject är slutmålet. Gå över till blockering i etapper, som guiden om att skärpa DMARC beskriver.
• ”Bevisade meddelandet ni skickade att det verkligen var ert?” är underkänd när SPF eller DKIM godkändes, men för den sändande tjänstens domän i stället för er. När ni skärper DMARC avvisas e-post som skickas så, även er riktiga e-post. Lösningen är oftast att tjänsten signerar med er egen domän, ofta kallat eget DKIM.
• ”Finns en lista över vilka som får skicka e-post i ert namn?” är er SPF-post. -all är målet. ~all märks Behöver åtgärdas, eftersom den är tillåtande mot avsändare som listan inte känner igen. +all, eller fler än en SPF-post, är underkänt.
• ”Är listan kort nog att faktiskt kunna läsas?” är underkänd när posten kräver fler DNS-uppslagningar än mottagare tillåter. Mottagaren slutar då läsa och betraktar SPF som misslyckad, även för äkta e-post. Guiden om SPF-gränsen för uppslagningar förklarar hur ni kortar ner den.

Är er e-post signerad på ett sätt andra kan lita på?

DKIM är den digitala signatur som gör att er e-post klarar vidarebefordran och ändå kan bevisa att den kom från er. En signatur kan finnas och ändå vara svag, så rapporten kontrollerar den i flera delar och lägger ”Samlad status för signeringen” överst i gruppen.

• Ingen signatur alls är underkänt. Skyddet vilar då helt på den sändande serverns adress, vilket brister så snart någon vidarebefordrar meddelandet. Be er e-postleverantör slå på signering för er domän.
• En nyckel som saknas, är återkallad eller inte stämmer gör att ingen kan verifiera signaturen. Be er leverantör om rätt nyckel och publicera den i DNS.
• En signatur som använder SHA-1, eller som inte skyddar avsändaradressen, är underkänd. En signatur som bara täcker en del av meddelandetexten behöver åtgärdas, eftersom text som läggs till i slutet ändå ser signerad ut.
• ”Kan signeringsnyckeln bytas ut säkert?” är information. DNS låter ingen lista era nycklar, så ett meddelande kan inte visa om en reservnyckel finns. Kontrollera med er leverantör att nycklarna byts ut.

Guiden om DKIM går igenom inställningarna mer ingående.

Vet ni vilka som skickar e-post i ert namn?

Den här gruppen har en kontroll: om er DMARC-post ber mottagare skicka aggregerade rapporter till en adress ni kontrollerar. Utan rapporter arbetar ni i blindo. Ni kan inte veta vilka av era egna tjänster som skickar e-post, och därför kan ni inte slå på blockering på ett säkert sätt.

Är kontrollen underkänd, lägg till en rapportadress (rua) i DMARC-posten och följ rapporterna i några veckor innan ni skärper policyn. Guiden om DMARC förklarar vad rapporterna innehåller.

Skyddas er e-post under transporten?

Kryptering mellan e-postservrar hindrar att meddelanden läses eller ändras på vägen. Det är skilt från att bevisa vem som skickade dem. Gruppen omfattar både meddelandet ni skickade och hur er domän tar emot e-post.

• ”Var meddelandet krypterat på vägen?” gäller det sista leveranssteget. Kunde inte fastställas betyder här att den mottagande servern inte noterade det, vilket inte är samma sak som att meddelandet var okrypterat.
• ”Flaggade vårt skräppostfilter meddelandet?” visas bara när vårt filter klassade testmeddelandet som skräppost. Meddelandet analyseras ändå. En saknad ämnesrad är en vanlig orsak, så skicka ett vanligt e-postmeddelande med ämnesrad.
• ”Krävs kryptering, eller bara erbjuds den?” är MTA-STS. Utan policy, eller med policyn i testläge, behöver den åtgärdas: avsändare kan fortfarande leverera okrypterat. En policy i läget enforce som utelämnar någon av era e-postservrar är underkänd, eftersom e-post till den servern nekas. Guiden om MTA-STS beskriver hur ni inför det säkert.
• ”Får ni veta när kryptering misslyckas?” är TLS-RPT. Utan det går misslyckade krypterade leveranser till er obemärkta förbi.
• ”Vart går er inkommande e-post?” kontrollerar era MX-poster. En domän som bara skickar bör ange det uttryckligen med en null MX-post, som guiden om domäner som inte skickar e-post förklarar.
• ”Extra certifikatskydd (valfritt)” är DANE. Används inte är helt i sin ordning här; de flesta avsändare kräver det inte.

Vad ingår under Grunder och tillägg?

Det här är stödjande punkter: bra att åtgärda på sikt, men inte det en angripare utnyttjar först.

• ”Är era DNS-inställningar skyddade mot manipulation?” är DNSSEC. Varje inställning i rapporten finns i DNS, så utan DNSSEC kan en angripare som kan påverka DNS-svar byta ut dem. Utan DNSSEC märks kortet Behöver åtgärdas. Be er DNS-leverantör aktivera det och publicera motsvarande DS-post hos registraren. Guiden om DNSSEC förklarar hur.
• ”Er logotyp i mottagarnas inkorgar (valfritt)” är BIMI. Det är en varumärkesfunktion, inte en säkerhetskontroll, och logotypen visas först när DMARC tillämpas med blockering. Vänta med den tills allt ovan är löst.

Hur är det med kontroller som inte kunde slutföras och de tekniska detaljerna?

Om någon kontroll blev Kunde inte fastställas listas den under ”Kontroller vi inte kunde slutföra”. Kontrollerna gav inget svar och är därför varken godkända eller underkända. En vanlig orsak är att någon av domänens namnservrar var långsam eller inte svarade. Kör kontrollen igen om ni behöver dem täckta.

Varje kort har också ett hopfällt avsnitt, ”Tekniska detaljer (på engelska)”, och rapporten avslutas med ”Tekniska bevis (på engelska)”. Båda är skrivna på engelska för den som hanterar er DNS: posterna som hittades, mottagarens bedömningar och den exakta rekommendationen. Skicka med dem tillsammans med åtgärderna i klartext när ni ber någon göra en ändring.