Das komplette E-Mail-Authentifizierungs-Rollout: SPF, DKIM & DMARC von Null auf p=reject

E-Mail bleibt der am häufigsten missbrauchte Einstiegspunkt in Unternehmen. Laut dem Verizon Data Breach Investigations Report sind Phishing und Pretexting an der Mehrheit der Social-Engineering-Angriffe beteiligt, und die meisten davon beginnen mit einer gefälschten Absenderadresse. Die drei DNS-basierten Authentifizierungsstandards — SPF, DKIM und DMARC — existieren, um das Spoofing Ihrer Domain technisch erkennbar und bei vollständiger Durchsetzung ablehnbar zu machen.

Dieser Leitfaden richtet sich an IT-Manager, die ein echtes Unternehmen — mit Newslettern, CRM, Helpdesk, Buchhaltungssoftware und Marketing-Plattformen, die alle E-Mails "von" der Firmendomain versenden — von Null auf eine durchgesetzte DMARC-Policy von p=reject bringen müssen, ohne dabei eine einzige legitime Nachricht zu verlieren. Planen Sie für den vollständigen Rollout 6–10 Wochen ein, bei nur wenigen Stunden Arbeitsaufwand pro Woche.

Wie die drei Protokolle zusammenarbeiten

Bevor Sie DNS-Einstellungen ändern, stellen Sie sicher, dass das Grundverständnis stimmt, denn die meisten gescheiterten Rollouts basieren auf einem Missverständnis des Begriffs Alignment.

• SPF (RFC 7208) veröffentlicht im DNS die Liste der IP-Adressen, die berechtigt sind, E-Mails unter Verwendung Ihrer Domain im SMTP-Envelope (MAIL FROM) zu versenden.
• DKIM (RFC 6376) signiert jede Nachricht kryptografisch mit einem privaten Schlüssel; der öffentliche Schlüssel wird im DNS veröffentlicht. Empfänger überprüfen die Signatur, um zu bestätigen, dass die Nachricht nicht verändert wurde und von der signierenden Domain autorisiert ist.
• DMARC (RFC 7489) verbindet beides. Es teilt den Empfängern mit: "Wenn eine Nachricht im sichtbaren From:-Header behauptet, von meiner Domain zu stammen, muss sie SPF oder DKIM im Alignment mit dieser Domain bestehen — und hier ist, was zu tun ist, wenn dies nicht der Fall ist, sowie die Zieladresse für Berichte."

Der Verifizierungsprozess auf dem empfangenden Mailserver sieht wie folgt aus:

            Eingehende Nachricht mit From: billing@example.com
                                 |
              +------------------+------------------+
              |                                     |
        SPF-Check                             DKIM-Check
   Ist die sendende IP im                Verifiziert die d=-Signatur
   SPF-Eintrag der domain                den öffentlichen DNS-Schlüssel?
   für den Absender gelistet?
              |                                     |
              +------------------+------------------+
                                 |
                          DMARC-Alignment
        Stimmt die Domain, die bestanden hat (Envelope-Domain für SPF,
        d=-Domain für DKIM), mit der sichtbaren From:-Domain überein?
                                 |
              +------------------+------------------+
              |                                     |
         PASS: Zustellung                  FAIL: Policy anwenden
                                          p=none  -> zustellen, berichten
                                          p=quarantine -> Spam-Ordner
                                          p=reject -> Nachricht ablehnen

Das entscheidende Detail: Eine Nachricht kann SPF und DKIM für eine beliebige Domain bestehen und trotzdem bei DMARC scheitern, da DMARC erfordert, dass die Domain, die den Test bestanden hat, mit der From:-Header-Domain aligniert ist, die Ihre Nutzer tatsächlich sehen. Genau das stoppt Phisher, die E-Mails mit dem DKIM-Schlüssel ihrer eigenen Domain signieren.

Phase 0 — Inventur aller legitimen Absender (Woche 1)

Die Hauptursache für verlorene E-Mails bei DMARC-Rollouts ist ein vergessener Versanddienst. Bevor Sie etwas veröffentlichen, erstellen Sie eine Absender-Inventur. Befragen Sie die Marketing-, Vertriebs-, Finanz- und HR-Teams und prüfen Sie das DNS auf bestehende include:-Mechanismen.

Typische Inventur für ein 50-Personen-Unternehmen:

Zwei Faustregeln für diese Phase:

1. Alles, was kein DKIM kann, sollte über ein authentifiziertes Relay (z. B. Ihr Workspace SMTP-Relay oder einen transaktionalen Provider wie Postmark oder SES) gesendet werden, statt direkt vom Webserver.
2. Raten Sie nicht. Die DMARC-Monitoring-Phase unten wird aufdecken, was Sie bei Befragungen übersehen haben — genau dafür ist sie da.

Phase 1 — Korrekten SPF-Eintrag veröffentlichen (Woche 1–2)

SPF ist ein TXT-Eintrag an der Root Ihrer Domain. Sammeln Sie die include-Mechanismen aus der Dokumentation jedes Anbieters und führen Sie sie in einem einzigen Eintrag zusammen — eine Domain darf exakt einen SPF-Eintrag haben; zwei Einträge verursachen einen permanenten Fehler (permerror) und deaktivieren SPF effektiv.

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

Entscheidungen:

• Enden Sie mit ~all (softfail), nicht -all, während des Rollouts. DMARC benötigt kein -all, um zu funktionieren, und -all kombiniert mit einer unvollständigen Inventur lässt legitime E-Mails sofort abprallen. Sie können nach Abschluss der Monitoring-Phase auf -all umstellen.
• Bleiben Sie unter 10 DNS-Lookups. Jeder include, a, mx und redirect-Mechanismus kostet ein Lookup; mehr als zehn verursachen einen permerror gemäß RFC 7208 §4.6.4. Zählen Sie die verschachtelten Lookups innerhalb jedes includes (Googles include allein kostet drei). Wenn Sie nahe am Limit sind, nutzen Sie SPF-Flattening vorsichtig oder verschieben Sie Massenversender auf eine Subdomain.
• Nutzen Sie ip4:/ip6: für Server unter Ihrer Kontrolle statt a:-Mechanismen — diese kosten keine Lookups.

Validieren Sie mit einem Checker (FortifyNets MX & E-Mail-Sicherheitstool zeigt SPF, DKIM und DMARC in einem Durchgang) und per dig:

dig +short TXT example.com | grep spf1

Phase 2 — DKIM überall aktivieren (Woche 2–3)

Die DKIM-Einrichtung ist anbieterspezifisch, folgt aber immer dem gleichen Muster: Der Anbieter generiert ein Schlüsselpaar, Sie veröffentlichen den öffentlichen Schlüssel unter selector._domainkey.example.com, und der Anbieter beginnt mit der Signierung.

• Google Workspace: Admin-Konsole → Apps → Google Workspace → Gmail → E-Mail-Authentifizierung. Generieren Sie einen 2048-Bit-Schlüssel (1024-Bit-Schlüssel gelten als schwach; NIST und M3AAWG empfehlen 2048). Veröffentlichen Sie den TXT-Eintrag, warten Sie auf die DNS-Propagierung und klicken Sie auf "Authentifizierung starten".
• Microsoft 365: Defender-Portal → E-Mail-Authentifizierungseinstellungen → DKIM. Microsoft nutzt zwei CNAME-Einträge (selector1, selector2), die eine automatische Schlüsselrotation ermöglichen.
• Mailchimp, HubSpot, Zendesk etc.: Jeder bietet einen "Domain authentifizieren"-Assistenten, der Ihnen 2–4 CNAME-Einträge gibt.

Überprüfen Sie jeden Selektor nach der Veröffentlichung:

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

Senden Sie dann eine Testnachricht an eine Gmail-Adresse, öffnen Sie "Original anzeigen" und bestätigen Sie, dass Sie DKIM: PASS with domain example.com sehen — der Teil "with domain" ist das Alignment, das DMARC prüfen wird.

Planen Sie eine Schlüsselrotation alle 6–12 Monate. Anbieter mit CNAME-basierten Setups rotieren für Sie; bei manuell veröffentlichten Schlüsseln tragen Sie sich jetzt einen Serientermin in den Security-Kalender ein.

Phase 3 — DMARC im Monitoring-Modus (Woche 3–4)

Veröffentlichen Sie einen DMARC-Eintrag unter _dmarc.example.com mit der Policy p=none. Dies ändert nichts an der Zustellung — es aktiviert lediglich die Berichterstattung.

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

Bedeutung der Tags:

Praktische Hinweise:

• Nutzen Sie ein dediziertes Postfach oder besser einen DMARC-Bericht-Prozessor — Rohberichte sind komprimierte XML-Dateien und kommen täglich von jedem großen E-Mail-Provider. Kostenlose Tarife gängiger Analysatoren reichen für eine einzelne Domain aus.
• Wenn die Berichtsadresse auf einer anderen Domain liegt als die überwachte, muss die Berichtsdomain einen externen Verifizierungs-Eintrag veröffentlichen (RFC 7489 §7.1).
• Lassen Sie das Monitoring mindestens zwei volle Wochen laufen, idealerweise vier, damit auch monatliche Prozesse (Rechnungsversand, Reports) in den Daten erscheinen.

Phase 4 — Berichte lesen und Fehler beheben (Woche 4–6)

Aggregierte Berichte beantworten drei Fragen für jede sendende IP: Wie viele E-Mails, war SPF aligniert, war DKIM aligniert. Sortieren Sie in drei Gruppen:

1. Aligned pass (SPF oder DKIM): gesund. Der Großteil Ihres Workspace/M365-Verkehrs sollte ab Tag eins hier landen.
2. Ihr Dienst, fehlgeschlagenes Alignment: z. B. das CRM besteht DKIM, signiert aber mit d=crm-provider.com. Korrektur: Führen Sie den Domain-Authentifizierungs-Assistenten des Anbieters aus, damit mit Ihrer Domain signiert wird.
3. Unbekannte IPs, die alles verfehlen: das ist Spoofing (oder Weiterleitung). Hier korrigieren Sie nichts — die Durchsetzung wird dies neutralisieren. Das Vorhandensein ist der Business-Case für dieses Projekt.

Eine legitime Quelle wird immer fehlschlagen: Mailinglisten und Forwarder zerstören SPF (neue sendende IP) und manchmal DKIM (Footer-Einfügung). ARC (RFC 8617) hilft bei großen Empfängern, aber eine kleine Fehlerquote (deutlich unter 1 %) ist bei der Durchsetzung normal und akzeptabel.

Phase 5 — Ramp-up zur Durchsetzung (Woche 6–10)

Springen Sie nie direkt von p=none zu p=reject. Nutzen Sie das pct-Tag für den Ramp-up:

Beobachten Sie bei jedem Schritt zwei Signale: Aggregierte Berichte (die aligned-pass Quote für bekannte Absender sollte stabil bleiben) und das Helpdesk (Tickets wegen "Kunde sagt, E-Mail kam nicht an"). Rollback ist eine einfache DNS-Änderung — setzen Sie den TTL während des Ramp-ups auf 3600 Sekunden.

Wenn Sie bei p=reject ankommen, beenden Sie die Arbeit:

• Fügen Sie eine explizite Subdomain-Policy hinzu: sp=reject, sofern nicht anders gewollt.
• Schützen Sie geparkte Domains, von denen Sie nie versenden: v=spf1 -all, leerer DKIM-Eintrag, v=DMARC1; p=reject. Geparkte Domains sind das Lieblingsziel für Spoofer.
• Erwägen Sie BIMI (Markenlogo im Posteingang) — dies erfordert ein erzwungenes DMARC, das Sie nun freigeschaltet haben.

Fehlerbehebung: Kurzübersicht

Das Rollout auf einen Blick

Jenseits von DMARC — MTA-STS und TLS-RPT

DMARC authentifiziert wer eine Nachricht sendet; es sagt nichts darüber aus, ob die Nachricht verschlüsselt übertragen wurde. SMTP fällt bei fehlgeschlagenem TLS-Handshake auf Klartext zurück.

MTA-STS (RFC 8461) lässt Ihre Domain erklären: "E-Mails nur über authentifiziertes TLS zustellen". Es besteht aus einem DNS-Eintrag und einer kleinen policy-Datei über HTTPS:

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

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

TLS-RPT (RFC 8460) ist der Berichtskanal für MTA-STS:

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

Governance — Durchsetzung bewahren

E-Mail-Authentifizierung ist kein Projekt mit Enddatum; es ist eine laufende Aufgabe.

• Change Control beim DNS: Jedes neue SaaS-Tool, das "E-Mails als wir" senden will, muss durch Ihre Prüfung und DKIM-Einrichtung.
• Vierteljährliche Berichtsprüfung: 15 Minuten pro Quartal, um den Analysator auf neue Fehlerquellen zu scannen.
• Monitoring der Records: Nutzen Sie externes Monitoring, um jede Änderung an Ihren DNS-Einträgen sofort zu bemerken.
• Offboarding: Wenn ein Dienst gekündigt wird, entfernen Sie sofort dessen include- und DKIM-Records.