SPF, DKIM, DMARC — vom Nice-to-have zur Zustellbedingung

/01Begriff und Abgrenzung

SPF, DKIM und DMARC prüfen drei unterschiedliche Dinge, und die Verwechslung der drei ist der häufigste Grund, warum eine Umstellung falsch geplant wird. Sender Policy Framework (SPF) legt fest, welche Server im Namen einer Domain versenden dürfen — ein DNS-Eintrag mit einer Liste erlaubter IP-Adressen. DomainKeys Identified Mail (DKIM) signiert eine Nachricht kryptografisch; der öffentliche Schlüssel liegt ebenfalls im DNS, und der Empfänger prüft, ob Kopfzeilen und Inhalt seit dem Versand unverändert geblieben sind. Beide Verfahren laufen unabhängig voneinander und unabhängig von der Absenderadresse, die ein Mensch im Postfach sieht.

Genau dort setzt DMARC an. Es verknüpft SPF und DKIM mit der sichtbaren Absenderadresse — der From-Kopfzeile — und verlangt, dass mindestens eines der beiden Verfahren auf dieselbe Domain zeigt (die sogenannte Ausrichtung, engl. Alignment). Ohne diese Verknüpfung könnte ein Angreifer eine eigene Domain sauber mit SPF und DKIM ausstatten, in der sichtbaren Absenderzeile aber eine fremde Marke eintragen — beide Prüfungen würden bestehen, weil sie die sichtbare Adresse gar nicht ansehen. DMARC schließt diese Lücke und legt zusätzlich fest, was ein Empfänger bei einer nicht ausgerichteten Nachricht tun soll: zustellen, in Quarantäne schicken oder ablehnen.

Was DMARC also nicht leistet: Es prüft keine Inhalte, erkennt keine bösartigen Anhänge oder Links, und es wehrt keine Phishing-Angriffe ab, die über eine zum Verwechseln ähnliche Domain läuft. Für die eigenen Mitarbeiter bleibt der wirksamste Schutz gegen eingehende Angriffe eine Kombination aus technischer Filterung, Zugriffskontrolle und Training — dazu mehr unter „Wo es hakt". DMARC ist der Baustein, der die eigene Absenderadresse vor fremdem Missbrauch schützt, nicht die gesamte E-Mail-Sicherheit in einem Eintrag.

/02Die drei DNS-Einträge und ihre Reihenfolge

Die Reihenfolge beim Aufbau ist nicht beliebig: DMARC ohne funktionierendes SPF und DKIM hat nichts, worauf es sich stützen kann, und schlägt bei jeder Nachricht fehl. Erst SPF, dann DKIM je Versandquelle, zuletzt DMARC — und DMARC startet immer bei p=none, dazu im nächsten Abschnitt mehr.

$ dig +short TXT hostspezial.de
"v=spf1 include:_spf.google.com include:mailgun.org -all"

$ dig +short TXT google._domainkey.hostspezial.de
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

$ dig +short TXT _dmarc.hostspezial.de
"v=DMARC1; p=none; rua=mailto:dmarc-reports@hostspezial.de; pct=100; adkim=r; aspf=r"

Beim SPF-Eintrag entscheidet das letzte Element über die Härte: -all (hard fail) weist alle nicht gelisteten Quellen ab, ~all (soft fail) markiert sie nur. Microsoft rät in der eigenen Dokumentation zur Einrichtung von SPF und DKIM ausdrücklich, mit ~all zu beginnen, solange nicht alle Versandquellen bekannt sind, und erst danach auf -all zu wechseln — derselbe Grundsatz wie später bei der DMARC-Politik selbst: erst beobachten, dann durchsetzen. Jede Subdomain braucht einen eigenen SPF-Eintrag; er wird nicht vererbt, was im Abschnitt „Wo es hakt" noch relevant wird.

Der DKIM-Schlüssel wird je Versandquelle erzeugt — ein Schlüssel für den eigenen Mailserver, ein weiterer für Microsoft 365 oder Google Workspace, ein dritter für jeden Newsletter-Dienstleister, der in Ihrem Namen verschickt. Der eigene, on-premise betriebene Mailserver braucht also seinen eigenen Selector genauso wie ein gehosteter Dienst — jede Quelle einen eigenen, damit sich ein kompromittierter Schlüssel isoliert widerrufen lässt, ohne die anderen Quellen zu beeinträchtigen.

