---
title: "SPF, DKIM und DMARC: Der komplette Leitfaden zur E-Mail-Authentifizierung"
description: "Meistere E-Mail-Authentifizierung mit diesem umfassenden Leitfaden zu SPF, DKIM und DMARC. Lerne, was jedes Protokoll macht, wie du DNS-Records einrichtest, häufige Probleme behebst und deine E-Mail-Zustellbarkeit verbesserst."
url: https://tajo.io/de/blog/spf-dkim-dmarc-guide/
markdown: https://tajo.io/de/blog/spf-dkim-dmarc-guide.md
lang: de-DE
author: "Set Noa"
author_url: https://tajo.io/de/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, da-DK: /dk/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/de/blog/?category=email)

# SPF, DKIM und DMARC: Der komplette Leitfaden zur E-Mail-Authentifizierung

Meistere E-Mail-Authentifizierung mit diesem umfassenden Leitfaden zu SPF, DKIM und DMARC. Lerne, was jedes Protokoll macht, wie du DNS-Records einrichtest, häufige Probleme behebst und deine E-Mail-Zustellbarkeit verbesserst.

SPF DKIM DMARC

Was sind SPF, DKIM und DMARC?

SPF nennt erlaubte Absender, DKIM signiert E-Mails und DMARC legt den Umgang mit fehlgeschlagenen Prüfungen fest. Richte alle drei DNS-Einträge ein und teste sie.

