Den kompletta utrullningen av e-postautentisering: SPF, DKIM och DMARC från noll till p=reject

E-post förblir den enskilt mest utnyttjade ingången till organisationer. Enligt Verizon Data Breach Investigations Report är nätfiske och förevändningar inblandade i majoriteten av alla social engineering-intrång, och de flesta av dessa börjar med en förfalskad avsändaradress. De tre DNS-baserade autentiseringsstandarderna — SPF, DKIM och DMARC — finns till för att göra förfalskning av din domän tekniskt detekterbar och, vid full efterlevnad, avvisningsbar.

Den här guiden är skriven för IT-chefer som behöver ta en verklig organisation — med nyhetsbrev, CRM, helpdesk, faktureringsprogramvara och en marknadsföringsplattform som alla skickar e-post "från" företagsdomänen — från noll e-postautentisering till en tvingande DMARC-policy på p=reject, utan att tappa ett enda legitimt meddelande på vägen. Räkna med att hela utrullningen tar 6–10 veckor i kalendertid, med bara några timmars praktiskt arbete per vecka.

Hur de tre protokollen hänger ihop

Innan du rör DNS, se till att den mentala modellen är rätt, eftersom de flesta misslyckade utrullningar beror på att man missförstår alignment.

• SPF (RFC 7208) publicerar, i DNS, listan över IP-adresser som får skicka e-post med din domän i SMTP-kuvertet (MAIL FROM).
• DKIM (RFC 6376) signerar varje meddelande kryptografiskt med en privat nyckel; den publika nyckeln publiceras i DNS. Mottagare verifierar signaturen för att bekräfta att meddelandet inte har ändrats och att det har auktoriserats av den signerande domänen.
• DMARC (RFC 7489) binder samman båda. Det säger till mottagare: "om ett meddelande påstår sig komma från min domän i det synliga From:-fältet, måste det klara SPF eller DKIM i alignment med den domänen — och här är vad du ska göra om det inte gör det, och här är vart du ska skicka rapporterna."

Verifieringsflödet hos den mottagande e-postservern ser ut så här:

            Inkommande meddelande som påstår From: billing@example.com
                                 |
              +------------------+------------------+
              |                                     |
        SPF-kontroll                           DKIM-kontroll
   Finns avsändarens IP i                Verifierar d=-signaturen
   example.coms SPF-post                 mot den publika DNS-nyckeln?
   för kuvertavsändaren?
              |                                     |
              +------------------+------------------+
                                 |
                          DMARC-alignment
        Matchar domänen som klarade kontrollen (kuvertdomän för SPF,
        d=-domän för DKIM) den synliga From:-domänen?
                                 |
              +------------------+------------------+
              |                                     |
         PASS: leverera                   FAIL: tillämpa policy
                                          p=none  -> leverera, rapportera
                                          p=quarantine -> skräppostmapp
                                          p=reject -> avvisa meddelande

Den avgörande detaljen: ett meddelande kan klara SPF och DKIM för en viss domän och ändå misslyckas med DMARC, eftersom DMARC kräver att den godkända domänen stämmer överens (aligns) med den From:-domän som dina användare faktiskt ser. Det är precis detta som stoppar en nätfiskare som signerar e-post med sin egen domäns DKIM-nyckel.

Fas 0 — Inventera varje legitim avsändare (vecka 1)

Den vanligaste orsaken till förlorad e-post under DMARC-utrullningar är en bortglömd sändningstjänst. Innan du publicerar något, bygg en sändarinventering. Intervjua marknadsförings-, sälj-, ekonomi- och HR-teamen, och kontrollera DNS för befintliga include:-mekanismer.

Typisk inventering för ett företag med 50 anställda:

Två tumregler från denna fas:

