SPF, DKIM og DMARC: komplet guide til e-mailautentificering

Få styr på e-mailautentificering med denne guide til SPF, DKIM og DMARC. Lær hvad hver protokol gør, hvordan du opsætter DNS-records, fejlfinder typiske problemer og forbedrer din e-mailleveringsevne.

SPF DKIM DMARC
SPF, DKIM og DMARC?

E-mailautentificering er fundamentet for pålidelig e-maillevering. Uden korrekt SPF-, DKIM- og DMARC-konfiguration når dine gennemtænkte e-mails måske aldrig frem til kundernes indbakker. I stedet ender de i spam eller bliver afvist helt.

Denne guide forklarer, hvad hver e-mailautentificeringsprotokol gør, viser DNS-opsætning trin for trin, gennemgår fejlfinding af almindelige problemer og viser, hvordan du verificerer, at konfigurationen virker.

Hvorfor e-mailautentificering betyder noget

E-mail blev designet i en tid, hvor sikkerhed ikke var det primære fokus. Den oprindelige SMTP-protokol har ingen indbygget kontrolmekanisme, der bekræfter, at en e-mail faktisk kommer fra den afsender, den udgiver sig for at komme fra. Den svaghed gør e-mailspoofing, phishingangreb og spam muligt.

E-mailautentificeringsprotokoller løser problemet ved at lade domæneejere angive:

  • Hvilke servere der må sende e-mail på deres vegne (SPF)
  • Kryptografisk bevis for at beskeder er ægte og uændrede (DKIM)
  • Hvad der skal ske med beskeder, der fejler autentificering (DMARC)

Forretningseffekten af dårlig autentificering

Uden korrekt e-mailautentificering får du:

  • Lavere leveringsevne: Store udbydere som Gmail, Microsoft og Yahoo filtrerer uautentificerede e-mails hårdere.
  • Højere spamrate: Dine legitime e-mails konkurrerer med spoofede beskeder, der bruger dit domæne.
  • Brandskade: Phishingangreb, der udgiver sig for at være dit brand, svækker kundernes tillid.
  • Omsætningstab: Marketingkampagner når ikke frem til abonnenter, der faktisk bad om at modtage dem.
  • Compliance-risiko: Flere regler og platformskrav forventer korrekt e-mailautentificering.

Autentificeringstriaden

SPF, DKIM og DMARC arbejder sammen som et samlet autentificeringssystem:

ProtokolHvad den gørAnalogi
SPFLister godkendte afsenderservereEt firmabrevpapir med godkendte kontorer
DKIMSignerer beskeder kryptografiskEt vokssegl der beviser ægthed
DMARCSætter politik for fejl og rapporteringInstruktioner til mistænkelige breve

Hver protokol dækker forskellige angrebsvinkler. SPF forhindrer uautoriserede servere i at sende som dig. DKIM forhindrer beskedændringer efter afsendelse. DMARC binder dem sammen og giver synlighed i autentificeringsresultater.

Forstå SPF (Sender Policy Framework)

SPF (Sender Policy Framework) er en DNS-baseret metode til e-mailautentificering, der angiver, hvilke mailservere der er godkendt til at sende e-mail på vegne af dit domæne.

Sådan fungerer SPF

Når en e-mail ankommer til en modtagende server, slår serveren afsenderdomænets SPF-record op. Derefter tjekker den, om IP-adressen, der sendte e-mailen, er listet som godkendt. Hvis IP’en matcher, består SPF. Hvis ikke, fejler SPF.

SPF-verificeringsprocessen:

  1. Du sender en e-mail fra din marketingplatform.
  2. Den modtagende server udtrækker dit domæne fra Return-Path (envelope sender).
  3. Serveren spørger DNS efter dit domænes SPF-record.
  4. Den sammenligner afsender-IP’en med den godkendte liste i SPF-recorden.
  5. Serveren registrerer resultatet som pass, fail, softfail eller neutral.

SPF-recordsyntaks

SPF-records publiceres som TXT-records i dit domænes DNS. Grundstrukturen er:

v=spf1 [mechanisms] [qualifier]all

Versionstag: Starter altid med v=spf1

Mekanismer: Definerer hvem der må sende

MekanismeBeskrivelseEksempel
include:Stol på et andet domænes SPFinclude:spf.brevo.com
ip4:Godkend specifik IPv4ip4:192.168.1.1
ip6:Godkend specifik IPv6ip6:2001:db8::1
aTillad domænets A-record-IP’era
mxTillad domænets mailserver-IP’ermx
ptrReverse DNS (forældet)ptr:example.com
exists:Betinget tjekexists:%{i}.spf.example.com

Qualifiers: Definerer hvordan matches håndteres