[Mehr erfahren](https://tajo.io/de/blog/spf-dkim-dmarc-guide/#warum-e-mail-authentifizierung-wichtig-ist)

E-Mail-Authentifizierung ist die Grundlage verlässlicher E-Mail-Zustellung. Ohne korrekte SPF-, DKIM- und DMARC-Konfiguration erreichen sorgfältig erstellte E-Mails die Posteingänge deiner Kund:innen vielleicht nie. Stattdessen landen sie im Spam oder werden komplett abgelehnt.

Dieser umfassende Leitfaden erklärt, was jedes E-Mail-Authentifizierungsprotokoll macht, zeigt die DNS-Einrichtung Schritt für Schritt, behandelt häufige Probleme und zeigt, wie du prüfst, ob deine Konfiguration korrekt funktioniert.

## Warum E-Mail-Authentifizierung wichtig ist

E-Mail wurde in einer Zeit entworfen, in der Sicherheit kein Hauptanliegen war. Das ursprüngliche SMTP-Protokoll hat keinen eingebauten Prüfmechanismus, der bestätigt, dass eine E-Mail wirklich von der Person oder Domain kommt, die sie vorgibt. Diese grundlegende Schwäche ermöglicht E-Mail-Spoofing, Phishing-Angriffe und Spam.

E-Mail-Authentifizierungsprotokolle lösen dieses Problem, indem Domain-Inhaber:innen festlegen können:

- **Welche Server in ihrem Namen E-Mail senden dürfen** (SPF)
- **Kryptografischen Nachweis, dass Nachrichten echt und unverändert sind** (DKIM)
- **Was mit Nachrichten passiert, die die Authentifizierung nicht bestehen** (DMARC)

### Geschäftliche Folgen schwacher Authentifizierung

Ohne korrekte E-Mail-Authentifizierung:

- **Niedrigere Zustellbarkeit**: Große Anbieter wie Gmail, Microsoft und Yahoo filtern nicht authentifizierte E-Mails aggressiver.
- **Höhere Spam-Raten**: Deine legitimen E-Mails konkurrieren mit gespooften Nachrichten, die deine Domain nutzen.
- **Markenschaden**: Phishing-Angriffe, die deine Marke imitieren, schwächen das Vertrauen deiner Kund:innen.
- **Umsatzverlust**: Marketingkampagnen erreichen Abonnent:innen nicht, die sich aktiv dafür angemeldet haben.
- **Compliance-Risiken**: Viele Regelwerke verlangen inzwischen korrekte E-Mail-Authentifizierung.

### Die Authentifizierungs-Trias

SPF, DKIM und DMARC arbeiten als vollständiges Authentifizierungssystem zusammen:

| Protokoll | Was es macht | Analogie |
| --- | --- | --- |
| SPF | Listet autorisierte sendende Server auf | Firmenbriefkopf mit genehmigten Büros |
| DKIM | Signiert Nachrichten kryptografisch | Wachssiegel als Echtheitsnachweis |
| DMARC | Setzt Policy für Fehler und Reporting | Anweisung, was mit verdächtigen Briefen zu tun ist |

Jedes Protokoll adressiert andere Angriffsvektoren. SPF verhindert, dass nicht autorisierte Server als du senden. DKIM verhindert Manipulationen nach dem Versand. DMARC verbindet beides und gibt Sichtbarkeit in Authentifizierungsergebnisse.

## SPF verstehen (Sender Policy Framework)

SPF (Sender Policy Framework) ist eine DNS-basierte Methode zur E-Mail-Authentifizierung, die festlegt, welche Mailserver E-Mails im Namen deiner Domain senden dürfen.

### Wie SPF funktioniert

Wenn eine E-Mail bei einem empfangenden Server ankommt, fragt dieser Server den SPF-Record der Senderdomain ab. Danach prüft er, ob die IP-Adresse, die die E-Mail gesendet hat, als autorisiert gelistet ist. Wenn die IP passt, besteht SPF. Wenn nicht, schlägt SPF fehl.

**Der SPF-Prüfprozess:**

1. Du sendest eine E-Mail aus deiner Marketingplattform.
2. Der empfangende Server liest deine Domain aus dem Return-Path (Envelope Sender).
3. Der Server fragt DNS nach dem SPF-Record deiner Domain.
4. Er vergleicht die sendende IP mit der autorisierten Liste im SPF-Record.
5. Der Server speichert das Ergebnis: pass, fail, softfail oder neutral.

### SPF-Record-Syntax

SPF-Records werden als TXT-Records im DNS deiner Domain veröffentlicht. Die Grundstruktur:

```
v=spf1 [mechanisms] [qualifier]all
```

**Version-Tag:** Beginnt immer mit `v=spf1`

**Mechanismen:** Definieren, wer senden darf

| Mechanismus | Beschreibung | Beispiel |
| --- | --- | --- |
| include: | SPF einer anderen Domain vertrauen | include:spf.brevo.com |
| ip4: | Bestimmte IPv4 autorisieren | ip4:192.168.1.1 |
| ip6: | Bestimmte IPv6 autorisieren | ip6:2001:db8::1 |
| a | IPs des A-Records der Domain erlauben | a |
| mx | IPs der Mailserver der Domain erlauben | mx |
| ptr | Reverse DNS (veraltet) | ptr:example.com |
| exists: | Bedingte Prüfung | exists:%{i}.spf.example.com |

**Qualifier:** Definieren, wie Treffer behandelt werden

| Qualifier | Bedeutung | Ergebnis |
| --- | --- | --- |
| + | Pass (Standard) | Autorisiert |
| - | Fail (hart) | Nicht autorisiert, ablehnen |
| ~ | SoftFail | Nicht autorisiert, annehmen, aber markieren |
| ? | Neutral | Keine Policy |

**Der all-Mechanismus:** Wird auf alles angewendet, was nicht zu vorherigen Mechanismen passt.

### SPF-Record-Beispiele

**Grundsetup mit einem E-Mail-Anbieter:**

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

Das autorisiert Brevo, E-Mail für deine Domain zu senden, und lehnt alle anderen Sender ab.

**Mehrere E-Mail-Dienste:**

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

Das autorisiert Brevo, Google Workspace und Microsoft 365.

**Eigenen Mailserver einschließen:**

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

Das autorisiert eine bestimmte IP-Adresse (deinen Server) plus Brevo.

**Beim Testen mit Soft Fail starten:**

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

`~all` statt `-all` markiert Fehler, lehnt aber nicht ab. Das ist während der Ersteinrichtung nützlich.

### SPF-Records einrichten

**Schritt 1: Deine sendenden Quellen identifizieren**

Liste jeden Dienst auf, der E-Mail von deiner Domain sendet:

- E-Mail-Marketingplattformen (Brevo, Mailchimp usw.)
- Transaktionale E-Mail-Dienste
- CRM-Systeme
- Helpdesk-Software
- Unternehmens-E-Mail (Google Workspace, Microsoft 365)
- Eigene Mailserver

**Schritt 2: SPF-Include-Statements sammeln**

Jeder E-Mail-Service-Provider dokumentiert den erforderlichen SPF-Include. Häufige Beispiele:

| Anbieter | 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 |

**Schritt 3: SPF-Record erstellen**

Kombiniere alle Includes in einem Record:

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

**Schritt 4: DNS-Record hinzufügen**

In deiner DNS-Verwaltung:

- Type: TXT
- Host/Name: @ (oder leer lassen für die Root-Domain)
- Value: dein vollständiger SPF-Record
- TTL: 3600 (oder Standard)

**Schritt 5: Record prüfen**

Nutze DNS-Lookup-Tools zur Bestätigung:

```bash
dig TXT yourdomain.com
```

Oder nutze Online-Tools wie MXToolbox SPF Lookup.

### SPF-Grenzen und Best Practices

**Das Limit von 10 DNS-Lookups:**

SPF erlaubt maximal 10 DNS-Lookups. Jedes `include:` zählt als ein Lookup, und eingeschlossene Records können eigene Includes enthalten, die ebenfalls zählen. Wenn du das Limit überschreitest, entsteht ein SPF permerror (permanent error), wodurch alle Prüfungen fehlschlagen.

**Strategien, um unter dem Limit zu bleiben:**

- Nutze direkte IP-Adressen, wenn möglich (`ip4:` zählt nicht als Lookup).
- Konsolidiere Dienste, die denselben Anbieter nutzen.
- Nutze SPF-Flattening-Services, die Includes in IP-Adressen umwandeln.
- Entferne ungenutzte Includes alter Dienste.

**Weitere SPF-Best-Practices:**

- Nur ein SPF-Record pro Domain (mehrere Records verursachen Fehler).
- Starte während der Einrichtung mit `~all` (softfail) und wechsle zu `-all`, sobald alles bestätigt ist.
- Aktualisiere SPF, wenn du E-Mail-Anbieter wechselst.
- Nutze den veralteten `ptr`-Mechanismus nicht.
- Halte Records so einfach wie möglich.

### Häufige SPF-Fehler

**Mehrere 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
```

**DNS-Lookup-Limit überschreiten:**

Wenn du viele Includes hast, prüfe die Gesamtzahl deiner Lookups. Nutze SPF-Analyzer, um sicherzustellen, dass du unter 10 bleibst.

**Nach Anbieterwechsel nicht aktualisieren:**

Wenn du von einem E-Mail-Dienst zu einem anderen wechselst, entferne den alten Include und füge den neuen hinzu.

**+all verwenden:**

Nutze niemals `+all`, weil es allen erlaubt, als deine Domain zu senden.

## DKIM verstehen (DomainKeys Identified Mail)

DKIM (DomainKeys Identified Mail) fügt deinen E-Mails eine kryptografische Signatur hinzu. Diese Signatur beweist, dass die Nachricht von deiner Domain stammt und während der Übertragung nicht verändert wurde.

### Wie DKIM funktioniert

DKIM nutzt Public-Key-Kryptografie:

1. Dein E-Mail-Anbieter erzeugt ein öffentliches/privates Schlüsselpaar.
2. Du veröffentlichst den öffentlichen Schlüssel im DNS.
3. Der Anbieter signiert ausgehende E-Mails mit dem privaten Schlüssel.
4. Empfangende Server holen deinen öffentlichen Schlüssel aus DNS.
5. Empfangende Server nutzen den öffentlichen Schlüssel, um die Signatur zu prüfen.
6. Eine gültige Signatur beweist Authentizität und Integrität.

**Was DKIM signiert:**

DKIM-Signaturen decken typischerweise bestimmte Header und den Nachrichtentext ab:

- From-Header (erforderlich)
- Subject-Header
- Date-Header
- Nachrichtentext
- Weitere Header je nach Konfiguration

Das verhindert, dass Angreifer diese Elemente nach dem Versand verändern.

### DKIM-Record-Struktur

DKIM-Records werden als TXT-Records mit einem bestimmten Namensformat veröffentlicht:

```
selector._domainkey.yourdomain.com
```

Der **Selector** ist eine eindeutige Kennung, mit der du mehrere DKIM-Schlüssel haben kannst. Unterschiedliche E-Mail-Dienste nutzen unterschiedliche Selector (z. B. brevo, google, s1, s2).

**DKIM-Record-Inhalt:**

```
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...
```

| Tag | Beschreibung | Beispiel |
| --- | --- | --- |
| v= | Version (immer DKIM1) | v=DKIM1 |
| k= | Schlüsseltyp (meist rsa) | k=rsa |
| p= | Öffentlicher Schlüssel (base64) | p=MIGfMA0… |
| t= | Flags (optional) | t=s (strict mode) |
| h= | Hash-Algorithmen (optional) | h=sha256 |

### DKIM einrichten

**Schritt 1: DKIM-Schlüssel erzeugen**

Dein E-Mail-Service-Provider erzeugt Schlüssel normalerweise für dich. In Brevo:

1. Gehe zu Settings > Senders, Domains & Dedicated IPs
2. Wähle deine Domain aus
3. Öffne den DKIM-Bereich
4. Kopiere den bereitgestellten DNS-Record

Für selbst gehostete Mailserver erzeugst du Schlüssel mit OpenSSL:

```bash
openssl genrsa -out private.key 2048
openssl rsa -in private.key -pubout -out public.key
```

**Schritt 2: DKIM-DNS-Record hinzufügen**

In deiner DNS-Verwaltung:

- Type: TXT
- Host/Name: selector.\_domainkey (z. B. brevo.\_domainkey)
- Value: der DKIM-Record deines Anbieters
- TTL: 3600

**Schritt 3: DKIM-Signierung aktivieren**

Aktiviere DKIM-Signierung für deine Domain in den Einstellungen deines E-Mail-Anbieters. Dadurch signiert der Anbieter ausgehende Nachrichten.

**Schritt 4: Setup prüfen**

Sende eine Test-E-Mail und prüfe die Header auf DKIM-Signature. Nutze Tools wie:

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

### DKIM-Best-Practices

**2048-Bit-Schlüssel nutzen:**

Ältere 1024-Bit-Schlüssel gelten als schwach. Moderne Sicherheitsstandards empfehlen mindestens 2048-Bit-RSA-Schlüssel.

**Schlüssel regelmäßig rotieren:**

Auch wenn es nicht strikt erforderlich ist, ist jährliche DKIM-Schlüsselrotation eine gute Sicherheitspraxis. Füge den neuen Schlüssel hinzu, bevor du den alten entfernst, damit keine Lücke entsteht.

**Auf kompromittierte Schlüssel achten:**

Wenn dein privater Schlüssel kompromittiert wird, können Angreifer Nachrichten als du signieren. Überwache ungewöhnliche Authentifizierungsmuster.

**Unterschiedliche Selector für unterschiedliche Dienste nutzen:**

Jeder E-Mail-Anbieter sollte einen eindeutigen Selector nutzen. Das ermöglicht unabhängiges Key Management und verhindert Konflikte mit anderen Diensten.

**DNS-Propagation prüfen:**

DKIM-Schlüssel können lang sein. Stelle sicher, dass dein DNS-Anbieter TXT-Records mit ausreichender Länge unterstützt. Einige Anbieter verlangen, dass der Schlüssel in mehrere Strings aufgeteilt wird.

### DKIM-Header lesen

Wenn du eine E-Mail erhältst, zeigt der DKIM-Signature-Header:

```
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 | Bedeutung |
| --- | --- |
| v= | Version (immer 1) |
| a= | Algorithmus (rsa-sha256 empfohlen) |
| c= | Canonicalization (relaxed erlaubt kleinere Änderungen) |
| d= | Signierende Domain |
| s= | Selector |
| h= | Signierte Header |
| bh= | Body Hash |
| b= | Signatur |

## DMARC verstehen (Domain-based Message Authentication, Reporting, and Conformance)

DMARC baut auf SPF und DKIM auf, um Policy-Durchsetzung und Reporting bereitzustellen. Es sagt empfangenden Servern, was bei Authentifizierungsfehlern passieren soll, und sendet dir Reports zu Authentifizierungsergebnissen.

### Wie DMARC funktioniert

DMARC ergänzt zwei wichtige Fähigkeiten:

1. **Policy-Durchsetzung**: Definiere, wie Empfänger mit Authentifizierungsfehlern umgehen sollen.
2. **Reporting**: Erhalte Daten darüber, wer E-Mail mit deiner Domain sendet.

**DMARC-Prüfprozess:**

1. Ein empfangender Server bekommt eine E-Mail, die vorgibt, von deiner Domain zu stammen.
2. Er prüft SPF (passt die sendende IP?).
3. Er prüft DKIM (ist die Signatur gültig?).
4. Er prüft DMARC-Alignment (passen die authentifizierten Domains zum From-Header?).
5. Wenn Alignment fehlschlägt, wendet er deine DMARC-Policy an.
6. Er sendet dir aggregierte und/oder forensische Reports.

*How DMARC decides what happens to a message*

### DMARC-Alignment

DMARC verlangt **Alignment** zwischen der Domain im From-Header und den Domains, die SPF oder DKIM bestehen:

**SPF-Alignment:** Die Domain im Return-Path (Envelope Sender) muss zur From-Header-Domain passen oder eine Subdomain davon sein.

**DKIM-Alignment:** Die Domain in der DKIM-Signatur (`d=`-Tag) muss zur From-Header-Domain passen oder eine Subdomain davon sein.

**Alignment-Modi:**

| Modus | Beschreibung |
| --- | --- |
| Strict (s) | Exakte Domain-Übereinstimmung erforderlich |
| Relaxed (r) | Subdomains erlaubt (Standard) |

Bei relaxed Alignment besteht die Prüfung, wenn dein From-Header `marketing@example.com` zeigt und DKIM mit `brevo.example.com` signiert, weil beide dieselbe organisatorische Domain `example.com` teilen.

### DMARC-Record-Syntax

DMARC-Records werden als TXT-Records unter `_dmarc.yourdomain.com` veröffentlicht:

```
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100
```

**Erforderliche Tags:**

| Tag | Beschreibung | Werte |
| --- | --- | --- |
| v= | Version | DMARC1 (immer) |
| p= | Policy | none, quarantine, reject |

**Optionale Tags:**

| Tag | Beschreibung | Standard |
| --- | --- | --- |
| rua= | Adresse für aggregierte Reports | none |
| ruf= | Adresse für forensische Reports | none |
| pct= | Prozentsatz, auf den Policy angewendet wird | 100 |
| sp= | Subdomain-Policy | gleich wie p= |
| adkim= | DKIM-Alignment-Modus | r (relaxed) |
| aspf= | SPF-Alignment-Modus | r (relaxed) |
| fo= | Optionen für forensische Reports | 0 |
| ri= | Report-Intervall (Sekunden) | 86400 |

### DMARC-Policies erklärt

**p=none (nur überwachen):**

Bei Fehlern wird keine Aktion ausgeführt. E-Mails werden normal zugestellt. Nutze diese Policy, während du Reports analysierst und Authentifizierungsprobleme behebst.

```
v=DMARC1; p=none; rua=mailto:dmarc@example.com
```

**p=quarantine (Spam-Ordner):**

Fehlgeschlagene E-Mails werden in den Spam- oder Junk-Ordner verschoben. Das ist ein guter Zwischenschritt vor vollständiger Ablehnung.

```
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100
```

**p=reject (blockieren):**

Fehlgeschlagene E-Mails werden vollständig abgelehnt. Das bietet maximalen Schutz, aber stelle zuerst sicher, dass alle legitimen Quellen bestehen.

```
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100
```

### DMARC einrichten

**Schritt 1: Sicherstellen, dass SPF und DKIM funktionieren**

DMARC hängt von SPF und DKIM ab. Prüfe, ob beide korrekt konfiguriert sind, bevor du DMARC hinzufügst.

**Schritt 2: Mit Monitoring starten (p=none)**

Beginne mit der permissivsten Policy, um Daten zu sammeln, ohne die Zustellung zu beeinflussen:

```
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
```

**Schritt 3: DNS-Record hinzufügen**

In deiner DNS-Verwaltung:

- Type: TXT
- Host/Name: \_dmarc
- Value: dein DMARC-Record
- TTL: 3600

**Schritt 4: Reports 2-4 Wochen analysieren**

DMARC-Aggregate-Reports kommen täglich als XML-Dateien und zeigen:

- Welche IPs E-Mail mit deiner Domain gesendet haben
- SPF- und DKIM-Pass/Fail-Raten
- DMARC-Alignment-Ergebnisse
- Aktionen empfangender Server

Nutze DMARC-Report-Analyzer, um diese Daten zu visualisieren:

- DMARC Analyzer
- Postmark DMARC
- Valimail
- dmarcian

**Schritt 5: Authentifizierungsprobleme beheben**

Häufige Probleme, die Reports sichtbar machen:

- Legitimen Diensten fehlt der SPF-Eintrag.
- DKIM ist für einen sendenden Dienst nicht aktiviert.
- Drittanbieter senden ohne korrekte Authentifizierung.
- Weiterleitungen brechen SPF-Alignment.

**Schritt 6: Schrittweise durchsetzen**

Sobald legitime Quellen konsistent bestehen:

1. Wechsle zu `p=quarantine; pct=10` (10 % der Fehler in Quarantäne verschieben).
2. Erhöhe pct auf 25, 50, 75, 100.
3. Wechsle zu `p=reject; pct=10`.
4. Erhöhe bis zur vollständigen Ablehnung.

**Schritt 7: Warten und überwachen**

Prüfe Reports weiter. Neue sendende Quellen, Anbieteränderungen oder Konfigurationsdrift können Authentifizierungsfehler verursachen.

### DMARC-Reports verstehen

**Aggregierte Reports (rua):**

Tägliche XML-Zusammenfassungen mit:

- Reportender Organisation
- Datumsbereich
- Veröffentlichter Policy
- Authentifizierungsergebnissen nach Quell-IP
- E-Mail-Volumen

Beispielauszug:

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

**Forensische Reports (ruf):**

Einzelne Nachrichtendetails für Fehler. Diese Reports sind detaillierter, aber datenschutzsensibel. Viele Empfänger senden keine forensischen Reports.

### DMARC-Best-Practices

**Immer mit p=none starten:**

Direkt zu reject zu springen kann legitime E-Mail blockieren. Überwache zuerst.

**Dedizierte E-Mail-Adresse für Reports nutzen:**

DMARC-Reports können sehr umfangreich werden. Nutze eine dedizierte Adresse oder einen Drittanbieter-Service.

**Subdomain-Policy setzen (sp=):**

Wenn du keine E-Mail von Subdomains sendest, setze `sp=reject`, um sie vor Spoofing zu schützen.

**Prozentsatz (pct=) für graduellen Rollout nutzen:**

Der pct-Tag erlaubt, Policy nur auf einen Prozentsatz der Fehler anzuwenden und den Rest weiter zu überwachen.

**Dedizierte DMARC-Services erwägen:**

Für größere Organisationen bieten Services wie Valimail, dmarcian oder Postmark DMARC bessere Report-Analyse als rohe XML-Dateien.

## DNS-Record-Setup: vollständiger Walkthrough

E-Mail-Authentifizierung erfordert bestimmte DNS-Records. Dieser Abschnitt führt dich durch ein vollständiges Setup für große DNS-Anbieter.

### Erforderliche Werte sammeln

Sammle vor dem Start diese Werte aus deinen E-Mail-Anbietern:

**Für SPF:**

- Alle Include-Statements (z. B. include:spf.brevo.com)
- Bestimmte IP-Adressen, die du autorisieren musst

**Für DKIM:**

- Den Selector-Namen (z. B. brevo, google, s1)
- Den vollständigen DKIM-Key-Wert

**Für DMARC:**

- Deine Reporting-E-Mail-Adresse

### Records bei häufigen DNS-Anbietern hinzufügen

**Cloudflare:**

1. Logge dich in das Cloudflare Dashboard ein.
2. Wähle deine Domain aus.
3. Gehe zu DNS > Records.
4. Klicke Add Record.
5. Für SPF: Type=TXT, Name=@, Content=dein SPF-Record.
6. Für DKIM: Type=TXT, Name=selector.\_domainkey, Content=DKIM-Key.
7. Für DMARC: Type=TXT, Name=\_dmarc, Content=DMARC-Record.
8. Klicke Save.

**Google Domains/Squarespace:**

1. Öffne die DNS-Einstellungen deiner Domain.
2. Scrolle zu Custom Records.
3. Klicke Manage Custom Records.
4. Füge jeden Record mit passendem Type, Host und Data hinzu.
5. Für SPF: Host=@, Type=TXT, Data=SPF-Record.
6. Für DKIM: Host=selector.\_domainkey, Type=TXT, Data=DKIM-Key.
7. Für DMARC: Host=\_dmarc, Type=TXT, Data=DMARC-Record.

**GoDaddy:**

1. Gehe zu My Products > Domains.
2. Klicke DNS neben deiner Domain.
3. Scrolle zum Records-Bereich.
4. Klicke Add für jeden neuen Record.
5. Wähle TXT als Type.
6. Gib den Name ein (@ für SPF, selector.\_domainkey für DKIM, \_dmarc für DMARC).
7. Gib den Value ein.
8. Speichere.

**Namecheap:**

1. Gehe zu Domain List > Manage.
2. Klicke Advanced DNS.
3. Füge jeweils Add New Record hinzu.
4. Wähle TXT Record.
5. Host: @ für SPF, selector.\_domainkey für DKIM, \_dmarc für DMARC.
6. Value: dein Record-Inhalt.
7. Speichere alle Änderungen.

### DNS-Propagation

Nach dem Hinzufügen von Records brauchen Änderungen Zeit, bis sie global propagiert sind. Typisch sind:

- 5-30 Minuten für erste Sichtbarkeit
- Bis zu 48 Stunden für vollständige globale Propagation

Nutze dig oder nslookup zur Prüfung:

```bash
dig TXT yourdomain.com
dig TXT selector._domainkey.yourdomain.com
dig TXT _dmarc.yourdomain.com
```

Oder nutze Online-Tools wie whatsmydns.net, um Propagation weltweit zu prüfen.

### Beispiel für ein vollständiges Setup

Für eine Domain, die Brevo und Google Workspace nutzt:

**SPF-Record (TXT bei @):**

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

**DKIM-Record für Brevo (TXT bei brevo.\_domainkey):**

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

**DKIM-Record für Google (TXT bei google.\_domainkey):**

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

**DMARC-Record (TXT bei \_dmarc):**

```
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
```

## Häufige Probleme beheben

Auch bei sorgfältiger Einrichtung kann E-Mail-Authentifizierung fehlschlagen. Hier sind häufige Probleme und wie du sie löst.

### SPF-Troubleshooting

**SPF-Record nicht gefunden:**

Symptome: SPF-Prüfungen zeigen “none” oder “no record”.

Ursachen:

- Record wurde nicht zu DNS hinzugefügt.
- Record wurde an der falschen Stelle hinzugefügt (Subdomain statt Root).
- DNS-Propagation ist noch nicht abgeschlossen.

Lösungen:

- Prüfe mit `dig TXT yourdomain.com`, ob der Record existiert.
- Prüfe das Name/Host-Feld (sollte @ oder leer für Root-Domain sein).
- Warte auf DNS-Propagation (bis zu 48 Stunden).

**SPF PermError (zu viele Lookups):**

Symptome: SPF-Ergebnisse zeigen “permerror”.

Ursachen:

- Mehr als 10 DNS-Lookups in deinem SPF-Record.
- Includes enthalten zu viele verschachtelte Includes.

Lösungen:

- Auditiere deine Includes und entferne ungenutzte.
- Ersetze Includes durch ip4:-Einträge, wo möglich.
- Nutze SPF-Flattening-Services.
- Konsolidiere Dienste auf weniger Anbieter.

**SPF SoftFail oder Fail für legitime E-Mail:**

Symptome: Legitime E-Mails bestehen SPF nicht.

Ursachen:

- Sendender Dienst fehlt im SPF.
- Versand erfolgt von einer nicht autorisierten IP.
- Ein Relay ändert den Envelope Sender.

Lösungen:

- Füge den fehlenden Include für deinen sendenden Dienst hinzu.
- Prüfe, welche IP die E-Mail tatsächlich gesendet hat (aus den Headern).
- Kontaktiere deinen E-Mail-Anbieter für korrekte SPF-Einstellungen.

**Mehrere SPF-Records:**

Symptome: SPF zeigt permerror oder zufällige Fehler.

Ursachen:

- Zwei oder mehr TXT-Records enthalten v=spf1.

Lösungen:

- Kombiniere alle Mechanismen in einen einzigen SPF-Record.
- Lösche doppelte SPF-Records.

### DKIM-Troubleshooting

**DKIM-Signatur fehlt:**

Symptome: Kein DKIM-Signature-Header in E-Mails.

Ursachen:

- DKIM-Signierung ist beim E-Mail-Anbieter nicht aktiviert.
- Domain-Verifizierung wurde nicht abgeschlossen.
- Versand läuft über einen Pfad ohne DKIM.

Lösungen:

- Aktiviere DKIM in den Einstellungen deines Anbieters.
- Schließe die Domain-Verifizierung ab.
- Prüfe die Anbieter-Dokumentation zum DKIM-Setup.

**DKIM-Prüfung fehlgeschlagen:**

Symptome: DKIM zeigt “fail” in Authentication-Results.

Ursachen:

- DNS-Record ist nicht veröffentlicht oder falsch.
- Falscher Selector wird genutzt.
- Key in DNS und Signing-Key passen nicht zusammen.
- Nachricht wurde während der Übertragung verändert.

Lösungen:

- Prüfe, ob der DNS-Record unter selector.\_domainkey.domain existiert.
- Vergleiche den Selector im DKIM-Signature-Header mit DNS.
- Erzeuge Schlüssel neu, wenn ein Mismatch vermutet wird.
- Prüfe Mailfilter oder Relays, die Nachrichten verändern.

**DKIM-Key zu lang für DNS:**

Symptome: DKIM-Record lässt sich nicht speichern, Truncation-Fehler.

Ursachen:

- 2048-Bit-Schlüssel überschreiten die Länge eines einzelnen TXT-Records.
- DNS-Anbieter hat Zeichenlimits.

Lösungen:

- Teile den Schlüssel in mehrere zitierte Strings auf (die meisten Anbieter behandeln das automatisch).
- Prüfe, ob dein DNS-Anbieter lange TXT-Records unterstützt.
- Nutze 1024-Bit-Schlüssel nur vorübergehend (weniger sicher).

Beispiel für einen aufgeteilten DKIM-Record:

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

### DMARC-Troubleshooting

**DMARC-Alignment-Fehler:**

Symptome: SPF und DKIM bestehen, aber DMARC schlägt fehl.

Ursachen:

- Die authentifizierte Domain passt nicht zur From-Header-Domain.
- Drittanbieter-Sendedienst nutzt eine eigene Domain.
- Envelope Sender ist falsch konfiguriert.

Lösungen:

- Stelle sicher, dass dein E-Mail-Anbieter mit deiner Domain signiert (Custom DKIM).
- Konfiguriere einen eigenen Return-Path/Envelope Sender.
- Nutze relaxed Alignment Mode (`adkim=r; aspf=r`).

**Keine DMARC-Reports erhalten:**

Symptome: Keine aggregierten Reports kommen an.

Ursachen:

- rua-Adresse ist falsch.
- E-Mail-Adresse kann keine externe E-Mail empfangen.
- Reports landen im Spam.
- Empfangende Server senden keine Reports.

Lösungen:

- Prüfe die rua-Syntax: `rua=mailto:address@domain.com`.
- Teste, ob die Reporting-Adresse externe E-Mail empfangen kann.
- Prüfe den Spam-Ordner auf Reports.
- Hinweis: Nicht alle Empfänger senden DMARC-Reports.

**DMARC-Record nicht gefunden:**

Symptome: DMARC-Prüfungen zeigen “no record”.

Ursachen:

- Record wurde an der falschen Stelle veröffentlicht.
- Falsches Format (muss TXT bei \_dmarc-Subdomain sein).

Lösungen:

- Der Record muss unter \_dmarc.yourdomain.com liegen.
- Prüfe mit `dig TXT _dmarc.yourdomain.com`.

### Allgemeine Troubleshooting-Tools

**Online-Validatoren:**

- MXToolbox (mxtoolbox.com) - SPF-, DKIM-, DMARC-Lookups
- Mail Tester (mail-tester.com) - Test-E-Mail für vollständige Analyse senden
- DMARC Analyzer - Report-Visualisierung
- Google Admin Toolbox - MX, SPF, DKIM prüfen

**Command-Line-Tools:**

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

**E-Mail-Header-Analyse:**

Prüfe den Authentication-Results-Header in empfangenen 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-Mail-Authentifizierung und Brevo

Brevo bietet umfassende Unterstützung für E-Mail-Authentifizierung und macht die Konfiguration von SPF, DKIM und DMARC für sendende Domains übersichtlich.

### Authentifizierung in Brevo einrichten

**Schritt 1: Domain hinzufügen**

1. Logge dich in dein Brevo-Konto ein.
2. Navigiere zu Settings > Senders, Domains & Dedicated IPs.
3. Klicke Add a Domain.
4. Gib deinen Domainnamen ein.

**Schritt 2: SPF konfigurieren**

Brevo stellt den SPF-Include bereit, den du zu DNS hinzufügst:

```
include:spf.brevo.com
```

Füge ihn zu deinem bestehenden SPF-Record hinzu oder erstelle einen neuen:

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

**Schritt 3: DKIM konfigurieren**

Brevo erzeugt DKIM-Schlüssel automatisch. Kopiere den bereitgestellten Record:

1. Gehe in Brevo zu deinen Domain-Einstellungen.
2. Suche den DKIM-Bereich.
3. Kopiere DNS-Record-Name und -Wert.
4. Füge den TXT-Record zu DNS hinzu.

**Schritt 4: Konfiguration prüfen**

Brevo prüft deine DNS-Records automatisch. Grüne Haken zeigen eine erfolgreiche Konfiguration.

### Vorteile korrekter Brevo-Authentifizierung

Wenn du Authentifizierung mit Brevo korrekt konfigurierst:

- **Höhere Inbox-Platzierung**: Gmail, Microsoft und andere Anbieter vertrauen authentifizierten Nachrichten.
- **Markenschutz**: DMARC verhindert Spoofing deiner Domain.
- **Bessere Analytics**: Öffnungen und Klicks werden genauer gemessen.
- **Reputationsaufbau**: Konsistente Authentifizierung baut Sender-Reputation auf.

## Fazit

E-Mail-Authentifizierung mit SPF, DKIM und DMARC ist für Unternehmen, die auf E-Mail-Kommunikation angewiesen sind, nicht mehr optional. Diese Protokolle schützen deine Marke vor Spoofing, verbessern Zustellbarkeit und bauen das Vertrauen auf, das wirksames E-Mail-Marketing braucht.

**Wichtigste Punkte:**

- **SPF** autorisiert sendende Server über DNS.
- **DKIM** beweist Nachrichtenechtheit mit kryptografischen Signaturen.
- **DMARC** setzt Policy durch und gibt Sichtbarkeit über Reports.
- Starte mit Monitoring (p=none), bevor du Ablehnung durchsetzt.
- Alle legitimen sendenden Quellen müssen korrekt konfiguriert sein.
- Regelmäßiges Monitoring verhindert Konfigurationsdrift.

Transaktionale E-Mails erreichen Kund:innen zuverlässig, Marketingkampagnen landen besser im Posteingang und deine Marke bleibt vor Spoofing-Angriffen geschützt.

Bereit, deine E-Mail-Zustellbarkeit zu verbessern? Starte mit einem Audit deiner aktuellen Authentifizierung anhand der Tools in diesem Leitfaden. Konfiguriere danach SPF, DKIM und DMARC systematisch nach den Schritt-für-Schritt-Anleitungen.

## Wo Tajo ins Spiel kommt

Tajo ist der agentische Integrations-Builder. Behalte deine Anbieter. Agenten verbinden alles andere, und du gibst jede Synchronisierung frei. Tajo befindet sich im Frühzugang. [Frühzugang anfragen](https://tajo.io/de/#early-access)

## Häufig gestellte Fragen

**Was sind SPF, DKIM und DMARC?**

SPF prüft sendende Server, DKIM fügt E-Mails eine digitale Signatur hinzu und DMARC sagt empfangenden Servern, wie sie nicht authentifizierte Nachrichten behandeln sollen. Zusammen authentifizieren sie deine E-Mails und schützen vor Spoofing.

**Brauche ich alle drei: SPF, DKIM und DMARC?**

Ja. Google und Yahoo verlangen inzwischen SPF und DKIM für alle Sender und DMARC für Sender mit mehr als 5.000 E-Mails pro Tag. Alle drei zusammen liefern die beste Zustellbarkeit und Sicherheit.

**Wie richte ich SPF, DKIM und DMARC ein?**

Füge DNS-Records zu deiner Domain hinzu: SPF als TXT-Record mit autorisierten Sendern, DKIM als TXT-Record mit deinem öffentlichen Schlüssel und DMARC als TXT-Record mit deiner Policy. Deine E-Mail-Plattform liefert die konkreten Werte.

**Was ist der Unterschied zwischen SPF, DKIM und DMARC?**

SPF legt fest, welche Server E-Mail für deine Domain senden dürfen. DKIM fügt eine kryptografische Signatur hinzu, die Nachrichtenechtheit beweist. DMARC setzt eine Policy dafür, wie Empfänger Authentifizierungsfehler behandeln sollen, und liefert Reporting. Alle drei arbeiten für vollständige E-Mail-Authentifizierung zusammen.

**Brauche ich wirklich alle drei (SPF, DKIM und DMARC)?**

Für die beste Zustellbarkeit und Sicherheit: ja. SPF allein ist anfällig für Spoofing. DKIM allein legt keine Richtlinie fest. DMARC braucht SPF oder DKIM, um zu funktionieren. Zusammen bieten sie umfassenden Schutz und die besten Posteingangsquoten.

**Wie lange dauert es, bis E-Mail-Authentifizierung funktioniert?**

DNS-Änderungen propagieren normalerweise innerhalb von 30 Minuten bis 48 Stunden. Sobald sie propagiert sind, greift Authentifizierung sofort. Sender-Reputation durch konsistente Authentifizierung aufzubauen, dauert jedoch Wochen bis Monate.

**Blockiert DMARC mit p=reject meine legitimen E-Mails?**

Das kann passieren, wenn es falsch konfiguriert ist. Deshalb solltest du immer mit p=none (Monitoring) starten, Reports 2-4 Wochen analysieren, Probleme beheben und dann schrittweise zu quarantine und reject wechseln. Überspringe die Monitoring-Phase nie.

**Was ist SPF-Alignment vs. DKIM-Alignment?**

Alignment bedeutet, dass die authentifizierte Domain zur sichtbaren From-Header-Domain passt. SPF-Alignment vergleicht die Return-Path-Domain. DKIM-Alignment vergleicht die signierende Domain (\`d=\`-Tag). DMARC verlangt, dass mindestens eines davon aligned.

**Kann ich mehrere DKIM-Schlüssel für eine Domain haben?**

Ja. Jeder E-Mail-Dienst kann einen anderen Selector nutzen (z. B. brevo.\_domainkey, google.\_domainkey). Dadurch können mehrere Dienste unabhängig mit DKIM signieren. Es gibt kein Limit für die Anzahl von DKIM-Selectors.

**Warum landen meine E-Mails nach der Einrichtung von Authentifizierung immer noch im Spam?**

Authentifizierung ist notwendig, aber nicht ausreichend für Inbox-Platzierung. Weitere Faktoren sind Sender-Reputation, Inhaltsqualität, Engagement-Raten und Listenhygiene. Authentifizierung bringt dich durch den ersten Filter. Gute Praxis entscheidet über die finale Platzierung.

**Wie lese ich DMARC-Aggregate-Reports?**

DMARC-Aggregate-Reports sind XML-Dateien. Nutze Tools wie dmarcian, Postmark DMARC oder DMARC Analyzer, um sie zu parsen und zu visualisieren. Diese Tools zeigen, welche IPs E-Mail als deine Domain senden und welche Pass/Fail-Raten sie haben.

**Was passiert, wenn ich das SPF-Limit von 10 Lookups überschreite?**

SPF liefert einen permanenten Fehler (permerror), und alle SPF-Prüfungen schlagen fehl. Behebe das, indem du ungenutzte Includes entfernst, Includes wo möglich durch IP-Adressen ersetzt oder SPF-Flattening-Services nutzt.

**Sollte ich -all oder ~all in meinem SPF-Record nutzen?**

Nutze \`~all\` (softfail), während du testest und Vertrauen aufbaust. Wenn du bestätigt hast, dass alle legitimen Quellen bestehen, wechsle zu \`-all\` (hard fail) für stärkeren Schutz. Softfail markiert Fehler, lehnt aber nicht ab. Hard fail autorisiert Ablehnung.

**Wie oft sollte ich DKIM-Schlüssel rotieren?**

Es gibt keine strikte Pflicht, aber jährliche Rotation ist eine gute Sicherheitspraxis. Beim Rotieren fügst du zuerst den neuen Schlüssel hinzu, wartest auf DNS-Propagation, aktivierst Signing mit dem neuen Schlüssel und entfernst den alten Schlüssel nach einer Übergangszeit.

**Brauchen Subdomains separate Authentifizierung?**

SPF: Ja, jede Subdomain braucht einen eigenen SPF-Record, wenn sie E-Mail sendet. DKIM: Schlüssel können pro Subdomain geteilt oder getrennt sein. DMARC: Subdomains erben die Parent-Policy, außer \`sp=\` ist gesetzt oder die Subdomain hat einen eigenen DMARC-Record.

## Verwandte Artikel

### [E-Mail-Blacklist-Check: kompletter Guide zu Erkennung, Entfernung und Prävention](https://tajo.io/de/blog/email-blacklist-check-guide/)

8\. März 2026 · 12 Min. Lesezeit

9 Abschnitte

### [E-Mail-Zustellbarkeit: Kompletter Leitfaden zur Inbox-Platzierung \[2026\]](https://tajo.io/de/blog/email-deliverability-complete-guide/)

8\. März 2025 · 12 Min. Lesezeit

13 Abschnitte

### [Was ist ein MCP-Server? So funktionieren MCP und MCP UI 2026](https://tajo.io/de/blog/what-is-an-mcp-server/)

3\. Okt. 2026 · 14 Min. Lesezeit

Schritt 1 → Schritt 6