Mejl som kommer fram

Vad ni får ut av det här

Ni skickar en offert. Kunden hittar den aldrig, för den ligger i skräpposten. Eller så kommer inbjudan från företagets nya Nextcloud aldrig fram alls.

Båda felen har oftast samma orsak: mottagarens mejlserver kan inte kontrollera att mejlet verkligen kommer från ert företag. Gmail, Outlook och de andra stora tar hårdare på det för varje år. Den som skickar till Gmail måste i dag ha minst SPF eller DKIM på plats, och de som skickar stora volymer behöver alla tre.

När ni har gått igenom guiden har domänen SPF, DKIM och DMARC, ni vet hur ni kontrollerar att de fungerar, och era egna program skickar mejl på ett sätt som mottagarna litar på.

Det här behöver ni innan ni börjar

• Ett eget domännamn, till exempel foretaget.se, och en mejltjänst som skickar från det. Guiden Domän och mejl går igenom hur ni kommer dit.
• Inloggning där domänens DNS sköts. Det är inte alltid där ni köpte domänen: har ni pekat om namnservrarna till till exempel Cloudflare är det där ni ändrar.
• En lista över allt som skickar mejl i företagets namn. Mejlprogrammet, webbutiken, nyhetsbrevet, fakturaprogrammet, bokningssystemet. Det brukar bli fler än man tror.
• En adress som kan ta emot rapporter, till exempel dmarc@foretaget.se. Den behövs i DMARC-steget.

Tre saker, förklarade utan teknik

Tänk er att ni tar emot ett brev med företagets brevhuvud.

SPF är gästlistan. I domänens DNS står en lista över vilka servrar som får skicka mejl för foretaget.se. Mottagaren tittar på vilken server mejlet kom från och kontrollerar om den står på listan.

DKIM är sigillet. Den som skickar sätter en digital signatur på varje mejl, och den publika nyckeln för att kontrollera signaturen ligger i domänens DNS. Stämmer signaturen vet mottagaren två saker: att mejlet kommer från någon som har rätt att skicka för domänen, och att det inte har ändrats på vägen.

DMARC är instruktionen till mottagaren om vad den ska göra när gästlistan och sigillet inte stämmer: släppa igenom, lägga i skräpposten eller slänga. DMARC ger er dessutom rapporter om vem som skickar mejl i er domäns namn, vilket är det enklaste sättet att upptäcka att någon annan gör det.

Alla tre är textposter i DNS. Ni installerar ingenting.

SPF: en post, alla avsändare

SPF är en TXT-post på själva domänen (namnet @ eller tomt i de flesta kontrollpaneler). Den ser ut ungefär så här:

v=spf1 include:_vsp.oderland.com ~all

include: pekar på en lista som mejlleverantören själv håller uppdaterad. Värdet får ni av leverantören. Några exempel:

Leverantör	Värde att lägga till
Oderland	include:_vsp.oderland.com
Beebyte	include:_spf.beebyte.se
Google Workspace	include:_spf.google.com
Microsoft 365	include:spf.protection.outlook.com

Slutet på posten talar om vad som gäller för alla andra servrar. ~all betyder att de ska behandlas med misstanke, -all att de ska avvisas. Här går råden isär: Google rekommenderar ~all, medan Microsoft använder -all. Börja med ~all tills DMARC-rapporterna (se nedan) visar att alla avsändare finns med, och gå sedan över till -all om ni vill.

Den viktigaste regeln: en domän får bara ha en SPF-post. Skickar ni från både Oderlands mejl och en SMTP-tjänst för webbutiken slår ni ihop dem i samma post:

v=spf1 include:_vsp.oderland.com include:spf.exempeltjanst.com ~all

Två separata SPF-poster gör att båda blir ogiltiga. Det är det vanligaste felet av alla.

Posten får heller inte leda till mer än tio uppslag totalt, och varje include: räknas, liksom de uppslag som den i sin tur gör. Med tre eller fyra leverantörer brukar det gå bra. Har ni fler, se över om alla verkligen behövs.

Microsoft ger ett råd som är värt att följa även om ni inte använder deras tjänster: låt nyhetsbrev och andra massutskick gå från en underdomän, till exempel nyhetsbrev.foretaget.se, med en egen SPF-post. Då drabbar problem med utskicken inte den vanliga mejlen, och varje underdomän har sina egna tio uppslag.

DKIM: nyckeln från leverantören