QualifierBetydningResultat
+Pass (standard)Godkendt
-Fail (hard)Uautoriseret, afvis
~SoftFailUautoriseret, acceptér men markér
?NeutralIngen politik

All-mekanismen: Bruges på alt, der ikke matcher tidligere mekanismer.

Eksempler på SPF-records

Grundopsætning med én e-mailudbyder:

v=spf1 include:spf.brevo.com -all

Dette godkender Brevo til at sende e-mail for dit domæne og afviser alle andre afsendere.

Flere e-mailtjenester:

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

Dette godkender Brevo, Google Workspace og Microsoft 365.

Med din egen mailserver:

v=spf1 ip4:203.0.113.10 include:spf.brevo.com -all

Dette godkender en bestemt IP-adresse (din server) plus Brevo.

Start med soft fail under test:

v=spf1 include:spf.brevo.com ~all

~all i stedet for -all markerer fejl, men afviser ikke. Det er nyttigt under den første opsætning.

Opsætning af SPF-records

Trin 1: Identificér dine afsendelseskilder

List alle tjenester, der sender e-mail fra dit domæne:

  • E-mailmarketingplatforme (Brevo, Mailchimp osv.)
  • Transaktionelle e-mailtjenester
  • CRM-systemer
  • Help desk-software
  • Firma-e-mail (Google Workspace, Microsoft 365)
  • Dine egne mailservere

Trin 2: Saml SPF-include-statements

Hver e-mailudbyder dokumenterer sit påkrævede SPF-include. Almindelige eksempler:

UdbyderSPF-include
Brevoinclude:spf.brevo.com
Google Workspaceinclude:_spf.google.com
Microsoft 365include:spf.protection.outlook.com
Amazon SESinclude:amazonses.com
SendGridinclude:sendgrid.net
Mailguninclude:mailgun.org

Trin 3: Opret din SPF-record

Kombinér alle includes i én record:

v=spf1 include:spf.brevo.com include:_spf.google.com -all

Trin 4: Tilføj DNS-recorden

I dit DNS-interface:

  • Type: TXT
  • Host/Name: @ (eller tomt felt for roddomænet)
  • Value: din komplette SPF-record
  • TTL: 3600 (eller standard)

Trin 5: Verificér recorden

Brug DNS-opslagsværktøjer:

Terminal window
dig TXT yourdomain.com

Eller brug onlineværktøjer som MXToolbox SPF Lookup.

SPF-begrænsninger og best practices

Grænsen på 10 DNS-opslag:

SPF har maksimalt 10 DNS-opslag. Hvert include: tæller som ét opslag, og inkluderede records kan have egne includes, der også tæller med. Hvis du overskrider grænsen, giver SPF permerror (permanent error), så alle tjek fejler.

Strategier til at holde dig under grænsen:

  • Brug IP-adresser direkte, når det er muligt (ip4: tæller ikke som opslag).
  • Konsolidér tjenester, der bruger samme udbyder.
  • Brug SPF-flattening-tjenester, som konverterer includes til IP-adresser.
  • Fjern ubrugte includes fra gamle tjenester.

Andre SPF-best practices:

  • Kun én SPF-record pr. domæne. Flere records skaber fejl.
  • Start med ~all (softfail) under opsætning, og skift til -all, når alt er bekræftet.
  • Opdatér SPF, når du skifter e-mailudbyder.
  • Brug ikke den forældede ptr-mekanisme.
  • Hold records så enkle som muligt.

Almindelige SPF-fejl

Flere SPF-records:

Wrong:
v=spf1 include:spf.brevo.com -all
v=spf1 include:_spf.google.com -all
Correct:
v=spf1 include:spf.brevo.com include:_spf.google.com -all

For mange DNS-opslag:

Hvis du har mange includes, skal du tjekke det samlede antal opslag. Brug SPF-analyseværktøjer til at sikre, at du er under 10.

Glemmer at opdatere efter skift af udbyder:

Når du skifter fra én e-mailtjeneste til en anden, skal du fjerne det gamle include og tilføje det nye.

Bruger +all:

Brug aldrig +all, fordi det godkender alle til at sende som dit domæne.

Forstå DKIM (DomainKeys Identified Mail)

DKIM (DomainKeys Identified Mail) tilføjer en kryptografisk signatur til dine e-mails og beviser, at beskeden stammer fra dit domæne og ikke blev ændret undervejs.

Sådan fungerer DKIM

DKIM bruger public key-kryptografi:

  1. Din e-mailudbyder genererer et offentligt/privat nøglepar.
  2. Du publicerer den offentlige nøgle i DNS.
  3. Udbyderen signerer udgående e-mails med den private nøgle.
  4. Modtagende servere henter din offentlige nøgle fra DNS.
  5. Serverne bruger den offentlige nøgle til at verificere signaturen.
  6. En gyldig signatur beviser ægthed og integritet.

