Jeder kann Ihre Domain in die Absenderzeile einer E-Mail tippen. Mit SPF, DKIM und DMARC kann der empfangende Server prüfen, ob eine Nachricht wirklich von Ihnen stammt, und Sie können ihm sagen, was er tun soll, wenn nicht. Sorgfältig eingerichtet, erschweren sie das Spoofing Ihrer exakten Domain erheblich. Überhastet eingeführt, können sie Ihre eigenen Rechnungen blockieren.
Was die einzelnen Mechanismen leisten
SPF (Sender Policy Framework, RFC 7208) ist ein DNS-TXT-Eintrag, der die Server auflistet, die E-Mails für eine Domain senden dürfen. Der Empfänger vergleicht die IP-Adresse des verbindenden Servers mit dieser Liste. SPF prüft den Envelope-Absender (die Identitäten MAIL FROM und HELO), nicht die From-Adresse, die der Empfänger sieht.
DKIM (DomainKeys Identified Mail, RFC 6376) versieht jede Nachricht mit einer kryptografischen Signatur. Das Tag d= nennt die signierende Domain, s= einen Selektor. Der öffentliche Schlüssel wird im DNS unter selector._domainkey.domain veröffentlicht. Eine gültige Signatur zeigt, dass sich die signierten Teile der Nachricht nicht verändert haben, seit diese Domain sie signiert hat.
DMARC verknüpft beides mit der sichtbaren From-Domain. Eine überarbeitete Fassung erschien im Mai 2026 als RFC 9989, ein Dokument auf dem Standards Track, das RFC 7489 ablöst. Ein DMARC-Eintrag legt Ihre Richtlinie fest und bittet Empfänger, Ihnen Berichte zu senden.
| Mechanismus | Was er belegt | Veröffentlicht unter | Lücke, wenn allein eingesetzt |
|---|---|---|---|
| SPF | Die sendende IP ist für die Envelope-Domain autorisiert | Der Domain selbst | Sagt nichts über die From-Adresse, die Menschen lesen |
| DKIM | Eine Domain bürgt für die Nachricht | selector._domainkey.domain | Die signierende Domain kann jede beliebige Domain sein |
| DMARC | SPF oder DKIM wurde für eine Domain bestanden, die zur From-Domain passt | _dmarc.domain | Setzt voraus, dass SPF und DKIM zuerst korrekt sind |
Ausrichtung: der Teil, der oft übersehen wird
Eine Nachricht besteht DMARC, wenn SPF oder DKIM besteht und die authentifizierte Domain zur From-Domain ausgerichtet ist (Alignment). Die lockere Ausrichtung (relaxed), die Voreinstellung, akzeptiert eine Übereinstimmung auf Ebene der Organisationsdomain; mail.example.eu passt also zu example.eu. Die strenge Ausrichtung (adkim=s oder aspf=s) verlangt eine exakte Übereinstimmung.
Bei Drittanbietern, die in Ihrem Namen senden, geht es meist schief. Eine Newsletter-Plattform verwendet vielleicht eine Envelope-Domain wie bounces.platform.example. SPF besteht für die Domain der Plattform, doch diese ist nicht zu example.eu ausgerichtet und trägt daher nichts zu Ihrem DMARC-Ergebnis bei.
Die Lösung: Lassen Sie die Plattform mit DKIM unter d=example.eu signieren oder konfigurieren Sie einen eigenen Return-Path auf einer Ihrer Subdomains. RFC 9989 empfiehlt Domaininhabern, SPF und DKIM gemeinsam einzusetzen. So kann einer der beiden das Ergebnis noch tragen, wenn der andere scheitert, etwa nach einer Weiterleitung.
So sehen die Einträge aus
Die Beispiele unten verwenden eine IP-Adresse aus dem Dokumentationsbereich und einen Platzhalter-Anbieter. Ersetzen Sie sie durch Ihre eigenen Werte.
example.eu. TXT "v=spf1 include:spf.mail-provider.example ip4:203.0.113.25 ~all"
s2026._domainkey.example.eu. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
_dmarc.example.eu. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.eu"Der DMARC-Eintrag oben steht im Überwachungsmodus. Er fordert aggregierte Berichte an, verlangt aber keine Maßnahme bei E-Mails, die durchfallen. Aggregierte Berichte, inzwischen in RFC 9990 spezifiziert, zeigen, welche Server E-Mails mit Ihrer Domain versenden und ob sie die Prüfungen bestehen.
Für DKIM-Schlüssel verlangt RFC 6376 bei langlebigen Schlüsseln RSA mit mindestens 1024 Bit. Google verlangt für E-Mails an private Gmail-Konten mindestens 1024 Bit und empfiehlt 2048 Bit, sofern Ihr Anbieter das unterstützt.
Sicher von p=none zu p=reject
- Erfassen Sie jeden Absender. Dazu gehören Ihre Mail-Plattform, CRM, Rechnungs- und Lohnabrechnungssysteme, Helpdesk, Website-Formulare und Geräte wie Scanner, die Dokumente per E-Mail versenden.
- Richten Sie für jeden SPF und DKIM ein. Bitten Sie jeden Dienst, mit DKIM unter Ihrer eigenen Domain zu signieren, wo immer er das zulässt.
- Veröffentlichen Sie
p=nonemit einerrua-Adresse. RFC 9989 beschreibt das als üblichen Ausgangspunkt, damit Sie Absender finden, die Sie bei der Einrichtung übersehen haben. - Werten Sie die Berichte aus und schließen Sie Lücken. Nehmen Sie sich mindestens einige Wochen Zeit, länger, wenn Sie monatliche oder vierteljährliche Versandläufe wie Lohnabrechnungen oder Jahresauszüge haben.
- Wechseln Sie zu
p=quarantine, dann zup=reject. RFC 9989 hat das alte Tagpctentfernt. Ersetzt wird es durch den Testmodus:t=ybittet Empfänger, die Richtlinie eine Stufe milder anzuwenden;p=reject; t=ywird also wie quarantine behandelt. - Berücksichtigen Sie Subdomains und geparkte Domains. Das Tag
splegt die Richtlinie für existierende Subdomains fest, das neue Tagnpgilt für Subdomains, die nicht existieren.
Verstehen Sie t=y als Abmilderung, nicht als Garantie. Sowohl RFC 7489 als auch RFC 9989 weisen Empfänger an, unbekannte Tags zu ignorieren. Ein Empfänger, der die neue Spezifikation noch nicht umgesetzt hat, wendet Ihre veröffentlichte Richtlinie daher womöglich vollständig an.
Zu Schritt 6: Eine Domain, die nie E-Mails versendet, sollte das ausdrücklich erklären. Veröffentlichen Sie einen SPF-Eintrag, der niemanden autorisiert, und eine Reject-Richtlinie:
parked-example.eu. TXT "v=spf1 -all"
_dmarc.parked-example.eu. TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.eu"
parked-example.eu._report._dmarc.example.eu. TXT "v=DMARC1"Der dritte Eintrag ist wichtig, weil die Berichte an eine andere Domain gehen. RFC 9990 verlangt von Empfängern, vor dem Versand zu prüfen, ob die Zieldomain zugestimmt hat, Berichte für die Richtliniendomain anzunehmen.
Große Postfachanbieter erwarten diese Arbeit bereits. Seit dem 1. Februar 2024 verlangt Google von Massenversendern (mehr als 5.000 Nachrichten pro Tag an Gmail) SPF, DKIM und DMARC mit Ausrichtung. Eine Richtlinie p=none erfüllt dieses Minimum, schützt Ihre Domain aber nicht.
Häufige Fehler
Zwei SPF-Einträge
Eine Domain darf nur einen SPF-Eintrag veröffentlichen. Findet ein Empfänger mehr als einen, lautet das SPF-Ergebnis permerror statt pass. Wenn Sie einen neuen Dienst hinzufügen, nehmen Sie dessen include in den bestehenden Eintrag auf, statt einen zweiten anzulegen.
Mehr als zehn DNS-Lookups
RFC 7208 begrenzt die SPF-Auswertung auf 10 Ausdrücke, die DNS-Abfragen auslösen: include, a, mx, ptr, exists und den Modifikator redirect. Includes, die in Ihren Includes verschachtelt sind, zählen ebenfalls. Wird das Limit überschritten, lautet das Ergebnis permerror.
Die Ausdrücke ip4, ip6 und all zählen nicht; es hilft also, die eigenen Server per Adresse aufzuführen. Entfernen Sie Includes für Dienste, die Sie nicht mehr nutzen. Der RFC empfiehlt außerdem, sogenannte „Void Lookups“, also Abfragen ohne Antwort, auf zwei zu begrenzen.
+all und ?all
Der Mechanismus all trifft immer zu; sein Qualifier bestimmt das Ergebnis. +all autorisiert daher jeden Server im Internet – veröffentlichen Sie es nie. ?all ergibt neutral, was laut RFC 7208 genau so zu behandeln ist, als gäbe es kein SPF-Ergebnis. Verwenden Sie ~all (softfail) oder -all (fail).
Welches von beiden? Die ursprüngliche DMARC-Spezifikation (RFC 7489, Abschnitt 6.7) weist darauf hin, dass eine Ablehnung bei SPF-Fail den Empfänger daran hindert, DKIM auszuwerten. Das kann weitergeleiteten E-Mails schaden, bei denen SPF scheitert, die DKIM-Signatur aber noch gültig ist. Sobald DMARC durchgesetzt wird, überlässt ~all die endgültige Entscheidung DMARC.
Weiterleitungen und Mailinglisten ignorieren
Eine weitergeleitete Nachricht kommt von der IP-Adresse des Weiterleitenden, die nicht in Ihrem SPF-Eintrag steht. Eine DKIM-Signatur übersteht die Weiterleitung meist, sofern die Nachricht nicht verändert wird. Mailinglisten, die den Betreff ändern oder eine Fußzeile anfügen, können sie allerdings brechen. Deshalb ist eine zuverlässige DKIM-Signatur unter Ihrer eigenen Domain beim Wechsel zu p=reject wichtiger als SPF.
ptr verwenden
Laut RFC 7208 sollte der Mechanismus ptr nicht veröffentlicht werden. Er ist langsam, weniger zuverlässig und zählt trotzdem zum Lookup-Limit.
Durchsetzen, ohne Berichte zu lesen
Wer direkt auf p=reject springt, blockiert schnell die eigenen Passwort-Resets, Rechnungen oder Support-Antworten. Die Berichte zeigen Ihnen, welche Absender Sie vergessen haben. Lesen Sie sie, bevor Sie durchsetzen, und lesen Sie sie auch danach weiter, denn es kommen neue Dienste hinzu.
Wo Sie anfangen
- Prüfen Sie mit unserem E-Mail-Sicherheitscheck, was Ihre Domain heute veröffentlicht.
- Erstellen oder bereinigen Sie Ihre Einträge mit dem SPF- und DMARC-Generator.
- Notieren Sie jedes System, das E-Mails im Namen Ihrer Domain versendet. Diese Liste brauchen Sie, bevor Sie durchsetzen.
- Veröffentlichen Sie jetzt
p=nonemit einer Berichtsadresse und legen Sie einen Termin fest, um die ersten Berichte auszuwerten. - Ergänzen Sie
v=spf1 -allund einen DMARC-Eintrag mitp=rejectfür jede Ihrer Domains, die keine E-Mails versendet.
Wenn Sie die Auswertung der Berichte und den Weg zur Durchsetzung lieber abgeben möchten, unterstützt Sie unser Managed-Security-Service bei beidem.