DKIM-nyckeln skapas av den som skickar mejlet, inte av er. Er uppgift är att lägga in den i DNS. Hur det går till beror på leverantören:

• Oderland sköter DKIM utan att ni gör något, så länge mejlen bara skickas från Oderlands servrar och domänens DNS ligger hos dem. Posten syns i kontrollpanelen cPanel under Levererbarhet för e-post.
• Beebyte hanterar DNS och mejl i sin kundportal, och ligger domänens DNS hos dem kan pekarna för mejlet läggas in därifrån. Står DKIM-posten inte redan bland domänens DNS-pekare, fråga deras support vilket värde som gäller.
• Microsoft 365 kräver två CNAME-poster, selector1._domainkey och selector2._domainkey, med värden som ni hämtar i Microsoft Defender-portalen. Värdena är unika för ert konto, så kopiera dem därifrån i stället för från en guide.
• Google Workspace skapar nyckeln i administratörskonsolen, under Appar, Google Workspace, Gmail och Autentisera e-postadress. Ni lägger in den som en TXT-post, med standardinställningen på namnet google._domainkey.

Samma sak gäller varje SMTP-tjänst och nyhetsbrevstjänst ni använder: de ger er en eller två poster att lägga in, oftast under ett namn som slutar på ._domainkey. Lägg in exakt det de skriver.

DMARC: börja med att bara titta

DMARC är en TXT-post på namnet _dmarc. Börja med en som inte stoppar något, bara skickar rapporter:

v=DMARC1; p=none; rua=mailto:dmarc@foretaget.se

p=none betyder att mottagarna ska leverera som vanligt men skicka en rapport till adressen efter rua=. Rapporterna kommer som bifogade filer, oftast en om dagen från varje stor mejltjänst, och de visar vilka servrar som har skickat mejl i domänens namn och om SPF och DKIM stämde.

Låt det gå några veckor. Ser ni avsändare i rapporterna som ni känner igen men som inte klarar kontrollen, till exempel webbutiken, rätta SPF eller DKIM för dem. När rapporterna visar att allt ert eget mejl klarar sig kan ni skärpa policyn till p=quarantine, som lägger det som inte stämmer i skräpposten, och så småningom p=reject, som avvisar det.

Rapporterna är svåra att läsa för hand. Det finns gratisverktyg som sammanställer dem; Cloudflare har ett inbyggt för domäner vars DNS ligger där.

Så lägger ni in posterna

Hos de flesta svenska leverantörer ser det ut ungefär likadant. Hos Oderland loggar ni in i cPanel, klickar på DNS-Hantering och väljer Hantera vid domänen. Under Lägg till inlägg väljer ni typen TXT och klistrar in värdet. För DMARC finns ett eget val i samma meny, där ni fyller i policyn i ett formulär i stället för att skriva posten själva.

Hos Beebyte väljer ni domänen i kundportalen och lägger till posten bland domänens DNS-pekare.

Cloudflare

I Cloudflare går ni till domänen, sedan DNS och Records, och lägger till en post av typen TXT. TXT- och MX-poster kan aldrig gå via Cloudflares proxy, så där finns inget val att göra. Två saker till att hålla koll på:

• Har ni en A-post för en mejlserver, till exempel mail, ska den stå som DNS only (grått moln). Cloudflares proxy hanterar inte mejltrafik.
• Cloudflare har en funktion för DMARC-hantering som både kan lägga in posten och visa rapporterna i kontrollpanelen.

Ändringar i DNS kan ta från några minuter till ett dygn innan de syns överallt.

Era egna program: använd en SMTP-tjänst

Nextcloud, Vaultwarden, Odoo, Vikunja och de flesta andra program ni kör själva behöver kunna skicka mejl: inbjudningar, lösenordsåterställning, fakturor, påminnelser. Utan inställning skickar de ingenting alls, eller försöker skicka direkt från servern och hamnar i skräpposten.

Frestelsen är att installera en egen mejlserver. Gör inte det. En nyinstallerad server har ingen historik som avsändare, dess IP-adress kan ha använts för skräppost av någon tidigare kund hos VPS-leverantören, och många leverantörer spärrar dessutom port 25, som mejlservrar använder för att skicka till varandra. Att få en egen mejlserver betrodd är ett arbete i sig, och underhållet tar aldrig slut.

