---
title: "SPF, DKIM og DMARC: komplet guide til e-mailautentificering"
description: "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."
url: https://tajo.io/dk/blog/spf-dkim-dmarc-guide/
markdown: https://tajo.io/dk/blog/spf-dkim-dmarc-guide.md
lang: da-DK
author: "Set Noa"
author_url: https://tajo.io/dk/set-noa/
published: 2026-03-08
updated: 2026-05-12
alternates: {en-US: /blog/spf-dkim-dmarc-guide.md, bg-BG: /bg/blog/spf-dkim-dmarc-guide.md, cs-CZ: /cz/blog/spf-dkim-dmarc-guide.md, de-DE: /de/blog/spf-dkim-dmarc-guide.md, es-ES: /es/blog/spf-dkim-dmarc-guide.md, fr-FR: /fr/blog/spf-dkim-dmarc-guide.md, el-GR: /gr/blog/spf-dkim-dmarc-guide.md, hi-IN: /hi/blog/spf-dkim-dmarc-guide.md, id-ID: /in/blog/spf-dkim-dmarc-guide.md, hr-HR: /hr/blog/spf-dkim-dmarc-guide.md, it-IT: /it/blog/spf-dkim-dmarc-guide.md, ja-JP: /jp/blog/spf-dkim-dmarc-guide.md, ko-KR: /kr/blog/spf-dkim-dmarc-guide.md, ar-SA: /ar/blog/spf-dkim-dmarc-guide.md, nl-NL: /nl/blog/spf-dkim-dmarc-guide.md, pl-PL: /pl/blog/spf-dkim-dmarc-guide.md, ro-RO: /ro/blog/spf-dkim-dmarc-guide.md, ru-RU: /ru/blog/spf-dkim-dmarc-guide.md, sv-SE: /se/blog/spf-dkim-dmarc-guide.md, zh-CN: /zh-cn/blog/spf-dkim-dmarc-guide.md, sl-SI: /sl/blog/spf-dkim-dmarc-guide.md, sr-Latn-RS: /sr/blog/spf-dkim-dmarc-guide.md, th-TH: /th/blog/spf-dkim-dmarc-guide.md, tr-TR: /tr/blog/spf-dkim-dmarc-guide.md, ur-PK: /ur/blog/spf-dkim-dmarc-guide.md, vi-VN: /vi/blog/spf-dkim-dmarc-guide.md, sk-SK: /sk/blog/spf-dkim-dmarc-guide.md}
---

[E-mail](https://tajo.io/dk/blog/?category=email)

# 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

Hvad er SPF, DKIM og DMARC?

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.

[Læs mere](https://tajo.io/dk/blog/spf-dkim-dmarc-guide/#hvorfor-e-mailautentificering-betyder-noget)

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:

| Protokol | Hvad den gør | Analogi |
| --- | --- | --- |
| SPF | Lister godkendte afsenderservere | Et firmabrevpapir med godkendte kontorer |
| DKIM | Signerer beskeder kryptografisk | Et vokssegl der beviser ægthed |
| DMARC | Sætter politik for fejl og rapportering | Instruktioner 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

| Mekanisme | Beskrivelse | Eksempel |
| --- | --- | --- |
| include: | Stol på et andet domænes SPF | include:spf.brevo.com |
| ip4: | Godkend specifik IPv4 | ip4:192.168.1.1 |
| ip6: | Godkend specifik IPv6 | ip6:2001:db8::1 |
| a | Tillad domænets A-record-IP’er | a |
| mx | Tillad domænets mailserver-IP’er | mx |
| ptr | Reverse DNS (forældet) | ptr:example.com |
| exists: | Betinget tjek | exists:%{i}.spf.example.com |

**Qualifiers:** Definerer hvordan matches håndteres

| Qualifier | Betydning | Resultat |
| --- | --- | --- |
| + | Pass (standard) | Godkendt |
| - | Fail (hard) | Uautoriseret, afvis |
| ~ | SoftFail | Uautoriseret, acceptér men markér |
| ? | Neutral | Ingen 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:

| Udbyder | SPF-include |
| --- | --- |
| Brevo | include:spf.brevo.com |
| Google Workspace | include:\_spf.google.com |
| Microsoft 365 | include:spf.protection.outlook.com |
| Amazon SES | include:amazonses.com |
| SendGrid | include:sendgrid.net |
| Mailgun | include: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:

```bash
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...
```

| Tag | Beskrivelse | Eksempel |
| --- | --- | --- |
| 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:

```bash
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;
```

| Tag | Betydning |
| --- | --- |
| 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.

*How DMARC decides what happens to a message*

### 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:**

| Mode | Beskrivelse |
| --- | --- |
| 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 `marketing@example.com`, 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:dmarc@example.com; pct=100
```

**Påkrævede tags:**

| Tag | Beskrivelse | Værdier |
| --- | --- | --- |
| v= | Version | DMARC1 (altid) |
| p= | Politik | none, quarantine, reject |

**Valgfrie tags:**

| Tag | Beskrivelse | Standard |
| --- | --- | --- |
| rua= | Adresse til aggregate reports | none |
| ruf= | Adresse til forensic reports | none |
| pct= | Procentdel hvor politik anvendes | 100 |
| sp= | Subdomænepolitik | samme som p= |
| adkim= | DKIM-alignment mode | r (relaxed) |
| aspf= | SPF-alignment mode | r (relaxed) |
| fo= | Forensic report-indstillinger | 0 |
| 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:dmarc@example.com
```

**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:dmarc@example.com; 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:dmarc@example.com; 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:dmarc-reports@yourdomain.com
```

**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:

```xml
<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:

```bash
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:dmarc@yourdomain.com
```

## 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:address@domain.com`.
- 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:**

```bash
# 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.

## 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.

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.

## Hvor Tajo passer ind

Tajo er den agentiske integrationsbygger. Behold dine udbydere. Agenter forbinder alt det andet, og du godkender hver synkronisering. Tajo er i tidlig adgang. [Anmod om tidlig adgang](https://tajo.io/dk/#early-access)

## Ofte Stillede Spørgsmål

**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.

**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 virkelig brug for alle tre (SPF, DKIM og DMARC)?**

For den bedste leveringsevne og sikkerhed: ja. SPF alene er sårbar over for spoofing. DKIM alene fastlægger ingen politik. DMARC kræver SPF eller DKIM for at fungere. Sammen giver de fuld beskyttelse og den bedste placering i indbakken.

**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.

## Relaterede artikler

### [E-mail blacklist-tjek: Komplet guide til opdagelse, fjernelse og forebyggelse](https://tajo.io/dk/blog/email-blacklist-check-guide/)

8\. mar. 2026 · 12 min læsetid

9 afsnit

### [E-mailleveringsevne: komplet guide til indbakkeplacering \[2026\]](https://tajo.io/dk/blog/email-deliverability-complete-guide/)

8\. mar. 2025 · 13 min læsetid

13 afsnit

### [Hvad er en MCP-server? Sådan virker MCP og MCP UI i 2026](https://tajo.io/dk/blog/what-is-an-mcp-server/)

3\. okt. 2026 · 14 min læsetid

Trin 1 → Trin 6