1. Allt som inte kan göra DKIM bör migreras för att skickas via en autentiserad relay (t.ex. din Workspace SMTP-relay eller en transaktionell leverantör som Postmark eller SES) istället för direkt från en webbserver.
2. Gissa inte. DMARC-övervakningsfasen nedan kommer att fånga upp det som intervjuerna missar — det är det den är till för.

Fas 1 — Publicera en korrekt SPF-post (vecka 1–2)

SPF är en TXT-post vid roten av din domän. Samla in include-mekanismerna från varje leverantörs dokumentation och slå ihop dem till en enda post — en domän måste ha exakt en SPF-post; två poster orsakar ett permanent fel (permerror) och inaktiverar SPF i praktiken.

example.com.  IN TXT  "v=spf1 include:_spf.google.com include:servers.mcsv.net include:_spf.hubspot.com ip4:203.0.113.25 ~all"

Viktiga beslut:

• Avsluta med ~all (softfail), inte -all, under utrullningen. DMARC behöver inte -all för att fungera, och -all kombinerat med en ofullständig inventering studsar legitim e-post omedelbart. Du kan strama åt till -all efter att övervakningen bekräftat att inventeringen är komplett.
• Håll dig under 10 DNS-uppslag. Varje include, a, mx och redirect-mekanism kostar ett uppslag; att överstiga tio är ett permerror enligt RFC 7208 §4.6.4. Räkna de nästlade uppslagen inuti varje include (Googles include kostar i sig tre). Om du är nära gränsen, använd SPF-plattning (flattening) försiktigt eller flytta bulkutskick till en underdomän.
• Använd ip4:/ip6: för servrar du kontrollerar istället för a:-mekanismer — de kostar inga uppslag.

Validera med en kontrollant (FortifyNets MX & email security tool visar SPF, DKIM och DMARC i ett svep) och med dig:

dig +short TXT example.com | grep spf1

Fas 2 — Aktivera DKIM överallt (vecka 2–3)

DKIM-konfiguration sker per leverantör, men följer alltid samma form: leverantören genererar ett nyckelpar, du publicerar den publika nyckeln vid selector._domainkey.example.com, och leverantören börjar signera.

• Google Workspace: Admin-konsol → Appar → Gmail → Autentisera e-post. Generera en 2048-bitars nyckel (1024-bitars nycklar anses svaga; NIST och M3AAWG rekommenderar båda 2048). Publicera TXT-posten, vänta på DNS-spridning, klicka på "Starta autentisering".
• Microsoft 365: Defender-portal → E-postautentiseringsinställningar → DKIM. Microsoft använder två CNAME-poster (selector1, selector2) som möjliggör automatisk nyckelrotation.
• Mailchimp, HubSpot, Zendesk etc.: varje har en guide för att "autentisera din domän" som ger dig 2–4 CNAME-poster.

Verifiera varje väljare (selector) efter publicering:

dig +short TXT google._domainkey.example.com
dig +short CNAME selector1._domainkey.example.com

Skicka sedan ett testmeddelande till en Gmail-adress, öppna "Visa original" och bekräfta att du ser DKIM: PASS with domain example.com — "with domain"-delen är den alignment som DMARC kommer att kontrollera.

Planera för nyckelrotation var 6–12:e månad. Leverantörer med CNAME-baserade uppsättningar roterar åt dig; för manuellt publicerade nycklar, lägg in en återkommande kalenderpost i säkerhetskalendern nu, eftersom ingen kommer ihåg det senare.

Fas 3 — DMARC i övervakningsläge (vecka 3–4)

Publicera en DMARC-post vid _dmarc.example.com med policyn p=none. Detta ändrar ingenting för leveransen — det aktiverar bara rapportering.

_dmarc.example.com.  IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1; adkim=r; aspf=r"

Vad varje tagg gör:

Praktiska noteringar:

• Använd en dedikerad brevlåda eller, ännu hellre, en DMARC-rapportprocessor — rårapporter är gzippad XML och anländer från varje stor mottagare dagligen. Gratisversioner av vanliga analysverktyg räcker för en enskild domän.
• Om rapportadressen ligger på en annan domän än den som övervakas, måste rapportdomänen publicera en post för verifiering av extern destination (RFC 7489 §7.1).
• Låt övervakningen köra minst två fulla veckor, helst fyra, så att månatliga jobb (fakturakörningar, styrelserapporter) syns i datan.

Fas 4 — Läs rapporterna och fixa det som misslyckas (vecka 4–6)

Samlingsrapporter besvarar tre frågor för varje sändande IP: hur mycket e-post, stämde SPF, stämde DKIM. Sortera i tre kategorier:

1. Aligned pass (SPF eller DKIM): hälsosamt. Huvuddelen av din Workspace/M365-e-post bör ligga här från dag ett.
2. Din tjänst, misslyckas med alignment: t.ex. CRM:et klarar DKIM men signerar med d=crm-provider.com. Fixa genom att slutföra leverantörens guide för domänautentisering så att den signerar med din domän. Denna kategori är din arbetskö för Fas 4.
3. Okända IP-adresser som misslyckas med allt: detta är förfalskning (eller vidaresändning). Du fixar inte detta — efterlevnad kommer att neutralisera det. Dess närvaro är affärsnyttan för hela detta projekt.

En legitim källa kommer att fortsätta misslyckas oavsett vad du gör: e-postlistor och vissa vidaresändare förstör SPF (ny sändande IP) och ibland DKIM (sidfot tillagd). ARC (RFC 8617) hjälper hos stora mottagare, men det ärliga svaret är att en liten kvarvarande felkvot (väl under 1%) är normalt och acceptabelt vid efterlevnad.

Fas 5 — Upptrappning till efterlevnad (vecka 6–10)

Hoppa aldrig direkt från p=none till p=reject. Använd pct-taggen för att trappa upp:

Vid varje steg, bevaka två signaler: samlingsrapporterna (aligned-pass-procent för kända sändare bör hålla sig platt) och helpdesken (ärenden om "kunder säger att mitt mejl studsade"). Återställning är en enkel DNS-ändring tillbaka till föregående steg och träder i kraft inom postens TTL — sätt TTL till 3600 sekunder under upptrappningen så att misstag blir billiga.

När du når p=reject, slutför jobbet:

• Lägg till en explicit underdomän-policy: sp=reject, om inte en underdomän avsiktligt skickar med lösare regler.
• Skydda parkerade domäner du äger men aldrig skickar ifrån: ge dem v=spf1 -all, en tom DKIM-policy och v=DMARC1; p=reject. Parkerade domäner är förfalskarens favoritmål.
• Överväg BIMI (varumärkeslogotyp i inkorgen) — det kräver tvingande DMARC, så du har precis låst upp det.

Snabbreferens för felsökning

Utrullningen i korthet

Skriv ut denna tabell i projektärendet; varje rad är en naturlig veckovis statusuppdatering för ledningen, och kolumnen för leverabel håller projektet ärligt om vad "klar" innebär i varje steg.

Bortom DMARC — MTA-STS och TLS-RPT

DMARC autentiserar vem som skickat ett meddelande; det säger ingenting om huruvida meddelandet reste krypterat. SMTP faller fortfarande tillbaka till klartext när TLS-förhandling misslyckas, och en aktiv angripare på nätverksvägen kan tvinga fram precis det felet. Två kompletterande standarder stänger gapet, och eftersom du redan är i DNS-konsolen är detta rätt vecka att distribuera dem.

MTA-STS (RFC 8461) låter din domän deklarera "leverera endast e-post till mig via autentiserad TLS". Det består av en DNS-post och en liten policyfil som serveras via HTTPS:

_mta-sts.example.com.  IN TXT  "v=STSv1; id=20260828T000000"

https://mta-sts.example.com/.well-known/mta-sts.txt:
  version: STSv1
  mode: testing
  mx: mail.example.com
  max_age: 86400