/03Was Google und Microsoft 2026 tatsächlich verlangen

Seit dem 1. Februar 2024 verlangt Google von jedem Absender, der mehr als 5.000 Nachrichten pro Tag an Gmail-Adressen schickt, ein eigenes Bündel an Anforderungen: SPF und DKIM für die sendende Domain, einen DMARC-Eintrag (eine Politik von p=none genügt formal), eine gültige TLS-Verbindung beim Versand und bei Marketing- oder abonnierten Nachrichten eine funktionierende One-Click-Abmeldung. Zusätzlich verlangt Google, die Beschwerderate unter 0,3 Prozent zu halten — Google selbst empfiehlt, sie zur Sicherheit dauerhaft unter 0,10 Prozent zu führen. Absender unterhalb der 5.000er-Schwelle brauchen laut Google mindestens SPF oder DKIM.

Microsoft zieht seit dem 5. Mai 2025 nach, mit derselben Schwelle von 5.000 Nachrichten pro Tag an Outlook.com, Hotmail und Live.com. Verlangt werden SPF, DKIM und ein ausgerichteter DMARC-Eintrag mit mindestens p=none. Der Unterschied zu Google liegt in der Konsequenz: Nicht konforme Post wird nicht in den Spam-Ordner einsortiert, sondern direkt im SMTP-Dialog abgewiesen, mit dem Fehlercode 550 5.7.15 Access denied, sending domain [SendingDomain] does not meet the required authentication level. Der Absender erfährt vom Ausfall also sofort — der Empfänger nie, weil die Nachricht ihn gar nicht erst erreicht. Wer den Versand über Microsoft 365 abwickelt, konfiguriert SPF, DKIM und DMARC im selben Mandanten, in dem auch Entra ID die Benutzerkonten führt — beides gehört organisatorisch zusammen, auch wenn es zwei getrennte Baustellen sind.

Für die meisten Betriebe im deutschen Mittelstand liegt das eigene Volumen unterhalb der 5.000er-Schwelle — das befreit aber nicht von der Pflicht zur sauberen Konfiguration. Beide Anbieter werten fehlende oder fehlerhafte Authentifizierung schon unterhalb der Schwelle als Spam-Signal, weil die implizite Reputationsprüfung unabhängig vom Schwellenwert läuft. Und ein einzelner Newsletter-Versand über einen externen Dienstleister kann die eigene Zählung unerwartet über die Schwelle heben, ohne dass der eigentliche Absender das bemerkt.

/04Von p=none zu p=quarantine zu p=reject

Jede Umstellung beginnt bei p=none — Beobachtung, keine Wirkung. Nachrichten werden zugestellt wie zuvor, aber jeder große Empfänger schickt einen täglichen Bericht darüber, welche Quellen im Namen der eigenen Domain versendet haben und ob sie SPF und DKIM bestanden haben. Diese Phase ist Pflicht, kein optionaler Zwischenschritt: Ohne sie bleibt unsichtbar, welche Systeme beim Sprung auf Durchsetzung ausfallen würden.

Nach der Beobachtungsphase — in der Praxis so lange, bis über mehrere Wochen keine unbekannte legitime Quelle mehr in den Berichten auftaucht (Erfahrungswert, keine belastbare Studienlage dazu) — folgt p=quarantine, zunächst mit einem niedrigen pct-Wert. Das pct-Tag bestimmt, auf welchen Anteil der nicht ausgerichteten Nachrichten die Politik überhaupt angewendet wird: pct=25 trifft nur ein Viertel, der Rest läuft wie bei p=none weiter durch. Steigt man den Wert schrittweise auf 100, wird jeder verbleibende Fehlversuch sichtbar, ohne dass gleich der komplette Versand einer noch nicht erfassten Quelle in Quarantäne landet.

