Så konfigurerar du SPF, DKIM och DMARC för Microsoft 365

Nästan alla svenska B2B-avsändare kör sin e-post via Microsoft 365, vilket gör SPF, DKIM och DMARC till skillnaden mellan att landa i inkorgen och att hamna i skräppost. Den här guiden går igenom exakt vilka poster du behöver, i vilken ordning du ska aktivera dem, och vilka misstag som oftast stjälper riktade cold email-kampanjer på just den här plattformen.

Varför Microsoft 365 kräver extra uppmärksamhet

Nästan alla svenska B2B-företag skickar sin e-post via Microsoft 365 (tidigare Office 365), vilket gör plattformen till en gemensam nämnare för både seriösa avsändare och de som missbrukar delad infrastruktur.

Eftersom Microsoft driver enorma delade IP-block använder Gmail, Outlook.com och andra mottagarsystem domänens egen autentisering – SPF, DKIM, DMARC – för att skilja legitim affärskommunikation från massutskick. Utan korrekt konfiguration hamnar även noggrant personaliserad B2B-outreach i skräppost, oavsett hur relevant mottagarlistan är.

Det här gäller särskilt riktade cold email-kampanjer mot specifika beslutsfattare, där varje enskilt mejl ska se ut som vanlig affärskorrespondens – inte som ett massutskick.

SPF: en enda TXT-post, men lätt att göra fel

Logga in hos er DNS-leverantör (Loopia, One.com, Binero, GoDaddy eller motsvarande) och lägg till en TXT-post på root-domänen. Grundposten för en domän som enbart skickar via Microsoft 365 är: v=spf1 include:spf.protection.outlook.com -all.

Problemet uppstår när fler tjänster skickar e-post för domänens räkning – ett CRM, ett faktureringssystem, en outreach-plattform som LDM. En domän får bara ha EN SPF-post totalt. Lösningen är att lägga alla include-satser i samma rad, inte skapa en ny post per tjänst.

• En domän = en SPF-post; lägg aldrig till en andra rad som börjar med "v=spf1"
• Inkludera varje tjänst som skickar e-post för domänens räkning i samma post
• Håll koll på 10-lookup-gränsen – varje include räknas, och överskrider ni gränsen blir hela SPF-posten ogiltig
• Testa alltid syntaxen med ett valideringsverktyg innan ni sparar ändringen

DKIM: aktiveras i Microsoft 365, inte hos DNS-leverantören

DKIM för en anpassad domän i Microsoft 365 sköts från Microsoft 365 Defender (Mail flow → DKIM) eller Exchange admin center, inte genom att själv skapa TXT-poster med en nyckel. Microsoft genererar två CNAME-poster som ni sedan lägger till hos er DNS-leverantör.

Utan det här steget signeras er utgående e-post fortfarande med Microsofts standarddomän i bakgrunden, vilket räcker för grundläggande leverans men försvagar domänens egen trovärdighet gentemot mottagande system – särskilt viktigt när DMARC-policyn senare ska skärpas.

• Gå till Microsoft 365 Defender → E-postflöde → DKIM (eller Exchange admin center)
• Välj domänen och klicka på Aktivera – Microsoft genererar två CNAME-poster (selector1 och selector2)
• Lägg till selector1._domainkey och selector2._domainkey som CNAME hos er DNS-leverantör
• Vänta på DNS-propagering och klicka aktivera igen om det första försöket misslyckas
• Microsoft roterar signeringsnycklarna automatiskt ungefär var sjätte månad så länge funktionen är påslagen

DMARC: höj policyn stegvis, inte allt på en gång

DMARC-posten läggs som en TXT-post på _dmarc.dindomän.se och bygger vidare på SPF och DKIM genom att kräva att minst en av dem passerar OCH är alignad med avsändaradressens domän. Att sätta DMARC direkt till p=reject utan att ha läst rapporter i förväg är den vanligaste orsaken till att legitim e-post plötsligt slutar levereras.

Rätt ordning är att börja i observationsläge, läsa aggregatrapporterna (rua) för att se vilka avsändarkällor som faktiskt använder domänen, och först därefter skärpa policyn i takt med att allt fler källor är korrekt autentiserade.

• Vecka 1-4: p=none; rua=mailto:dmarc@dindomän.se – enbart övervakning, inga mejl blockeras
• Vecka 5-8: p=quarantine; pct=25 – en fjärdedel av icke godkänd trafik hamnar i skräppost som test
• Vecka 9-12: p=quarantine; pct=100 – om rapporterna är rena
• Vecka 13 och framåt: p=reject – full enforcement när ingen legitim källa längre fallerar

Vanliga misstag hos M365-domäner

De flesta autentiseringsproblem vi ser hos svenska B2B-domäner beror inte på tekniskt komplicerade fel, utan på ett fåtal återkommande misstag som är enkla att undvika om man vet vad man letar efter.

Det vanligaste är dubbla SPF-poster – ofta en kvarglömd rad från en tidigare leverantör som ingen tog bort. Näst vanligast är att en outreach-plattform eller ett marknadsföringsverktyg börjar skicka e-post för domänens räkning utan att någon uppdaterar SPF-inkluderingen, vilket gör att just den trafiken faller på SPF-kontrollen.

Checklista – så gör LDM det för kunders cold email-domäner

När en domän ska användas för riktad B2B-outreach separerar vi ofta avsändningen från huvuddomänens vanliga affärskorrespondens genom en dedikerad subdomän, med egna SPF-, DKIM- och DMARC-poster. Det innebär att en eventuell studsfrekvens- eller klagomålsspik i en kampanj aldrig smittar av sig på domänen som används för fakturor, avtal och kundsupport.

Volymen trappas alltid upp gradvis på en ny subdomän – en varmkörningsperiod på några veckor innan full kampanjvolym körs – samtidigt som DMARC-rapporterna bevakas löpande, inte bara vid uppsättningstillfället.

• Verifiera att SPF innehåller exakt en post med alla avsändarkällor inkluderade
• Bekräfta att DKIM är aktiverat och signerar med domänens egna selectorer, inte Microsofts standard
• Sätt DMARC i p=none med rua-rapportering innan någon kampanj skickas i skarpt läge
• Använd en dedikerad subdomän för cold outreach, separat från huvuddomänens vanliga e-post
• Trappa upp volymen gradvis och läs DMARC-rapporterna varje vecka under de första månaderna

Vanliga frågor