Etikett: DNS-säkerhet

DNSSEC – så skyddar du din domän från manipulation

Domain Name System (DNS) är ett av internets mest grundläggande protokoll. Det fungerar som internets telefonkatalog och översätter domännamn till IP-adresser.

Varje gång du ansluter till ett domännamn litar du på att DNS ger dig rätt IP-adress. Men DNS utvecklades i en tid då internet var en vänligare plats och protokollet saknar mekanismer för att verifiera att svaret verkligen stämmer.

Jag ska ge ett exempel

Jag äger domänen learntodefend.se och sätter upp en DNS-server för den. Därefter kontaktar jag min registrar och anger vilka namnservrar som är ansvariga för domänen.

När någon vill besöka min webbplats börjar det med att klienten frågar en resolver efter IP-adressen till www.learntodefend.se. Resolvern frågar först en root-server, men den har inte svaret utan hänvisar istället till namnservrarna för toppdomänen .se.

Resolvern frågar en av .se-servrarna. Den vet inte heller IP-adressen till www.learntodefend.se, men den vet vilka namnservrar som är ansvariga för domänen.

Till slut skickas frågan till min DNS-server, som svarar med den korrekta IP-adressen.

Men tänk om du sitter på ett osäkert nätverk. En angripare kanske manipulerar DNS-trafiken och svarar på dina förfrågningar med falska IP-adresser.

Du tror att du besöker min webbplats, men i själva verket hamnar du på en fejkad sida.

Det kanske inte är hela världen om en angripare skapar en fejkad version av min blogg. Men tänk om det till exempel hade varit din banks webbplats.

I varje steg litar resolvern på att den får rätt information, men det finns inget sätt att verifiera detta. Det är här DNSSEC kommer in.

Vad är DNSSEC?

Domain Name System Security Extensions (DNSSEC) är ett komplement till DNS som gör det möjligt att verifiera att DNS-svar är rätt.

DNSSEC löser detta genom att komplettera svaren med digitala signaturer.

Såhär fungerar det

När man aktiverar DNSSEC så genererar DNS-servern kryptografiska nycklar:

En Key Signing Key (KSK)
En eller två Zone Signing Key (ZSK)

Zone Signing Keys används för att signera zonens DNS-poster. Den privata delen av nycklarna skyddas noga och lämnar aldrig DNS-servern.

Den publika delen publiceras som DNSKEY-poster i zonen och används för att verifiera signaturer.

Om du är osäker på hur asymmetrisk kryptering med privat och publik nyckel fungerar har jag skrivit en separat artikel: En enkel guide till kryptering och digitala signaturer.

Du kan enkelt se hur en signerad post ser ut genom att använda kommandot dig och lägga till växeln +dnssec:

Utan DNSSEC skulle svaret bara innehålla första raden, dvs IP-adressen. Med DNSSEC får vi även en RRSIG-post som innehåller signaturen för A-posten.

RRSIG-posten innehåller även en del metadata:

Fält	Beskrivning
IN	Klass (Internet)
RRSIG A	Den här signaturen gäller för A-posten
8	Algoritm (8 = RSA/SHA-256)
3	Antal etiketter i det signerade namnet. `www.learntodefend.se` har tre labels: * www * learntodefend * se
3600	TTL
20260312000000 (expires) 20260219000000 (inception)	Signaturen är giltig: Från: 2026-02-19 00:00:00 UTC Till: 2026-03-12 00:00:00 UTC
21120	Key tag
H7GNG9nghg0+JcGAooZemjxeqLA1JbcMb2soDMhWf483ho8Mqvh2Z1W4HlXvJ08bTwJ0vUi6iAs…	Signatur (base64-kodad)

Den långa base64-strängen är alltså signaturen för A-posten. Den har skapats med den privata delen av Zone Signing Key (ZSK) med key tag 21120.

Verifiera signaturen

För att verifiera signaturen behöver resolvern tillgång till den publika delen av nyckeln. Som jag skrev tidigare publiceras den som en DNSKEY-post. Du kan enkelt se dessa genom att använda kommandot dig och ange att du vill hämta poster av typen DNSKEY.

Med hjälp av den publika nyckeln kan resolvern verifiera RRSIG-posten och säkerställa att svaret är giltigt.

I DNSKEY-svaret ser vi två ZSK, en KSK och en RRSIG-post (den återkommer jag till strax).