Erst wenn p=quarantine bei pct=100 über einen Zeitraum ohne Beschwerden läuft, ist p=reject an der Reihe. Ab hier gibt es keine Zustellung mehr für nicht ausgerichtete Post — keine Spam-Markierung, kein Zurückhalten zur Prüfung, sondern eine Ablehnung, die beim Absender als Unzustellbarkeitsmeldung ankommt und beim Empfänger überhaupt nicht. Für Subdomains, die nie zum Mailversand genutzt werden, lohnt sich p=reject dagegen sofort — über das Tag sp=reject in der Hauptdomain, ohne die eigentliche Versanddomain zu berühren.

# Stufe 1 — Beobachtung
"v=DMARC1; p=none; rua=mailto:dmarc-reports@hostspezial.de"

# Stufe 2 — Durchsetzung anteilig hochfahren
"v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@hostspezial.de"
"v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@hostspezial.de"

# Stufe 3 — volle Durchsetzung, ungenutzte Subdomains sofort sperren
"v=DMARC1; p=reject; pct=100; sp=reject; rua=mailto:dmarc-reports@hostspezial.de"

/05Aggregat-Berichte lesen, statt zu raten

Die Aggregat-Berichte (das rua-Tag) sind komprimierte XML-Dateien, die jeder größere Empfänger einmal täglich an die im DMARC-Eintrag hinterlegte Adresse schickt. Jeder Bericht enthält, aufgeschlüsselt nach Quell-IP, wie viele Nachrichten angekommen sind, ob SPF und DKIM bestanden wurden und wie die eigene Politik im konkreten Fall angewendet wurde.

<record>
  <row>
    <source_ip>203.0.113.42</source_ip>
    <count>184</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>hostspezial.de</header_from>
  </identifiers>
</record>

184 Nachrichten von einer einzelnen IP, SPF bestanden, DKIM fehlgeschlagen — ein typisches Muster für einen Newsletter-Dienstleister, der noch nicht mit einem eigenen DKIM-Schlüssel signiert. Weil DMARC nur eines von beiden braucht, wäre diese Quelle heute noch unauffällig; bei p=reject würde sie durchfallen, sobald der SPF-Pfad aus irgendeinem Grund einmal nicht greift — etwa nach einem IP-Wechsel beim Dienstleister.

Rohe XML-Dateien von Dutzenden Empfängern von Hand zu lesen, skaliert nicht über eine Handvoll Nachrichten hinaus. In der Praxis läuft die Auswertung über einen Parser (verbreitet ist etwa das quelloffene Werkzeug parsedmarc), der die Berichte einsammelt und zu einer Quellenliste verdichtet. Ein Betrieb, der ohnehin ein SOC betreibt, hängt diese Auswertung an denselben Rhythmus wie andere Sicherheitswarnungen — die Berichte sind kein Nebenprojekt, sondern ein weiterer Alarmkanal, nur eben für den eigenen Namen statt für die eigene Infrastruktur. Forensische Berichte (das ruf-Tag) enthalten dagegen Kopien einzelner Nachrichten und damit personenbezogene Daten im Sinne der DSGVO — die meisten großen Empfänger verschicken sie seit Jahren gar nicht mehr, unabhängig davon, ob man sie anfordert. In der Praxis wird die laufende Auswertung erst dann zur zumutbaren Aufgabe, wenn sie Teil eines Managed Service ist, statt eines Punkts auf einer Liste, die niemand regelmäßig abarbeitet.

/06Die drei Fälle, an denen KMU-Umstellungen scheitern

Der Newsletter-Dienstleister

Ein externer Versanddienst schickt im Namen der eigenen Domain, aber über eigene Server. SPF schlägt fehl, wenn die IPs des Dienstleisters nicht im eigenen SPF-Eintrag stehen — die einfachste Lösung ist ein include-Verweis auf den vom Dienstleister bereitgestellten SPF-Baustein. Robuster ist DKIM: Die meisten Anbieter liefern einen eigenen Selector, der als CNAME in die eigene Zone eingetragen wird. Fällt dann später der SPF-Pfad einmal aus — etwa bei einem IP-Wechsel beim Anbieter —, bleibt die Nachricht über DKIM trotzdem ausgerichtet.