Hvad DKIM signerer:

DKIM-signaturer dækker typisk specifikke headers og beskedens body:

  • From-header (påkrævet)
  • Subject-header
  • Date-header
  • Beskedens body
  • Andre headers efter konfiguration

Det forhindrer angribere i at ændre disse elementer efter afsendelse.

DKIM-recordstruktur

DKIM-records publiceres som TXT-records med et bestemt navneformat:

selector._domainkey.yourdomain.com

Selector er en unik identifikator, der lader dig have flere DKIM-nøgler. Forskellige e-mailtjenester bruger forskellige selectors, for eksempel brevo, google, s1 eller s2.

DKIM-recordindhold:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...
TagBeskrivelseEksempel
v=Version (altid DKIM1)v=DKIM1
k=Nøgletype (typisk rsa)k=rsa
p=Offentlig nøgle (base64)p=MIGfMA0…
t=Flags (valgfrit)t=s (strict mode)
h=Hashalgoritmer (valgfrit)h=sha256

Opsætning af DKIM

Trin 1: Generér DKIM-nøgler

Din e-mailudbyder genererer normalt nøgler for dig. I Brevo:

  1. Gå til Settings > Senders, Domains & Dedicated IPs
  2. Vælg dit domæne
  3. Gå til DKIM-sektionen
  4. Kopiér den DNS-record, du får vist

For selvhostede mailservere kan du generere nøgler med OpenSSL:

Terminal window
openssl genrsa -out private.key 2048
openssl rsa -in private.key -pubout -out public.key

Trin 2: Tilføj DKIM DNS-recorden

I DNS-administrationen:

  • Type: TXT
  • Host/Name: selector._domainkey (for eksempel brevo._domainkey)
  • Value: DKIM-recorden fra din udbyder
  • TTL: 3600

Trin 3: Aktivér DKIM-signering

Aktivér DKIM-signering for dit domæne i e-mailudbyderens indstillinger. Det fortæller udbyderen, at den skal signere udgående beskeder.

Trin 4: Verificér opsætningen

Send en testmail, og tjek headers for DKIM-Signature. Brug værktøjer som:

  • mail-tester.com
  • DKIM Validator
  • MXToolbox DKIM Lookup

DKIM-best practices

Brug 2048-bit nøgler:

Ældre 1024-bit nøgler betragtes som svage. Moderne sikkerhedsstandarder anbefaler mindst 2048-bit RSA-nøgler.

Rotér nøgler periodisk:

Det er ikke altid et krav, men årlig DKIM-nøglerotation er god sikkerhedspraksis. Tilføj den nye nøgle, før du fjerner den gamle, så du undgår huller.

Overvåg for kompromitterede nøgler:

Hvis din private nøgle kompromitteres, kan angribere signere beskeder som dig. Overvåg usædvanlige autentificeringsmønstre.

Brug forskellige selectors til forskellige tjenester:

Hver e-mailudbyder bør bruge sin egen selector. Det giver uafhængig nøglestyring og undgår konflikt med andre tjenester.

Tjek DNS-propagation:

DKIM-nøgler kan være lange. Sørg for, at din DNS-udbyder understøtter TXT-records med tilstrækkelig længde. Nogle udbydere kræver, at nøglen deles op i flere strenge.

Læsning af DKIM-headers

Når du modtager en e-mail, viser DKIM-Signature-headeren:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.com; s=brevo;
h=from:to:subject:date:message-id;
bh=base64hashofbody;
b=base64signature;
TagBetydning
v=Version (altid 1)
a=Algoritme (rsa-sha256 anbefales)
c=Canonicalization (relaxed tillader mindre ændringer)
d=Signerende domæne
s=Selector
h=Signerede headers
bh=Body-hash
b=Signatur

Forstå DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC bygger oven på SPF og DKIM for at give politikhåndhævelse og rapportering. Det fortæller modtagende servere, hvad de skal gøre, når autentificering fejler, og sender dig rapporter om autentificeringsresultater.

Sådan fungerer DMARC

DMARC tilføjer to vigtige funktioner:

  1. Politikhåndhævelse: Definér hvordan modtagere skal håndtere autentificeringsfejl.
  2. Rapportering: Modtag data om hvem der sender e-mail med dit domæne.

DMARC-verificeringsprocessen:

  1. En modtagende server får en e-mail, der påstår at komme fra dit domæne.
  2. Den tjekker SPF: matcher afsender-IP’en?
  3. Den tjekker DKIM: er signaturen gyldig?
  4. Den tjekker DMARC-alignment: matcher de autentificerede domæner From-headeren?
  5. Hvis alignment fejler, anvender den din DMARC-politik.
  6. Den sender dig aggregate og/eller forensic reports.

DMARC-alignment