Använd i stället en SMTP-tjänst som är byggd för att skicka mejl från program, så kallade transaktionsmejl. Ni verifierar er domän hos tjänsten, lägger in de SPF- och DKIM-poster den ger er, och får ett användarnamn och lösenord (eller en API-nyckel) att lägga in i programmet. Välj gärna en tjänst med servrar i EU och ett personuppgiftsbiträdesavtal, eftersom mejlen innehåller namn och adresser.

Ett alternativ för låga volymer är att skicka via företagets vanliga mejlkonto hos Oderland, Microsoft 365 eller Google Workspace. Det fungerar, men flera av dem har begränsningar i hur många mejl som får skickas per dag och i hur program får logga in.

Inställningarna i programmet ser nästan alltid ut så här:

Fält	Vanligt värde
Server	Tjänstens SMTP-adress
Port	587 med STARTTLS, eller 465 med TLS
Användarnamn	Från tjänsten
Lösenord	Från tjänsten, sparat i lösenordshanteraren
Avsändare	En adress på er egen domän, till exempel noreply@foretaget.se

Kör ni programmet på en VPS, kontrollera först att porten inte är spärrad. DigitalOcean spärrar som standard både 25, 465 och 587 på alla servrar, så där fungerar inte ens en SMTP-tjänst på de vanliga portarna. Välj i så fall en tjänst som går att nå på en annan port eller via ett API, och se efter i tjänstens dokumentation vilka alternativ den har.

Avsändaradressen måste vara på den domän ni har verifierat hos tjänsten. Skickar Nextcloud som nextcloud@localhost spelar det ingen roll hur rätt SPF och DKIM är.

Testa

mail-tester.com är det enklaste sättet att se hur ett mejl uppfattas. Sidan visar en tillfällig adress; skicka ett vanligt mejl dit från det konto eller program ni vill testa, och klicka sedan på knappen för att se resultatet. Ni får ett betyg och en lista över vad som stämmer och vad som saknas, med SPF, DKIM och DMARC var för sig.

Testa varje avsändare för sig. Mejlprogrammet kan få fullt betyg medan webbutiken får tre av tio, eftersom de skickar via helt olika servrar.

Ett annat sätt är att skicka till ett Gmail-konto, öppna mejlet, klicka på Mer (tre punkter) bredvid Svara och välja Visa original. Överst står SPF, DKIM och DMARC med PASS eller FAIL.

Så här vet ni att det funkade

• mail-tester.com visar att SPF, DKIM och DMARC finns och stämmer för varje avsändare ni har.
• Det finns exakt en TXT-post som börjar med v=spf1 på domänen, och Visa original i Gmail visar PASS på alla tre.
• DMARC-rapporter börjar komma till adressen i rua= inom ett par dagar.
• Inbjudningar och lösenordsåterställning från era egna program kommer fram och hamnar i inkorgen.

Vanliga fel

Två SPF-poster. Någon har lagt till en ny post för nyhetsbrevet i stället för att lägga till i den befintliga. Slå ihop dem till en enda.

Webbutiken eller nyhetsbrevet saknas i SPF. Allt från mejlprogrammet kommer fram, men orderbekräftelserna gör det inte. Gå tillbaka till listan över allt som skickar mejl och kontrollera att varje avsändare finns med.

DKIM-posten är avklippt. Nycklarna är långa, och vissa kontrollpaneler bryter dem eller lägger till citattecken. Kopiera värdet exakt som leverantören visar det, och jämför efteråt tecken för tecken med vad DNS faktiskt svarar.

Posterna ligger hos fel leverantör. Ni har lagt in dem där domänen är köpt, men namnservrarna pekar någon annanstans. Ändringarna syns då aldrig. Kontrollera vilka namnservrar domänen har och gör ändringarna där.

p=reject för tidigt. DMARC skärptes innan alla avsändare var på plats, och nu avvisas fakturorna från bokföringsprogrammet. Gå tillbaka till p=none, läs rapporterna och rätta innan ni skärper igen.

Vidarebefordrade mejl hamnar i skräpposten. När en adress vidarebefordrar automatiskt till en annan kommer mejlet från en server som inte står i avsändarens SPF. DKIM brukar klara sig, men inte alltid. Använd hellre en riktig brevlåda eller ett alias hos samma leverantör än vidarebefordran till en annan tjänst.

Nästa steg

Gå igenom listan över allt som skickar mejl i företagets namn en gång om året. System tillkommer, byts ut och läggs ner, och SPF-posten ska följa med.

Kör ni egna program på en server, se till att de nås via HTTPS innan ni börjar skicka inbjudningar med länkar i. Guiden HTTPS med Caddy eller Traefik visar hur.