Der Kopierer mit Scan-to-Mail

Multifunktionsgeräte versenden gescannte Dokumente häufig direkt aus dem lokalen Netz heraus, mit der Absenderadresse eines Mitarbeiters oder einer Sammeladresse, aber ohne jede Authentifizierung. Bei p=none fällt das nur in den Berichten auf; bei p=reject kommt der Scan beim Empfänger nicht mehr an — ein klassischer Fall, der erst nach der Umstellung als Ticket auftaucht. Zwei Wege führen heraus: das Gerät über den offiziellen Mailserver als Relay laufen lassen, statt direkt ins Internet zu senden, oder eine eigene Subdomain wie scan.hostspezial.de mit eigenem, lockerem SPF-Eintrag einrichten, die die Hauptdomain nicht gefährdet.

Die Fachanwendung mit Direktversand

ERP-Systeme, Ticket-Tools und branchenspezifische Software versenden oft direkt aus der Anwendung heraus — Rechnungen, Bestätigungen, automatische Benachrichtigungen. Ob auf einem eigenen Windows Server betrieben oder als SaaS bezogen: Diese Quellen sind der IT häufig gar nicht bekannt, weil ein Fachbereich sie ohne Rücksprache eingerichtet hat. Genau hier liegt das Risiko aus der Überschrift dieses Artikels — ein zu früher Sprung auf p=reject kappt den Rechnungsversand, nicht den Angriff.

/07BIMI: das Firmenlogo im Posteingang

Brand Indicators for Message Identification (BIMI) zeigt das eigene Logo neben dem Absendernamen an, in unterstützenden Postfächern wie Gmail, Apple Mail oder Yahoo. Technisch ist BIMI ein weiterer DNS-Eintrag, der auf eine SVG-Datei im Format SVG Tiny PS verweist — quadratisch, unter 32 KB, per HTTPS erreichbar. Voraussetzung ist eine DMARC-Politik auf Durchsetzungsstufe: p=quarantine oder p=reject, üblicherweise bei pct=100. Ohne diese Vorstufe akzeptiert kein Anbieter den BIMI-Eintrag — das Logo ist die Belohnung für eine bereits abgeschlossene Durchsetzung, kein Ersatz dafür.

Für die Anzeige selbst reicht ein reiner BIMI-Eintrag bei manchen Anbietern (etwa Yahoo, Fastmail, LaPoste laut Angabe der BIMI Group). Für die verlässliche Anzeige bei den großen Anbietern braucht es zusätzlich ein Zertifikat, und hier unterscheidet sich der Weg: Ein Verified Mark Certificate (VMC) setzt eine eingetragene Marke voraus und ist der Weg zum blauen Häkchen bei Gmail sowie zur Anzeige bei Apple Mail. Ein Common Mark Certificate (CMC) ist der neuere, von Gmail eingeführte Weg für Organisationen ohne eingetragene Marke — er verlangt stattdessen den Nachweis, dass das Logo bereits über einen längeren Zeitraum öffentlich auf der eigenen Domain verwendet wurde. Nach Angabe der BIMI Group ist die Unterstützung für CMCs unter den Postfachanbietern derzeit noch begrenzt.

Die ehrliche Rechnung: Zertifikate dieser Art sind kostenpflichtig und werden über akkreditierte Zertifizierungsstellen ausgestellt, nicht kostenlos wie die übrigen DNS-Einträge. Für Absender mit hohem Verbraucherkontakt — Banken, Versicherungen, große Handelsmarken — zahlt sich die Wiedererkennung im Posteingang aus. Für einen klassischen B2B-Mittelständler, dessen Post überwiegend an bekannte Ansprechpartner geht, ist der Effekt spürbar kleiner als der Aufwand, der vorher ohnehin für p=reject nötig war.

/08Wo es hakt

Weiterleitungen brechen SPF, manchmal auch DKIM