DMARC kræver alignment mellem domænet i From-headeren og de domæner, der består SPF eller DKIM:

SPF-alignment: Domænet i Return-Path (envelope sender) skal matche eller være et subdomæne af From-header-domænet.

DKIM-alignment: Domænet i DKIM-signaturen (d=-tag) skal matche eller være et subdomæne af From-header-domænet.

Alignment modes:

ModeBeskrivelse
Strict (s)Kræver præcist domænematch
Relaxed (r)Subdomæner tilladt (standard)

Med relaxed alignment består en mail, hvis From-headeren viser [email protected], og DKIM signerer med brevo.example.com, fordi begge deler organisationsdomænet example.com.

DMARC-recordsyntaks

DMARC-records publiceres som TXT-records på _dmarc.yourdomain.com:

v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100

Påkrævede tags:

TagBeskrivelseVærdier
v=VersionDMARC1 (altid)
p=Politiknone, quarantine, reject

Valgfrie tags:

TagBeskrivelseStandard
rua=Adresse til aggregate reportsnone
ruf=Adresse til forensic reportsnone
pct=Procentdel hvor politik anvendes100
sp=Subdomænepolitiksamme som p=
adkim=DKIM-alignment moder (relaxed)
aspf=SPF-alignment moder (relaxed)
fo=Forensic report-indstillinger0
ri=Rapportinterval (sekunder)86400

DMARC-politikker forklaret

p=none (kun overvågning):

Ingen handling ved fejl. E-mails leveres normalt. Brug dette, mens du analyserer rapporter og retter autentificeringsproblemer.

v=DMARC1; p=none; rua=mailto:[email protected]

p=quarantine (spammappe):

Fejlede e-mails sendes til spam/junk. Det er et godt mellemtrin før fuld afvisning.

v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100

p=reject (blokér):

Fejlede e-mails afvises helt. Det giver maksimal beskyttelse, men sørg for at alle legitime kilder består først.

v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100

Opsætning af DMARC

Trin 1: Sørg for at SPF og DKIM virker

DMARC afhænger af SPF og DKIM. Verificér begge, før du tilføjer DMARC.

Trin 2: Start med overvågning (p=none)

Begynd med den mest tilladende politik for at indsamle data uden at påvirke levering:

v=DMARC1; p=none; rua=mailto:[email protected]

Trin 3: Tilføj DNS-recorden

I DNS-administrationen:

  • Type: TXT
  • Host/Name: _dmarc
  • Value: din DMARC-record
  • TTL: 3600

Trin 4: Analysér rapporter i 2-4 uger

DMARC aggregate reports ankommer dagligt som XML-filer. Rapporterne viser:

  • Hvilke IP’er der sendte e-mail med dit domæne
  • SPF- og DKIM-pass/fail-rater
  • DMARC-alignment-resultater
  • Modtagende serveres handlinger

Brug DMARC-rapportanalyse til at visualisere data:

  • DMARC Analyzer
  • Postmark DMARC
  • Valimail
  • dmarcian

Trin 5: Ret autentificeringsproblemer

Almindelige problemer i rapporter:

  • Legitime tjenester mangler i SPF
  • DKIM er ikke aktiveret for en afsendertjeneste
  • Tredjepartstjenester sender uden korrekt autentificering
  • Videresendelse bryder SPF-alignment

Trin 6: Håndhæv gradvist

Når legitime kilder består stabilt:

  1. Skift til p=quarantine; pct=10 (quarantine 10% af fejl).
  2. Øg pct til 25, 50, 75, 100.
  3. Skift til p=reject; pct=10.
  4. Øg til fuld afvisning.

Trin 7: Vedligehold og overvåg

Fortsæt med at gennemgå rapporter. Nye afsendelseskilder, udbyderskift eller konfigurationsdrift kan skabe autentificeringsfejl.

Forstå DMARC-rapporter

Aggregate reports (rua):

Daglige XML-resuméer, der viser:

  • Rapporterende organisation
  • Datointerval
  • Din publicerede politik
  • Autentificeringsresultater efter kilde-IP
  • E-mailvolumen

Eksempeluddrag:

<record>
<source_ip>203.0.113.10</source_ip>
<count>1250</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</record>

Forensic reports (ruf):

Individuelle beskeddetaljer ved fejl. Rapporterne er mere detaljerede, men følsomme for privatliv. Mange modtagere sender ikke forensic reports.

DMARC-best practices

Start altid med p=none:

Hvis du går direkte til reject, kan legitime e-mails blive blokeret. Overvåg først.

Brug en dedikeret e-mailadresse til rapporter:

DMARC-rapporter kan fylde meget. Brug en dedikeret adresse eller en tredjepartstjeneste.

Sæt subdomænepolitik (sp=):

