Kurz gesagt: SPF, DKIM und DMARC sind drei DNS-Einträge, mit denen empfangende Mailserver prüfen, ob eine E-Mail wirklich von Ihrer Domain kommt. SPF nennt die erlaubten Server, DKIM signiert jede Nachricht, DMARC legt fest, was mit Mails passiert, die durchfallen, und schickt Ihnen Berichte. Seit Februar 2024 verlangen Gmail und Yahoo von allen Absendern SPF oder DKIM, von Massenversendern zusätzlich DMARC. Richten Sie DMARC stufenweise ein, von none über quarantine bis reject.
Das Problem: gefälschte Absender
Im E-Mail-Protokoll kann jeder Server eine beliebige Absenderadresse eintragen. Ein Betrüger verschickt also ohne Weiteres eine Mail von „[email protected]“, obwohl er mit Ihrer Firma nichts zu tun hat. Dieses Spoofing ist die Grundlage vieler Phishing-Angriffe: Ihre Kunden erhalten eine scheinbar echte Rechnung mit falscher Bankverbindung.
Gleichzeitig leidet Ihre eigene Zustellbarkeit. Empfangende Server können echte und gefälschte Mails ohne Authentifizierung schlecht unterscheiden. Im Zweifel landen dann auch Ihre legitimen E-Mails im Spam-Ordner. SPF, DKIM und DMARC lösen beide Probleme zusammen.
SPF: Welche Server dürfen für Ihre Domain senden?
Das Sender Policy Framework (SPF, RFC 7208 vom April 2014) ist ein TXT-Eintrag im DNS Ihrer Domain. Er listet die Server und Dienste, die E-Mails im Namen Ihrer Domain versenden dürfen. Der empfangende Server vergleicht die IP-Adresse des Absenders mit dieser Liste.
example.com. IN TXT "v=spf1 mx include:_spf.mailanbieter.example ip4:203.0.113.10 -all"Der Eintrag erlaubt die eigenen Mailserver (mx), alle Server eines Mailanbieters (include) und eine einzelne IP-Adresse. -all am Ende heißt: Alle anderen Server sind nicht autorisiert. Mit ~all (Softfail) markieren Empfänger solche Mails nur als verdächtig.
Zwei Regeln sind wichtig. Pro Domain darf es nur einen SPF-Eintrag geben. Und die Auswertung darf laut RFC 7208 höchstens zehn DNS-Abfragen auslösen; jedes include, a und mx zählt mit. Wer viele Dienste einbindet, etwa Newsletter, Shop und Ticketsystem, stößt schnell an diese Grenze, und dann schlägt SPF komplett fehl.
DKIM: digitale Signatur für jede E-Mail
DomainKeys Identified Mail (DKIM, RFC 6376 vom September 2011) setzt auf Kryptografie. Ihr Mailserver signiert jede ausgehende Nachricht mit einem privaten Schlüssel. Den öffentlichen Schlüssel veröffentlichen Sie im DNS. Der Server des Empfängers prüft damit, ob die Signatur stimmt und ob der Inhalt auf dem Weg verändert wurde.
mail2026._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...IDAQAB"„mail2026“ ist der Selektor, ein frei gewählter Name. So kann eine Domain mehrere DKIM-Schlüssel haben, zum Beispiel einen für das Postfach und einen für den Newsletter-Dienst. Den Schlüssel erzeugen Sie meist nicht selbst: Ihr Mailanbieter zeigt Ihnen im Kundenmenü den Eintrag, den Sie ins DNS kopieren. Ein großer Vorteil von DKIM: Die Signatur bleibt bei Weiterleitungen meist gültig, SPF dagegen scheitert dabei oft.
DMARC: Regeln und Berichte
Domain-based Message Authentication, Reporting and Conformance (DMARC) baut auf SPF und DKIM auf. Der Eintrag sagt dem Empfänger, was er mit Mails tun soll, die beide Prüfungen nicht bestehen, und wohin er Berichte schickt.
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"p ist die Richtlinie (Policy), rua die Adresse für Sammelberichte. Für Subdomains können Sie mit sp eine eigene Richtlinie festlegen.
Alignment: Die Domains müssen zusammenpassen
DMARC prüft mehr als SPF und DKIM allein. Es verlangt, dass die geprüfte Domain zur sichtbaren Absenderadresse im Feld „Von“ passt. Das nennt man Alignment. Ein Beispiel: Ihr Newsletter-Dienst versendet mit seiner eigenen Domain im Hintergrund und signiert mit seinem eigenen DKIM-Schlüssel. SPF und DKIM bestehen, aber für den Dienst, nicht für example.com. DMARC schlägt dann trotzdem fehl. Die Lösung ist eine DKIM-Signatur mit Ihrer eigenen Domain, die fast alle Versanddienste anbieten. Es reicht, wenn SPF oder DKIM besteht und dabei zur Absenderdomain passt.
Stufenweise einrichten: none, quarantine, reject
- p=none: Der Empfänger ändert nichts an der Zustellung, schickt Ihnen aber Berichte. Lassen Sie diese Stufe einige Wochen laufen.
- Berichte auswerten: Die rua-Berichte sind XML-Dateien. Sie zeigen, welche Server in Ihrem Namen senden und ob SPF und DKIM dabei bestehen. Oft tauchen dabei vergessene Absender auf, etwa das Kontaktformular der Website, die Buchhaltungssoftware oder ein Drucker.
- p=quarantine: Wenn alle legitimen Absender sauber authentifiziert sind, landen Mails, die durchfallen, im Spam-Ordner.
- p=reject: Der Empfänger weist solche Mails ganz ab. Erst diese Stufe schützt Ihre Domain wirksam vor Spoofing.
Wer zu schnell auf reject geht, riskiert, dass eigene Rechnungen oder Newsletter nicht mehr ankommen. Gehen Sie deshalb erst eine Stufe weiter, wenn die Berichte sauber sind.
Was Gmail und Yahoo seit Februar 2024 verlangen
Seit dem 1. Februar 2024 gelten bei Gmail strengere Regeln. Alle Absender brauchen SPF oder DKIM, einen gültigen Reverse-DNS-Eintrag (PTR) für den sendenden Server und eine TLS-Verbindung. Die Spamrate soll unter 0,3 Prozent bleiben. Wer mehr als 5.000 Mails am Tag an Gmail-Adressen schickt, braucht zusätzlich SPF, DKIM und DMARC. Dabei darf die DMARC-Policy auf none stehen, das Alignment muss aber stimmen. Marketing-Mails brauchen außerdem eine Abmeldung mit einem Klick.
Yahoo hat zur gleichen Zeit ähnliche Anforderungen für Massenversender eingeführt, ebenfalls mit DMARC mindestens auf p=none. Eine feste Mengengrenze nennt Yahoo nicht. Für Ihren Newsletter heißt das: Ohne saubere E-Mail-Authentifizierung kommt er bei diesen Anbietern schlechter oder gar nicht an. Wie Newsletter in eine Content-Planung passen, lesen Sie im Artikel Content-Marketing-Strategie.
Domains ohne Mailversand absichern
Viele Firmen besitzen mehrere Domains, etwa Tippfehler-Varianten oder Domains für alte Projekte. Auch über sie können Betrüger Mails fälschen. Für eine Domain, die nie E-Mails versendet, reichen diese Einträge:
example.com. IN TXT "v=spf1 -all" _dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=reject" example.com. IN MX 0 .Der SPF-Eintrag erlaubt keinen einzigen Server. DMARC weist alles ab, auch für Subdomains. Der sogenannte Null-MX-Eintrag nach RFC 7505 zeigt an, dass die Domain auch keine Mails empfängt. Einen DKIM-Schlüssel brauchen Sie für eine solche Domain nicht.
Die Standards hinter SPF, DKIM und DMARC
- SPF: RFC 7208, April 2014
- DKIM: RFC 6376, September 2011, Internet-Standard STD 76
- DMARC: ursprünglich RFC 7489 von 2015. Im Mai 2026 hat die IETF eine Neufassung in drei Teilen veröffentlicht: RFC 9989 (das Protokoll selbst), RFC 9990 (Sammelberichte) und RFC 9991 (Fehlerberichte). Sie ersetzen RFC 7489.
Für bestehende Einträge mit v=DMARC1, p und rua ändert sich durch die Neufassung im Alltag wenig. Ältere Zusätze wie pct sind darin nicht mehr vorgesehen. Für Anbieter von E-Mail-Diensten hat das BSI außerdem die Technische Richtlinie TR-03182 zur E-Mail-Authentifizierung veröffentlicht.
SPF, DKIM und DMARC prüfen
Ob Ihre Einträge stimmen, sehen Sie mit einer DNS-Abfrage. Unter macOS und Linux nutzen Sie dig:
dig TXT example.com +short dig TXT _dmarc.example.com +short dig TXT mail2026._domainkey.example.com +shortUnter Windows funktioniert nslookup:
nslookup -type=TXT _dmarc.example.comNoch genauer ist ein Blick in eine echte E-Mail. Schicken Sie sich eine Nachricht an ein Gmail-Postfach und öffnen Sie dort „Original anzeigen“. Gmail zeigt für SPF, DKIM und DMARC jeweils PASS oder FAIL an. Die E-Mail-Einträge sind auch Teil eines vollständigen Checks, wie wir ihn im Artikel Website-Sicherheit prüfen beschreiben. Wer gerade an der Domain arbeitet, findet bei den Security-Headern den nächsten Schritt.
Fazit
SPF nennt die erlaubten Server, DKIM signiert die Nachrichten, DMARC verbindet beides mit einer Regel und liefert Berichte. Richten Sie zuerst SPF und DKIM ein, starten Sie DMARC mit p=none und verschärfen Sie die Policy, sobald die Berichte keine unbekannten Absender mehr zeigen. Vergessen Sie dabei die Domains ohne Mailversand nicht. Mehr zum Thema finden Sie auf unserer Themenseite E-Mail-Sicherheit.
Quellen: RFC 7208 (SPF), RFC 6376 (DKIM), RFC 7489 sowie RFC 9989, 9990 und 9991 (DMARC, Mai 2026), RFC 7505 (Null MX); Google, Richtlinien für E-Mail-Absender (gültig ab 01.02.2024); Yahoo Sender Hub, Anforderungen für Bulk-Sender (2024); BSI TR-03182; RFC-Editor, Metadaten zu RFC 7489 (ersetzt durch RFC 9989–9991).