Det är vanligt att ha två ZSK samtidigt under en period. Eftersom nycklarna roteras, publiceras den nya i förväg och börjar användas innan den gamla tas bort. På så vis kan man byta nyckel utan att något slutar fungera.

Även DNSKEY-posten innehåller en del intressant metadata:

Fält	Beskrivning
IN	Klass (Internet)
DNSKEY	Detta är en publik DNSSEC-nyckel
256 / 257	Flagga som anger typ av nyckel * 256 = ZSK (Zone Signing Key) * 257 = KSK (Key Signing Key)
3	Protokoll (alltid 3 för DNSSEC)
8	Algoritm (8 = RSA/SHA-256)
AwEAAcZUV/6k73tmMwVhcD5J0WU0qL+IfBZEB7gfBYJXNyu3TYt3Zxg7B63+8b1AURngCa5cJG6…	Publik nyckel (base64-kodad)

Genom att behandla DNSKEY-postens innehåll med en särskild algoritm (RFC 4034 Appendix B) kan man räkna fram ett 16-bitars värde som kallas key tag. Det är tack vare detta värde som resolvern vet vilken nyckel som ska användas för att validera signaturen i en RRSIG-post.

Men om en angripare kontrollerar zonen, kan den inte bara skapa egna nycklar?

Jo, om en angripare sätter upp en falsk DNS-server som den kontrollerar skulle den kunna skapa egna nycklar och signera falska svar. Därför räcker det inte att verifiera signaturen, utan vi måste även verifiera att själva nyckeln är rätt.

Det är här Key Signing Keys (KSK) kommer in i bilden.

När man aktiverar DNSSEC grupperas DNS-posterna efter typ i så kallade RRsets (Resource Record Sets). Ett RRset består av alla poster av samma typ och namn, till exempel alla MX-poster för en domän, eller alla DNSKEY-poster.

Det är dessa RRsets som signeras – inte varje enskild post individuellt.

De flesta RRsets i zonen signeras av den privata delen av ZSK (i denna bild den vita DNSKEY:n med ID 21120). Men DNSKEY-setet, alltså själva nycklarna, signeras av den privata delen av KSK (den grå DNSKEY:n med ID 12412).

Det betyder att om vi litar på KSK, då kan vi också lita på DNSKEY-setet, och därmed på ZSK.

Okej, men hur kan vi lita på KSK?

Nu börjar vi närma oss kärnan i DNSSEC, nämligen hur man bygger en chain of trust. Svaret är att förtroendet inte skapas i den egna DNS-servern – det skapas i föräldrazonen.

Man tar den publika delen av KSK och räknar ut ett hashvärde av denna. Detta hashvärde registreras sedan som en DS-post (Delegation Signer) i föräldrazonen, i detta fall .se.

DS-posten innehåller alltså inte själva nyckeln, utan bara ett kryptografiskt fingeravtryck av KSK.

För att se denna post kan vi återigen använda kommandot dig och ange att vi vill hämta poster av typen DS.

Posterna i bilden ovan ligger alltså i föräldrazonen .se. Och DS-postens key tag 12412 motsvarar key tag på vår KSK.

Postens värde är en hash av vår KSK och detta är enkelt att verifiera själv med verktyget dnssec-dsfromkey:

# Spara DNSKEY-poster till fil
> dig learntodefend.se DNSKEY > dnskey.txt

# Räkna ut hash från KSK i filen dnskey.txt
> dnssec-dsfromkey -f dnskey.txt learntodefend.se

learntodefend.se. IN DS 12412 8 2 8194D32EA0F45CCE32F11D3BB901D23D4B30DD02E1E994D56F37E7F8747A0DEB

Om vi tittar på svaret igen ser vi att även denna post är signerad med en RRSIG-post. Signaturen är skapad av en nyckel med key tag 65293, och eftersom signaturen kommer från föräldrazonen står det .se som signer istället för learntodefend.se.

Men var finns denna nyckel? Jo, den hittar vi genom att fråga föräldrazonen efter dess DNSKEY-poster.

Precis som i min egen zon är även föräldrazonens DNSKEY-poster signerade med en RRSIG-post. Och så fortsätter det hela vägen upp till root-zonen. På så sätt byggs en chain of trust – fiffigt värre!