Server-basierte Weiterleitungen ändern die versendende IP-Adresse, wodurch SPF beim Empfänger scheitert — ein bekanntes, dokumentiertes Verhalten. DKIM übersteht Weiterleitungen in der Regel, sofern Kopfzeilen und Inhalt unverändert bleiben. Genau das ist bei Mailinglisten und manchen Sicherheitsdiensten aber oft nicht der Fall, wenn sie eine Fußzeile einfügen oder die Betreffzeile ändern — dann bricht auch die Signatur, und die Nachricht fällt trotz legitimer Herkunft durch DMARC. Für diesen Fall existiert mit Authenticated Received Chain (ARC) ein Zusatzmechanismus, der die ursprüngliche Prüfung durch vertrauenswürdige Zwischenstationen an den nächsten Server weiterreicht — die Unterstützung auf der Empfängerseite ist allerdings uneinheitlich.

Vergessene Subdomains

SPF-Einträge vererben sich nicht an Subdomains — jede braucht ihren eigenen. Wer das übersieht, hinterlässt ungenutzte Subdomains ohne jede Absenderregel, und genau die lassen sich für Spoofing-Versuche missbrauchen, ohne dass die Hauptdomain betroffen wäre. Das sp-Tag im DMARC-Eintrag der Hauptdomain schließt diese Lücke pauschal für alle nicht gesondert geregelten Subdomains.

Der Standard bewegt sich weiter

Im Mai 2026 ist mit RFC 9989 die überarbeitete Fassung von DMARC erschienen und hat den bisherigen Standard RFC 7489 abgelöst — unter anderem mit einem robusteren Verfahren zur Ermittlung der zuständigen Organisationsdomain und einer erweiterten Auswertung für Betreiber öffentlicher Domain-Suffixe. Für den laufenden Betrieb ändert sich dadurch wenig, aber es zeigt: Wer eine Politik einmal einrichtet und nie wieder anschaut, arbeitet irgendwann gegen einen veralteten Stand.

Denn Phishing bleibt der häufigste Einstiegsvektor für Ransomware — und dagegen hilft die eigene DMARC-Politik nichts, weil sie ausgehende Post regelt, nicht eingehende. Der wirksame Hebel gegen Angriffe, die bei den eigenen Mitarbeitern ankommen, bleibt MFA als Schadensbegrenzung bei gestohlenen Zugangsdaten, kombiniert mit wiederkehrendem Training. Wird der eigene Name trotzdem für Betrug gegen Dritte missbraucht — etwa CEO-Fraud über eine Lookalike-Domain —, ist das ein Fall für die Incident-Response, nicht für die DNS-Konfiguration.

/09Wann sich die Durchsetzung lohnt — und wann Sie warten sollten

p=none lohnt sich praktisch immer und sofort: Es kostet nichts, verändert nichts an der Zustellung und liefert ab dem ersten Tag Sichtbarkeit über die eigenen Versandquellen. Die Entscheidung, die tatsächlich Abwägung braucht, ist der Sprung auf Durchsetzung.

Er lohnt sich besonders dort, wo die Versandquellen bereits inventarisiert sind und die Berichte über mehrere Wochen keine Überraschung mehr zeigen — und dort, wo Dritte ohnehin danach fragen: Betreiber, die unter die NIS2-Meldepflichten fallen oder als KRITIS-Einrichtung gelten, ebenso wie Unternehmen, deren Versicherer im Fragebogen zur Cyberversicherung zunehmend explizit nach SPF, DKIM und DMARC fragt. E-Mail-Authentifizierung gehört inzwischen zu den Punkten, die im Nachweis der technischen und organisatorischen Maßnahmen regelmäßig auftauchen — sie ist eine technische Maßnahme mit Bezug zur DSGVO, keine reine Marketing-Frage.

Warten sollte, wer die eigenen Versandquellen noch nicht kennt und keine Kapazität hat, wochenlang Berichte zu lesen. Ein zu schneller Sprung auf p=reject ist in diesem Fall das größere Risiko als der Zustand davor — die eigene Buchhaltung merkt es zuerst, wenn Rechnungen plötzlich nicht mehr ankommen, nicht die IT. Die Reihenfolge aus Abschnitt vier ist deshalb keine Formalie, sondern der Unterschied zwischen einer kontrollierten Umstellung und einem selbst verursachten Ausfall.

/10Häufige Fragen