Hvis du ikke sender e-mail fra subdomæner, kan du sætte sp=reject for at beskytte dem mod spoofing.

Brug procent (pct=) til gradvis udrulning:

pct-tagget lader dig håndhæve politikken på en procentdel af fejl, mens resten overvåges.

Overvej dedikerede DMARC-tjenester:

For større organisationer giver tjenester som Valimail, dmarcian eller Postmark DMARC bedre rapportanalyse end rå XML-filer.

DNS-recordopsætning: komplet gennemgang

Opsætning af e-mailautentificering kræver, at du tilføjer specifikke DNS-records. Dette afsnit gennemgår de største DNS-udbydere.

Saml de påkrævede værdier

Før du starter, skal du hente disse værdier fra dine e-mailudbydere:

Til SPF:

  • Alle include-statements, for eksempel include:spf.brevo.com
  • Eventuelle specifikke IP-adresser, du skal godkende

Til DKIM:

  • Selector-navnet, for eksempel brevo, google eller s1
  • Den fulde DKIM-nøgleværdi

Til DMARC:

  • Din rapporteringsadresse

Tilføj records hos almindelige DNS-udbydere

Cloudflare:

  1. Log ind i Cloudflare Dashboard.
  2. Vælg dit domæne.
  3. Gå til DNS > Records.
  4. Klik Add Record.
  5. Til SPF: Type=TXT, Name=@, Content=din SPF-record.
  6. Til DKIM: Type=TXT, Name=selector._domainkey, Content=DKIM key.
  7. Til DMARC: Type=TXT, Name=_dmarc, Content=DMARC record.
  8. Klik Save.

Google Domains/Squarespace:

  1. Gå til DNS-indstillingerne for dit domæne.
  2. Scroll til Custom Records.
  3. Klik Manage Custom Records.
  4. Tilføj hver record med korrekt type, host og data.
  5. Til SPF: Host=@, Type=TXT, Data=SPF record.
  6. Til DKIM: Host=selector._domainkey, Type=TXT, Data=DKIM key.
  7. Til DMARC: Host=_dmarc, Type=TXT, Data=DMARC record.

GoDaddy:

  1. Gå til My Products > Domains.
  2. Klik DNS ud for dit domæne.
  3. Scroll til Records-sektionen.
  4. Klik Add for hver ny record.
  5. Vælg TXT som Type.
  6. Angiv Name (@ til SPF, selector._domainkey til DKIM, _dmarc til DMARC).
  7. Angiv Value.
  8. Gem.

Namecheap:

  1. Gå til Domain List > Manage.
  2. Klik Advanced DNS.
  3. Tilføj New Record for hver record.
  4. Vælg TXT Record.
  5. Host: @ til SPF, selector._domainkey til DKIM, _dmarc til DMARC.
  6. Value: dit recordindhold.
  7. Gem alle ændringer.

DNS-propagation

Når du har tilføjet records, tager ændringer tid at propagere globalt. Det tager typisk:

  • 5-30 minutter før første synlighed
  • Op til 48 timer for fuld global propagation

Brug dig eller nslookup til at verificere:

Terminal window
dig TXT yourdomain.com
dig TXT selector._domainkey.yourdomain.com
dig TXT _dmarc.yourdomain.com

Eller brug onlineværktøjer som whatsmydns.net til at tjekke propagation globalt.

Eksempel på komplet opsætning

For et domæne, der bruger Brevo og Google Workspace:

SPF-record (TXT på @):

v=spf1 include:spf.brevo.com include:_spf.google.com -all

DKIM-record for Brevo (TXT på brevo._domainkey):

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA... [key from Brevo dashboard]

DKIM-record for Google (TXT på google._domainkey):

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BA... [key from Google Admin]

DMARC-record (TXT på _dmarc):

v=DMARC1; p=none; rua=mailto:[email protected]

Fejlfinding af almindelige problemer

Selv med omhyggelig opsætning kan e-mailautentificering fejle. Her er de mest almindelige problemer og løsninger.

SPF-fejlfinding

SPF-record ikke fundet:

Symptomer: SPF-tjek viser “none” eller “no record”.

Årsager:

  • Recorden er ikke tilføjet i DNS.
  • Recorden er tilføjet det forkerte sted (subdomæne i stedet for rod).
  • DNS-propagation er ikke færdig.

Løsninger:

  • Verificér recorden med dig TXT yourdomain.com.
  • Tjek feltet Name/Host. Det bør være @ eller tomt for roddomænet.
  • Vent på DNS-propagation (op til 48 timer).

SPF PermError (for mange opslag):

Symptomer: SPF-resultater viser “permerror”.

Årsager:

  • Mere end 10 DNS-opslag i SPF-recorden.
  • Includes med for mange indlejrede includes.