Om du vill få en komplett översikt över DNSSEC-konfigurationen för din domän rekommenderar jag verktyget DNSViz.net, som både analyserar din zons konfiguration och skapar en överskådlig rapport:

Aktivera DNSSEC i praktiken

Nu när vi gått igenom hur DNSSEC fungerar tänkte jag visa hur man aktiverar det i praktiken.

Om din DNS-leverantör dessutom fungerar som din registrar är det oftast väldigt enkelt. I många fall räcker det att logga in i leverantörens portal och aktivera funktionen. Resten hanteras automatiskt:

DNSSEC aktiveras för zonen
ZSK och KSK genereras
Zonens RRsets signeras
En hash av den publika delen av KSK registreras i föräldrazonen som en DS-post

För domänen learntodefend.se använder jag Loopia både som DNS-leverantör och registrar. Då räcker det att logga in och klicka på ”Aktivera DNSSEC”.

Jag har även en annan domän där jag hanterar DNS via Cloudflare, medan Loopia fortfarande är min registrar. Där ser processen lite annorlunda ut.

Då behöver jag istället:

Logga in i Cloudflares portal och aktivera DNSSEC.

Eftersom Cloudflare inte är min registrar kan de inte uppdatera föräldrazonen automatiskt.
Cloudflare räknar då ut en hash av min KSK och skapar en DS-post som jag får kopiera.
Därefter loggar jag in hos Loopia, aktiverar DNSSEC och klistrar in DS-posten där.

Loopia registrerar DS-posten i .se-zonen och länkar ihop Cloudflares KSK med föräldrazonen.

Sammanfattning

Jag hoppas att den här genomgången har gjort att DNSSEC känns lite mindre mystiskt, och kanske till och med inspirerar några av er att aktivera det på er domän. DNSSEC är trots allt ett av de viktigaste protokollen för ett säkrare internet – men tyvärr något som hoppas över alldeles för ofta.

DNSSEC är egentligen inte särskilt svårt att använda. Absolut, en felaktig konfiguration kan få allvarliga konsekvenser (till exempel att resolvers slutar lita på dina DNS-svar), men så länge du är noggrann med att DS-posten registreras korrekt brukar de flesta DNS-servrar hantera resten automatiskt idag.

Har du egna erfarenheter av DNSSEC får du gärna dela med dig i kommentarerna.

2026-03-10

Skydda dig mot falska mejl med SPF, DKIM och DMARC

För att skydda din domän mot spam, phishing, spoofing och andra bluffmejl finns det tre tekniker du måste känna till: SPF, DKIM och DMARC.

Tillsammans ser de till att mejl som skickas i ditt namn verkligen kommer från dig, och skyddar mot att någon missbrukar din domän för bedrägerier.

I den här guiden går vi igenom hur varje teknik fungerar, hur du implementerar dem, och hur de samverkar till ett komplett skydd.

SPF – Vilka servrar som får skicka mejl

Sender Policy Framework (SPF) skyddar mejl mot förfalskning (även kallat spoofing). Tanken är enkel – du som ägare av en domän anger vilka servrar som får skicka mejl i ditt namn.

Du gör detta genom att lägga till en TXT-post i din DNS. I posten anger du de IP-adresser som får skicka mejl för din räkning.

v=spf1 ip4:40.92.0.0/15 -all

I exemplet ovan har jag lagt till en av de nätadresser som Microsoft 365 använder för att skicka mejl. Men Microsoft använder många olika adresser och istället för att behöva lägga till dessa manuellt kan du inkludera Microsofts färdiga SPF-post:

v=spf1 include:spf.protection.outlook.com -all

Här är en snabb förklaring av de vanligaste taggarna i en SPF-post:

Tagg	Betydelse
`v=spf1`	Anger vilken version som SPF-posten använder. Den här taggen ska alltid stå först.
`ip4:`	Specificerar en IPv4-adress, eller en nätadress som får skicka mejl från domänen.
`include:`	Används för att inkludera en annan domäns SPF-post.
`-all`	Anger vad som ska hända med mejl som inte matchar någon tillåten server: `-all` = neka `~all` = markera som misstänkt `?all` = låter mottagaren avgöra Den här taggen ska alltid stå sist.