Kör läget: testing i två veckor, byt sedan till mode: enforce och höj max_age till 604800. MX-raderna måste matcha dina riktiga MX-värdnamn exakt — ett skrivfel här kastar tyst inkommande e-post i enforce-läge, vilket är anledningen till att teststadiet finns.

TLS-RPT (RFC 8460) är rapportkanalen för MTA-STS, precis som rua-rapportering är för DMARC:

_smtp._tls.example.com.  IN TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Sändare som misslyckas med att leverera via TLS berättar varför, dagligen, i maskinläsbar JSON. I praktiken är rapporterna tysta — vilket är precis den bekräftelse du vill ha innan du tillämpar efterlevnad.

Läsning av en samlingsrapport manuellt

Även med ett analysverktyg, läs en rårapport en gång så att datan slutar vara en svart låda. Inuti den gzippade XML-filen innehåller varje postblock tre saker som spelar roll:

<record>
  <row>
    <source_ip>198.51.100.7</source_ip>
    <count>412</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
</record>

Läs det som en mening: "198.51.100.7 skickade 412 meddelanden som påstod sig vara example.com; SPF stämde, DKIM gjorde det inte; under nuvarande policy vidtogs ingen åtgärd." Slå upp IP-adressen (omvänd DNS plus sändarens publicerade intervall) och du vet om denna rad är kategori 1, 2 eller 3 från Fas 4. Tio minuter med en rapport lär dig mer än någon rundtur i en instrumentpanel.

Governance — att hålla det vid efterlevnad

E-postautentisering är inte ett projekt med ett slutdatum; det är en liten stående förmåga. Baka in detta i den normala driften innan du stänger ärendet:

• Ändringskontroll i DNS: varje nytt SaaS-verktyg som "bara behöver skicka e-post som oss" går via dig, får DKIM korrekt uppsatt och läggs till i inventeringstabellen. Alternativet är att marknadsavdelningen registrerar sig för ett verktyg i november och dess e-post tyst hamnar i skräppost under din p=reject.
• Kvartalsvis granskning: femton minuter per kvartal för att skanna analysverktyget efter nya misslyckade källor. Boka in det.
• Övervakning av själva posterna: SPF-, DKIM- och DMARC-poster kan förstöras av en oskyldig DNS-migrering. Extern övervakning som larmar vid varje ändring av dessa poster — FortifyNets domänövervakning gör detta kontinuerligt — förvandlar en tyst regression till en åtgärd samma dag.
• Avslutande (offboarding): när en sändningstjänst avslutas, ta bort dess include- och DKIM-poster samma vecka. Gamla include-poster är både ett slöseri med uppslagsbudgeten och en risk i leveranskedjan: om leverantörens IP-rymd omfördelas kan den som ärver den skicka autentiserad e-post som du.

Slutlig checklista

• Sändarinventering granskad av marknadsföring, ekonomi, support
• Exakt en SPF-post, under 10 uppslag, slutar med ~all (sedan -all)
• DKIM 2048-bitars, verifierad per väljare, rotation schemalagd
• DMARC p=none med rua-rapportering, 2–4 veckors data granskad
• Alla legitima sändare aligned (kategori 2 tom)
• Upptrappning: quarantine 10% → 50% → 100% → reject, en vecka+ per steg
• sp=reject satt; parkerade domäner låsta
• Kör en fullständig FortifyNet-skanning för att bekräfta att posterna har bra betyg

Källor

• RFC 7208 — Sender Policy Framework (SPF)
• RFC 6376 — DomainKeys Identified Mail (DKIM)
• RFC 7489 — Domain-based Message Authentication, Reporting & Conformance (DMARC)
• M3AAWG Email Authentication Best Practices
• Google Workspace — Set up DMARC
• Microsoft 365 — Use DMARC to validate email
• Verizon Data Breach Investigations Report