Løsninger:

  • Auditér dine includes, og fjern ubrugte.
  • Erstat includes med ip4:-entries, hvor det er muligt.
  • Brug SPF-flattening-tjenester.
  • Konsolidér tjenester hos færre udbydere.

SPF SoftFail eller Fail for legitim mail:

Symptomer: Legitime e-mails fejler SPF.

Årsager:

  • Afsendertjenesten mangler i SPF.
  • Der sendes fra en IP, som ikke er godkendt.
  • En relay ændrer envelope sender.

Løsninger:

  • Tilføj det manglende include for din afsendertjeneste.
  • Tjek hvilken IP der faktisk sendte e-mailen i headers.
  • Kontakt din e-mailudbyder for korrekte SPF-indstillinger.

Flere SPF-records:

Symptomer: SPF viser permerror eller tilfældige fejl.

Årsager:

  • To eller flere TXT-records indeholder v=spf1.

Løsninger:

  • Kombinér alle mekanismer i én SPF-record.
  • Slet dublerede SPF-records.

DKIM-fejlfinding

DKIM-signatur mangler:

Symptomer: Ingen DKIM-Signature-header i e-mails.

Årsager:

  • DKIM-signering er ikke aktiveret hos e-mailudbyderen.
  • Domæneverificering er ikke gennemført.
  • Afsendelse sker gennem en ikke-DKIM-sti.

Løsninger:

  • Aktivér DKIM i udbyderens indstillinger.
  • Gennemfør domæneverificeringen.
  • Tjek udbyderens dokumentation til DKIM-opsætning.

DKIM-verificering fejlede:

Symptomer: DKIM viser “fail” i autentificeringsresultater.

Årsager:

  • DNS-recorden er ikke publiceret eller er forkert.
  • Forkert selector bruges.
  • Nøglen i DNS matcher ikke signeringen.
  • Beskeden blev ændret undervejs.

Løsninger:

  • Verificér at DNS-recorden findes på selector._domainkey.domain.
  • Sammenlign selector i DKIM-Signature-headeren med DNS.
  • Generér nøgler igen, hvis du mistænker mismatch.
  • Tjek mailfiltre eller relays, der ændrer beskeder.

DKIM-nøgle for lang til DNS:

Symptomer: DKIM-record kan ikke gemmes, eller der opstår truncation-fejl.

Årsager:

  • 2048-bit nøgler overstiger længden for én TXT-record.
  • DNS-udbyderen har tegngrænser.

Løsninger:

  • Del nøglen i flere citerede strenge. Typisk håndterer DNS-udbyderen det automatisk.
  • Tjek om DNS-udbyderen understøtter lange TXT-records.
  • Brug 1024-bit nøgler midlertidigt, men kun som mindre sikker nødløsning.

Eksempel på opdelt DKIM-record:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
"...continuation of key..."

DMARC-fejlfinding

DMARC-alignment-fejl:

Symptomer: SPF og DKIM består, men DMARC fejler.

Årsager:

  • Det autentificerede domæne matcher ikke From-header-domænet.
  • Tredjepartsafsendertjenesten bruger sit eget domæne.
  • Envelope sender er fejlkonfigureret.

Løsninger:

  • Sørg for at din e-mailudbyder signerer med dit domæne (custom DKIM).
  • Konfigurér custom Return-Path/envelope sender.
  • Brug relaxed alignment mode (adkim=r; aspf=r).

Ingen DMARC-rapporter modtages:

Symptomer: Ingen aggregate reports ankommer.

Årsager:

  • rua-adressen er forkert.
  • E-mailadressen kan ikke modtage ekstern mail.
  • Rapporter lander i spam.
  • Modtagende servere sender ikke rapporter.

Løsninger:

  • Verificér rua-syntaks: rua=mailto:[email protected].
  • Test at rapportadressen kan modtage ekstern mail.
  • Tjek spamfolderen for rapporter.
  • Bemærk, at ikke alle modtagere sender DMARC-rapporter.

DMARC-record ikke fundet:

Symptomer: DMARC-tjek viser “no record”.

Årsager:

  • Recorden er publiceret det forkerte sted.
  • Forkert format bruges. Den skal være TXT på _dmarc-subdomænet.

Løsninger:

  • Recorden skal ligge på _dmarc.yourdomain.com.
  • Verificér med dig TXT _dmarc.yourdomain.com.

Generelle fejlfindingsværktøjer

Onlinevalidators:

  • MXToolbox (mxtoolbox.com) til SPF-, DKIM- og DMARC-opslag
  • Mail Tester (mail-tester.com) til testmail med fuld analyse
  • DMARC Analyzer til rapportvisualisering
  • Google Admin Toolbox til MX-, SPF- og DKIM-tjek

Kommandolinjeværktøjer:

Terminal window
# Check SPF
dig TXT yourdomain.com
# Check DKIM
dig TXT selector._domainkey.yourdomain.com
# Check DMARC
dig TXT _dmarc.yourdomain.com
# Check from specific DNS server
dig @8.8.8.8 TXT yourdomain.com

Analyse af e-mailheaders:

Tjek Authentication-Results-headeren i modtagne e-mails:

Authentication-Results: mx.google.com;
dkim=pass header.d=example.com header.s=brevo;
spf=pass smtp.mailfrom=example.com;
dmarc=pass action=none header.from=example.com

E-mailautentificering og Brevo

Brevo giver bred understøttelse af e-mailautentificering, så det er ligetil at konfigurere SPF, DKIM og DMARC for dine afsenderdomæner.

Opsætning af autentificering i Brevo

Trin 1: Tilføj dit domæne

  1. Log ind på din Brevo-konto.
  2. Gå til Settings > Senders, Domains & Dedicated IPs.
  3. Klik Add a Domain.
  4. Indtast dit domænenavn.

Trin 2: Konfigurér SPF

Brevo giver det SPF-include, du skal føje til DNS:

include:spf.brevo.com

Tilføj det til din eksisterende SPF-record, eller opret en ny:

v=spf1 include:spf.brevo.com -all

Trin 3: Konfigurér DKIM

Brevo genererer DKIM-nøgler automatisk. Kopiér den record, du får vist:

  1. Gå til domæneindstillingerne i Brevo.
  2. Find DKIM-sektionen.
  3. Kopiér DNS-recordens navn og værdi.
  4. Tilføj TXT-recorden i DNS.

Trin 4: Verificér konfigurationen

Brevo tjekker automatisk dine DNS-records. Grønne flueben viser, at konfigurationen virker.

Fordele ved korrekt Brevo-autentificering

Når du konfigurerer autentificering korrekt med Brevo:

  • Bedre indbakkeplacering: Gmail, Microsoft og andre udbydere stoler mere på autentificerede beskeder.
  • Brandbeskyttelse: DMARC forhindrer spoofing af dit domæne.
  • Bedre analyser: Mere præcis tracking af åbninger og klik.
  • Opbygning af omdømme: Stabil autentificering styrker afsenderomdømmet.

Fordele ved Tajo-integration

Når du bruger Tajo til at forbinde din Shopify-butik med Brevo, får du yderligere fordele:

  • Automatisk kundesynkronisering: Kundedata flyder sømløst til personaliserede e-mails.
  • Eventtracking: Køb, browsing og kurvevents kan trigge autentificerede transaktionelle e-mails.
  • Multikanalkoordinering: Hold autentificeringen konsistent på tværs af e-mail, SMS og WhatsApp.
  • Samlet analyse: Følg e-mailperformance sammen med andre marketingmetrikker.

Kombinationen af korrekt e-mailautentificering og kundedatasynkronisering i realtid sikrer, at dine e-mails ikke bare når indbakken, men også føles relevante for hver modtager.

Ofte stillede spørgsmål

Hvad er forskellen på SPF, DKIM og DMARC?

SPF angiver, hvilke servere der må sende e-mail for dit domæne. DKIM tilføjer en kryptografisk signatur, der beviser beskedens ægthed. DMARC sætter politik for, hvordan modtagere skal håndtere autentificeringsfejl, og giver rapportering. Alle tre arbejder sammen om komplet e-mailautentificering.

Har jeg brug for alle tre, SPF, DKIM og DMARC?

For optimal leveringsevne og sikkerhed, ja. SPF alene er sårbar over for spoofing. DKIM alene angiver ingen politik. DMARC kræver SPF eller DKIM for at fungere. Sammen giver de omfattende beskyttelse og de bedste muligheder for indbakkeplacering.

Hvor lang tid tager det, før e-mailautentificering virker?

DNS-ændringer propagerer typisk inden for 30 minutter til 48 timer. Når de er propageret, gælder autentificeringen med det samme. Men opbygning af afsenderomdømme baseret på stabil autentificering tager uger til måneder.

Vil DMARC med p=reject blokere mine legitime e-mails?

Det kan ske, hvis konfigurationen er forkert. Derfor bør du altid starte med p=none (overvågning), analysere rapporter i 2-4 uger, rette fejl og derefter gradvist gå til quarantine og reject. Spring ikke overvågningsfasen over.

Hvad er SPF-alignment vs DKIM-alignment?

Alignment betyder, at det autentificerede domæne matcher det synlige From-header-domæne. SPF-alignment sammenligner Return-Path-domænet. DKIM-alignment sammenligner det signerende domæne (d=-tag). DMARC kræver, at mindst én af dem aligner.

Kan jeg have flere DKIM-nøgler for ét domæne?