Jag skriver att mejl kan ”blockeras”, ”flaggas” eller ”accepteras”, men det är viktigt att förstå att det inte är din SPF-post som bestämmer detta. SPF fungerar snarare som en rekommendation till mottagarens mejlserver.

Låt säga att företaget ”Fiffel & Båg” försöker göra ett bedrägeriförsök i ditt namn. Det finns inget som hindrar dem från att skicka ett mejl och ange din domän som avsändare. Det är först när mejlet når mottagarens server som SPF-kontrollen görs:

Servern kontrollerar vilken IP-adress mejlet skickades från.

Den läser din SPF-post i DNS.

Och den avgör om mejlet ska blockeras, flaggas eller accepteras utifrån resultatet.

Om du använder Microsoft 365 sköts detta automatiskt – du behöver bara lägga till SPF-posten i DNS.

Så aktiverar du SPF för din domän

För att implementera SPF behöver du bara lägga till en TXT-post i DNS. Hur du gör det beror på din DNS-leverantör, men principen är densamma.

Här är ett exempel från min post hos Loopia där jag har konfigurerat SPF för Microsoft 365. I Loopia loggar man in i kundzonen, klickar på det domännamn man vill konfigurera, väljer knappen ”DNS-editor” och lägger sedan till en ny post under ’@’.

💡 Tips: Glöm inte att även inkludera andra tjänster du använder för mejl, t ex verktyg för nyhetsbrev eller maillistor.

DKIM – Skriv under dina mejl digitalt

SPF är en bra grund, men för att få bästa möjliga skydd måste du även konfigurera DKIM.

Så här fungerar tekniken: du som ägare av en domän skapar ett nyckelpar (en privat och en publik nyckel). Den privata nyckeln är hemlig och finns bara på din mejlserver. Den publika nyckeln är, precis som det låter publik, och läggs upp som en TXT-post i din DNS (i formatet id._domainkey.dittföretag.com). På så vis kan alla ta del av den.

När du skickar mejl skapar mejlservern en signatur med den privata nyckeln och lägger till den i mejlet. När mottagaren får mejlet hämtar deras server den publika nyckeln från din DNS och verifierar signaturen. På så sätt kan mottagaren vara säker på att mejlet verkligen kommer från dig. Dessutom säkerställer signaturen att innehållet i mejlet inte blivit förändrat på vägen.

Så lägger du till DKIM-signering

Konfigurationen kan se lite olika ut beroende på vilken DNS- och mejlleverantör du använder. I mina exempel använder jag Loopia och Microsoft 365.

Logga in i Defender-portalen
Klicka på ”Email & collaboration” > ”Policies & rules” > ”Threat policies”
Skrolla ner till rubriken ”Rules” och klicka på ”Email authentication settings”

Klicka på fliken ”DKIM” och markera ditt domännamn i listan.
Klicka på ”Create DKIM keys”

När du klickar på ”Create DKIM keys” skapas ett nyckelpar automatiskt i bakgrunden. Exchange Online konfigureras med den privata nyckeln, medan den publika nyckeln görs tillgänglig via DNS.

Microsoft hanterar det här automatiskt, så du behöver inte lägga upp den publika nyckeln manuellt. Istället publiceras den under en domän som är unik för din tenant. Guiden visar sedan två CNAME-poster som du ska lägga till i din DNS för att peka på den publika nyckeln.

CNAME-post	Pekar på (exempel)
selector1._domainkey	selector1-learntodefend-se._domainkey.learntodefend.k-v1.dkim.mail.microsoft
selector2._domainkey	selector2-learntodefend-se._domainkey.learntodefend.k-v1.dkim.mail.microsoft

Logga in i Loopias kundzon och lägg till dessa poster

🛡️ Säkerhetstips: När man aktiverar DKIM i Defender-portalen genererar Microsoft nycklar som är 1024 bitar långa. Idag är best practice att använda 2048 bitar. Tyvärr går det inte att välja nyckellängd i webbgränssnittet men det går att göra om man roterar nycklarna med PowerShell.

Install-Module -Name ExchangeOnlineManagement
Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline
Rotate-DkimSigningConfig -Identity “learntodefend.se” -KeySize 2048

DMARC – Så hänger SPF, DKIM och DMARC ihop

DMARC samarbetar med SPF och DKIM för att upptäcka och rapportera försök att missbruka din domän.

