SPF, DKIM, DMARC: så konfigurerar du e-postautentisering för cold email

En cold email-kampanj som skickas från en domän utan korrekt SPF, DKIM och DMARC hamnar förr eller senare i skräpposten, oavsett hur bra texten är. Gmail, Outlook och andra stora leverantörer använder dessa tre DNS-poster för att avgöra om ett mejl faktiskt kommer från den avsändare det påstår sig vara — och för B2B-avsändare som skickar till nya mottagare varje dag är marginalen för fel liten. Den här guiden går igenom vad varje post gör, hur du sätter upp den korrekt, och vilka misstag som oftast sänker leveransgraden.

Varför SPF, DKIM och DMARC avgör om cold email når fram

Stora e-postleverantörer som Google och Microsoft har byggt sina spamfilter kring en enkel princip: ett mejl utan verifierbar autentisering behandlas som misstänkt, oavsett innehåll. Det gäller särskilt cold email, där mottagaren aldrig tidigare fått ett meddelande från avsändaren och där algoritmen inte har någon relationshistorik att luta sig mot.

SPF, DKIM och DMARC är de tre DNS-baserade mekanismer som tillsammans bevisar att ett mejl verkligen kommer från den domän det påstår sig representera, och att innehållet inte manipulerats på vägen. Utan dem kan vem som helst skicka mejl som ser ut att komma från din domän — vilket är exakt det beteende som spamfilter är byggda för att stoppa.

För ett B2B-företag som skickar riktade mejl till namngivna kontaktpersoner på specifika bolag är detta inte en teknisk detalj utan en förutsättning. En kampanj med perfekt personalisering och relevant ämnesrad landar ändå i skräpposten om domänen saknar korrekt spf dkim dmarc-konfiguration.

SPF: vem får skicka e-post å din domäns vägnar

SPF (Sender Policy Framework) är en textpost i DNS som listar vilka mailservrar som har tillåtelse att skicka mejl från din domän. När en mottagarserver tar emot ett mejl kontrollerar den avsändarens IP-adress mot din SPF-post — matchar den inte listan riskerar mejlet att markeras som förfalskat.

En typisk SPF-post för ett företag som använder både Google Workspace och ett cold email-verktyg ser ut ungefär så här: v=spf1 include:_spf.google.com include:sendgrid.net -all. Varje include pekar på en tjänsteleverantörs egna servrar, och -all i slutet säger till mottagaren att strikt avvisa allt som inte matchar listan.

Den vanligaste svagheten med SPF är att den bara har utrymme för tio DNS-uppslag (include-poster) innan den slutar fungera helt — ett fel som kallas 'too many DNS lookups' och som tyst gör hela posten ogiltig. Lägger du till fler verktyg över tid (CRM, kalenderbokning, cold email-plattform) är det lätt att gå över gränsen utan att märka det förrän leveransgraden redan sjunkit.

DKIM: den digitala signaturen som håller efter vidarebefordran

DKIM (DomainKeys Identified Mail) löser en svaghet SPF har: SPF kollar bara avsändarens IP, vilket gör den funktionslös så fort ett mejl vidarebefordras via en annan server. DKIM signerar istället själva mejlinnehållet med en privat nyckel, och mottagaren verifierar signaturen mot en publik nyckel som ligger i din DNS som en TXT-post.

Konfigurationen sker i två delar. Din e-postleverantör (Google Workspace, ett cold email-verktyg eller din SMTP-tjänst) genererar ett nyckelpar och ger dig en DNS-post att lägga till, till exempel selector1._domainkey.dittforetag.se med ett publikt nyckelvärde. Signeringen sker sedan automatiskt på varje utgående mejl.

Ett vanligt misstag är att bara aktivera DKIM för huvuddomänen men inte för de subdomäner som används i cold email-verktyget. Skickar du från mail.dittforetag.se måste den subdomänen ha sin egen DKIM-signering — ärvs inte automatiskt från huvuddomänen.

DMARC: policyn som knyter ihop SPF och DKIM

DMARC (Domain-based Message Authentication, Reporting and Conformance) bygger vidare på SPF och DKIM genom att kräva att minst en av dem stämmer överens (är 'aligned') med den domän mottagaren faktiskt ser i avsändarfältet — och genom att tala om för mottagarservern vad den ska göra om ingen av dem gör det.

En DMARC-post har tre policylägen: p=none (övervaka men agera inte), p=quarantine (skicka misstänkta mejl till skräppost) och p=reject (avvisa dem helt). För en ny domän är det klok praxis att börja på p=none i två till fyra veckor, läsa av rapporterna som genereras (RUA-rapporter skickas till en adress du anger i posten), och först därefter trappa upp mot quarantine och slutligen reject.

Att hoppa direkt till p=reject på en domän där SPF eller DKIM inte är helt korrekt konfigurerad är den vanligaste orsaken till att legitima cold email-kampanjer plötsligt slutar levereras alls — mejlen avvisas tyst av mottagarens server utan att avsändaren märker det förrän svarsfrekvensen kollapsar.

Vanliga misstag som stjälper autentiseringen

De flesta leveransproblem i cold email går tillbaka till ett litet antal återkommande fel snarare än till innehållet i själva mejlet.

• Flera SPF-poster på samma domän istället för en sammanslagen — DNS tillåter bara en, och en andra gör hela konfigurationen ogiltig
• SPF-posten passerar tiogränsen för DNS-uppslag efter att fler verktyg lagts till över tid
• DKIM aktiverad för huvuddomänen men glömd för den subdomän cold email-verktyget faktiskt skickar från
• DMARC satt till p=reject för tidigt, innan alla skickande system är verifierade och aligned
• Ingen mottagare angiven för DMARC-rapporter (RUA), vilket gör att problem upptäcks först när svarsfrekvensen redan fallit
• Att skicka cold email från huvuddomänen istället för en dedikerad subdomän, vilket exponerar hela företagets domänrykte för kampanjrisk

Checklista: så sätter LDM upp autentisering för nya kunder

Innan en enda cold email-kampanj går ut mot skarpa kontakter kontrollerar vi alltid att grunden är på plats — det är billigare att fixa en DNS-post än att reparera ett skadat domänrykte i efterhand.

För ett svenskt B2B-bolag, till exempel en tillverkare som Nordisk Ventilation AB som vill nå inköpschefer på entreprenadfirmor, sätter vi typiskt upp en dedikerad subdomän (mail.nordiskventilation.se) med egen SPF och DKIM, låter den värmas upp med gradvis ökande volym under tre till fyra veckor, och trappar DMARC-policyn stegvis medan RUA-rapporterna övervakas.

Vanliga frågor