Ja. Hver e-mailtjeneste kan bruge en forskellig selector, for eksempel brevo._domainkey eller google._domainkey. Det lader flere tjenester signere uafhængigt med DKIM. Der er ingen praktisk grænse for antallet af DKIM-selectors.

Hvorfor går mine e-mails stadig i spam efter autentificering?

Autentificering er nødvendig, men ikke nok til indbakkeplacering. Andre faktorer er afsenderomdømme, indholdskvalitet, engagementrater og listehygiejne. Autentificering får dig forbi det første filter. Gode praksisser afgør den endelige placering.

Hvordan læser jeg DMARC aggregate reports?

DMARC aggregate reports er XML-filer. Brug værktøjer som dmarcian, Postmark DMARC eller DMARC Analyzer til at parse og visualisere dem. Værktøjerne viser, hvilke IP’er der sender e-mail som dit domæne, og deres pass/fail-rater.

Hvad sker der, hvis jeg overskrider SPF-grænsen på 10 opslag?

SPF returnerer en permanent error (permerror), og alle SPF-tjek fejler. Ret det ved at fjerne ubrugte includes, erstatte includes med IP-adresser hvor muligt eller bruge SPF-flattening-tjenester.

Skal jeg bruge -all eller ~all i min SPF-record?

Brug ~all (softfail), mens du tester og opbygger sikkerhed. Når du har bekræftet, at alle legitime kilder består, kan du skifte til -all (hard fail) for stærkere beskyttelse. Softfail markerer fejl, men afviser ikke. Hard fail tillader afvisning.

Hvor ofte bør jeg rotere DKIM-nøgler?

Der er ikke et strengt krav, men årlig rotation er god sikkerhedspraksis. Ved rotation skal du tilføje den nye nøgle først, vente på DNS-propagation, aktivere signering med den nye nøgle og derefter fjerne den gamle efter en overgangsperiode.

Har subdomæner brug for separat autentificering?

SPF: Ja, hvert subdomæne kræver sin egen SPF-record, hvis der sendes e-mail fra det. DKIM: Nøgler kan deles eller være separate pr. subdomæne. DMARC: Subdomæner arver parent-politikken, medmindre sp= er sat, eller subdomænet har sin egen DMARC-record.

Konklusion

E-mailautentificering med SPF, DKIM og DMARC er ikke længere valgfrit for virksomheder, der er afhængige af e-mailkommunikation. Protokollerne beskytter dit brand mod spoofing, forbedrer leveringsevnen og bygger den tillid, effektiv e-mailmarketing kræver.

Vigtige pointer:

  • SPF godkender afsenderservere via DNS.
  • DKIM beviser beskedægthed med kryptografiske signaturer.
  • DMARC håndhæver politik og giver synlighed gennem rapporter.
  • Start med overvågning (p=none), før du håndhæver afvisning.
  • Alle legitime afsendelseskilder skal være korrekt konfigureret.
  • Løbende overvågning forebygger konfigurationsdrift.

For e-handelsvirksomheder, der bruger Shopify, skaber kombinationen af korrekt e-mailautentificering og kundedata-integration gennem Tajo og Brevo et stærkt fundament. Dine transaktionelle e-mails når kunderne pålideligt, dine marketingkampagner får bedre indbakkeplacering, og dit brand er bedre beskyttet mod spoofingangreb.

Klar til at forbedre din e-mailleveringsevne? Start med at auditere din nuværende autentificeringsopsætning med værktøjerne i denne guide, og konfigurér derefter SPF, DKIM og DMARC systematisk efter trinene ovenfor.

Læs hvordan Tajo integrerer med Brevo for at give sømløs e-mailautentificering sammen med kundedatasynkronisering i realtid til din Shopify-butik.

Relaterede artikler

Frequently Asked Questions

Hvad er SPF, DKIM og DMARC?
SPF verificerer afsendende servere, DKIM tilføjer en digital signatur til e-mails, og DMARC fortæller modtagere, hvordan de skal håndtere uautentificerede beskeder. Sammen autentificerer de dine e-mails og beskytter mod spoofing.
Har jeg brug for alle tre, SPF, DKIM og DMARC?
Ja. Google og Yahoo kræver nu SPF og DKIM for alle afsendere og DMARC for afsendere, der sender over 5.000 e-mails om dagen. Alle tre samlet giver den bedste leveringsevne og sikkerhed.
Hvordan opsætter jeg SPF, DKIM og DMARC?
Tilføj DNS-records til dit domæne: SPF som en TXT-record med godkendte afsendere, DKIM som en TXT-record med din offentlige nøgle og DMARC som en TXT-record med din politik. Din e-mailplatform giver de konkrete værdier.

Subscribe to updates

strategy

Drop your email or phone number — we'll send you what matters next.

auto-detect
Få Brevo