Diagrammet nedan visar hur processen ser ut när ett mejl skickas och tas emot:

Även denna teknik är enkel. Du skapar en TXT-post i DNS med formatet _dmarc.dindomän.se.

När en mottagare får mejl från din domän kontrollerar deras server först SPF och DKIM. Om något inte stämmer läser servern din DMARC-post för att avgöra hur den ska hantera och rapportera mejlet.

None: gör ingenting, bara rapportera
Quarantine: lägg i skräppost
Reject: blockera

Därefter skickar mottagarens mejlserver tillbaka en rapport. På så sätt ser du snabbt om någon försöker missbruka din domän.

Så ställer du in din DMARC-policy

Precis som för SPF och DKIM så behöver du lägga till en TXT-post i DNS med namnet _dmarc.dindomän.se.

v=DMARC1;p=reject;rua=mailto:dmarc@learntodefend.se;

I det här exemplet har jag konfigurerat policyn (p) till “reject” och rapportering (rua) till dmarc@learntodefend.se

Få ut mer av dina DMARC-rapporter

När du lagt till din DMARC-post börjar mottagande servrar att skicka rapporter till den adress du angivit i rua-fältet.

Rapporterna kommer i XML-format och ser ut ungefär såhär:

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
  <report_metadata>
    <org_name>gmail.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>1234567890</report_id>
    <date_range>
      <begin>1730697600</begin>
      <end>1730783999</end>
    </date_range>
  </report_metadata>

  <policy_published>
    <domain>learntodefend.se</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>reject</p>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>

  <record>
    <row>
      <source_ip>192.0.2.15</source_ip>
      <count>24</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>learntodefend.se</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>learntodefend.se</domain>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>learntodefend.se</domain>
        <result>fail</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Här är en snabb förklaring av de viktigaste taggarna i rapporten:

Tagg	Förklaring
`<report_metadata>`	Anger vem som skickat rapporten och vilken tidsperiod den gäller.
`<policy_published>`	Din aktuella DMARC-konfiguration.
`<record>`	En eller flera resultat med IP-adress, antal mejl och om de klarade SPF/DKIM-kontrollerna.

Men ingen blir lycklig av att få dessa rapporter mejlade och behöva granska dem manuellt. För att verkligen dra nytta av DMARC behöver du ett verktyg som:

tar emot rapporterna automatiskt
sammanställer tydliga grafer och statistik
och skickar larm om någon försöker missbruka din domän

Det finns en mängd olika tjänster som gör detta, även en del gratisalternativ. För learntodefend.se använder jag URIports. I deras dashboard ser jag tydligt alla mejl som är skickade från min domän och om de klarat SPF/DKIM-kontrollerna:

I exemplet ovan ser du två testmejl. Ett giltigt som är skickat från min Microsoft 365-tenant, och ett fejkmejl som jag skickat med ett verktyg för att spoofa min domän.

Sammanfattning

Om du följer de här tipsen och aktiverar SPF, DKIM och DMARC så får du ett bra skydd mot falska mejl och bedrägerier.

Alla tre teknikerna arbetar tillsammans och kompletterar varandra, men det går så klart fint att börja med exempelvis SPF och sedan bygga på med DKIM och DMARC efter hand.

Finns det några risker med att aktivera SPF, DKIM och DMARC?

Ja, det finns en viss risk att giltiga mejl blir blockerade. Jag har arbetat på flera företag där vi använt SPF, DKIM och DMARC med en blockerande policy, och det vanligaste problemet är avsändare som konfigurerat SPF felaktigt (dvs att de skickar mejl från en IP-adress som inte finns med i deras SPF-post).

Men jag föredrar att dessa blockeras, och att jag får en rapport så att jag kan kontakta avsändaren och hjälpa dem rätta till felet. Hellre det än att blunda och släppa igenom felaktiga poster. I de flesta fall brukar avsändare bli glada när man hör av sig och vill hjälpa dem förbättra sin säkerhet.

Och tänk på att även om du har aktiverat SPF, DKIM och DMARC finns det nästan alltid möjlighet att lägga till undantag i mejlservern.

Det finns andra tekniker som också är värda att nämna – DANE, MTA-STS och TLS-RPT. De tillför ytterligare en nivå av skydd utöver SPF, DKIM och DMARC. Men jag återkommer till dem i en kommande bloggpost.

2025-11-16