SPF, DKIM und DMARC einfach erklärt – E-Mail-Sicherheit prüfen

Eine E-Mail von rechnung@deine-firma.de sieht auf den ersten Blick vertrauenswürdig aus. Doch stammt sie wirklich von deinem Mailserver?

Genau hier liegt eines der grundsätzlichen Probleme von E-Mail: Das klassische SMTP-Protokoll wurde ursprünglich nicht dafür entwickelt, zuverlässig zu überprüfen, ob ein Absender tatsächlich derjenige ist, für den er sich ausgibt. Microsoft beschreibt dieses Grundproblem ebenfalls ausdrücklich: Eine normale SMTP-Nachricht validiert den behaupteten Absender nicht automatisch.

Das macht gefälschte Absenderadressen möglich. Angreifer können beispielsweise versuchen, Nachrichten mit Absendern wie buchhaltung@firma.de, support@unternehmen.de, chef@unternehmen.de oder rechnung@shop.de zu verschicken, obwohl die Nachricht überhaupt nicht über die Mailserver dieser Domains versendet wurde.

Damit empfangende Mailserver solche Manipulationen erkennen können, existieren drei wichtige Verfahren: SPF, DKIM und DMARC. Gemeinsam bilden sie heute einen zentralen Bestandteil moderner E-Mail-Authentifizierung. Microsoft empfiehlt ausdrücklich, SPF, DKIM und DMARC gemeinsam einzusetzen, da die Verfahren aufeinander aufbauen.

In diesem Artikel erfährst du, was sich hinter den drei Abkürzungen verbirgt, warum sie auch für kleinere Domains wichtig sind und wie du deine eigene E-Mail-Sicherheit überprüfen kannst.

Was sind SPF, DKIM und DMARC?

Vereinfacht kann man sich die drei Verfahren so merken:

Verfahren	Aufgabe
SPF	Welche Server dürfen E-Mails für meine Domain versenden?
DKIM	Wurde diese E-Mail tatsächlich kryptografisch signiert und unterwegs verändert?
DMARC	Stimmen sichtbarer Absender und Authentifizierung zusammen – und was soll bei Fehlern passieren?

Oder noch einfacher: SPF kontrolliert den Versandweg. DKIM kontrolliert die Signatur. DMARC kontrolliert das Zusammenspiel.

Was ist SPF?

SPF steht für Sender Policy Framework. Mit SPF veröffentlicht der Eigentümer einer Domain im DNS, welche Systeme E-Mails für diese Domain versenden dürfen.

Der aktuelle SPF-Standard ist in RFC 7208 beschrieben. Der empfangende Mailserver kann damit überprüfen, ob der sendende Host für die verwendete MAIL-FROM-Domain autorisiert ist.

Ein vereinfachter SPF-Eintrag könnte beispielsweise so aussehen:

v=spf1 ip4:203.0.113.10 include:_spf.mailanbieter.example -all

Dieser Eintrag bedeutet sinngemäß: Die angegebene IP-Adresse und die Server des eingebundenen Mailanbieters dürfen E-Mails für diese Domain versenden. Andere Systeme nicht.

Wo befindet sich der SPF-Record?

SPF wird über einen TXT-Record im DNS veröffentlicht. Du kannst ihn beispielsweise unter Linux oder macOS mit dig prüfen:

dig TXT example.de

Alternativ:

host -t TXT example.de

Unter Windows funktioniert beispielsweise:

nslookup -type=TXT example.de

Der SPF-Standard schreibt die Veröffentlichung über DNS-TXT-Records vor. Außerdem darf für einen Domainnamen nicht einfach eine beliebige Anzahl paralleler SPF-Records veröffentlicht werden; mehrere gleichzeitig ausgewählte SPF-Records führen zu einem permanenten SPF-Fehler.

Was bedeuten -all und ~all?

Am Ende vieler SPF-Einträge findest du beispielsweise -all oder ~all. Diese Zeichen haben unterschiedliche Bedeutungen.

-all – Fail: Nicht aufgeführte Absender sind laut SPF-Policy nicht autorisiert.

~all – Softfail: Nicht aufgeführte Systeme sind wahrscheinlich nicht autorisiert, die Aussage ist jedoch weniger strikt.

RFC 7208 unterscheidet unter anderem zwischen pass, fail, softfail und neutral. Ein typisches Beispiel eines Mailanbieters könnte etwa so aussehen:

v=spf1 include:_spf.example.net ~all

Welcher Eintrag für deine Domain korrekt ist, hängt allerdings davon ab, welche Systeme tatsächlich E-Mails versenden.

Häufiger SPF-Fehler: Nicht alle Absender berücksichtigt

Genau hier entstehen in Unternehmen häufig Probleme. Vielleicht läuft die normale Firmen-E-Mail über Microsoft 365 oder Google Workspace. Zusätzlich verschicken aber auch die Website, ein Newsletter-System, ein Ticketsystem, ein CRM, ein Webshop, eine Monitoring-Lösung, ein Rechnungsprogramm, ein Server oder ein Drucker beziehungsweise Multifunktionsgerät E-Mails unter derselben Domain.

Fehlt eines dieser Systeme im SPF-Konzept, können legitime Nachrichten bei Empfängern die SPF-Prüfung nicht bestehen. Deshalb sollte vor Änderungen zunächst eine vollständige Liste aller Systeme erstellt werden, die E-Mails im Namen der Domain versenden.

Vorsicht vor dem SPF-Lookup-Limit

Ein weiterer häufig übersehener Punkt ist die Anzahl der DNS-Abfragen. SPF erlaubt während einer Auswertung maximal 10 DNS-verursachende Mechanismen beziehungsweise Modifier wie beispielsweise include, a, mx, exists oder redirect. Wird dieses Limit überschritten, muss die SPF-Auswertung mit permerror fehlschlagen.

Ein scheinbar harmloser SPF-Record wie:

v=spf1 include:anbieter1.example include:anbieter2.example include:anbieter3.example -all

kann deshalb problematischer sein, als er aussieht. Jedes include kann wiederum weitere DNS-Abfragen auslösen. Gerade Domains mit zahlreichen Cloud-Diensten sollten ihren SPF-Record deshalb regelmäßig kontrollieren.

Was ist DKIM?

DKIM steht für DomainKeys Identified Mail. Während SPF kontrolliert, woher eine E-Mail kommt, arbeitet DKIM mit einer kryptografischen Signatur.

Beim Versand erzeugt der Mailserver eine digitale Signatur und fügt sie dem Header der E-Mail hinzu. Der private Schlüssel verbleibt beim Absender. Der passende öffentliche Schlüssel wird über DNS veröffentlicht.

Der empfangende Mailserver kann diesen Schlüssel abrufen und damit überprüfen, ob die DKIM-Signatur gültig ist. RFC 6376 beschreibt dieses Verfahren und die Veröffentlichung des öffentlichen Schlüssels über DNS.

DKIM vereinfacht erklärt

Stell dir vor, du verschickst einen Brief. SPF kontrolliert: Wurde der Brief in einem erlaubten Briefkasten eingeworfen? DKIM kontrolliert zusätzlich: Trägt der Brief das richtige Siegel und wurde sein Inhalt nach dem Versiegeln verändert? Genau deshalb ergänzen sich SPF und DKIM.

Wie sieht ein DKIM-Eintrag aus?

Ein DKIM-Key kann beispielsweise unter einem DNS-Namen wie diesem liegen:

selector1._domainkey.example.de

Der TXT-Record könnte vereinfacht enthalten:

v=DKIM1; k=rsa; p=MIIBIjANBgkqh...

Der lange Wert hinter p= enthält den öffentlichen Schlüssel.

Was ist der DKIM-Selector?

Damit eine Domain mehrere Schlüssel verwenden und Schlüssel austauschen kann, arbeitet DKIM mit sogenannten Selektoren. Ein DKIM-Header kann beispielsweise s=selector1 und d=example.de enthalten. Daraus ergibt sich die DNS-Abfrage selector1._domainkey.example.de.

Das ermöglicht beispielsweise eine Schlüsselrotation, ohne den gesamten Mailbetrieb gleichzeitig umstellen zu müssen. RFC 6376 sieht genau dieses Selector-Konzept für unterschiedliche beziehungsweise wechselnde Schlüssel vor.

DKIM unter Linux prüfen

Wenn der Selector bekannt ist:

dig TXT selector1._domainkey.example.de

oder:

host -t TXT selector1._domainkey.example.de

Unter Windows:

nslookup -type=TXT selector1._domainkey.example.de

Wichtig: Der Selector ist nicht immer selector1. Je nach Mailanbieter könnte er beispielsweise google, default, selector1, selector2, mail, dkim, s1 oder s2 heißen. Den tatsächlich verwendeten Selector findest du normalerweise in der Konfiguration deines Mailproviders oder im DKIM-Signature-Header einer versendeten Nachricht.

Was ist DMARC?

DMARC steht für Domain-based Message Authentication, Reporting and Conformance. DMARC verbindet SPF und DKIM mit der Domain, die der Empfänger tatsächlich im sichtbaren From:-Feld der E-Mail sieht.

Genau das ist entscheidend. Denn eine Nachricht könnte technisch einen gültigen SPF-Check bestehen – jedoch für eine vollkommen andere Domain als diejenige, die der Benutzer als Absender angezeigt bekommt. DMARC führt deshalb das sogenannte Domain Alignment ein.

Der aktuelle DMARC-Standard ist seit Mai 2026 RFC 9989. Er löst unter anderem den früher häufig genannten RFC 7489 ab.

Was bedeutet DMARC Alignment?

Angenommen, eine Nachricht zeigt From: rechnung@example.de. DKIM signiert aber mit d=irgendein-maildienst.example, und SPF authentifiziert ebenfalls nur eine andere Domain.

SPF oder DKIM können technisch erfolgreich sein – trotzdem muss daraus nicht automatisch ein erfolgreicher DMARC-Check entstehen. DMARC verlangt, dass mindestens eine erfolgreich authentifizierte Identität passend zur sichtbaren Absenderdomain ausgerichtet ist.

RFC 9989 unterscheidet zwischen relaxed Alignment und strict Alignment. Beim relaxed Alignment genügt in vielen Fällen dieselbe organisatorische Domain, während strict Alignment eine identische Domain verlangt.

Wie sieht ein DMARC-Record aus?

Ein einfacher DMARC-Eintrag könnte beispielsweise lauten:

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

Veröffentlicht wird er unter _dmarc.example.de. Prüfen kannst du ihn unter Linux mit:

dig TXT _dmarc.example.de

oder:

host -t TXT _dmarc.example.de

Unter Windows:

nslookup -type=TXT _dmarc.example.de

Was bedeuten p=none, p=quarantine und p=reject?

Der wichtigste Bestandteil einer DMARC-Konfiguration ist die Policy.

p=none (v=DMARC1; p=none): DMARC wird ausgewertet, aber die Domain fordert keine besondere Behandlung fehlgeschlagener Nachrichten. Diese Einstellung eignet sich vor allem für die Analysephase.

p=quarantine (v=DMARC1; p=quarantine): Bei fehlgeschlagener DMARC-Prüfung signalisiert die Domain dem Empfänger, dass die Nachricht verdächtig behandelt werden soll – beispielsweise durch eine Einstufung in den Spam- beziehungsweise Quarantänebereich.

p=reject (v=DMARC1; p=reject): Damit signalisiert der Domaininhaber die strengste Richtlinie für Nachrichten, die DMARC nicht bestehen.

Wichtig ist allerdings: Eine DMARC-Policy ist Teil der Entscheidungsgrundlage des empfangenden Systems. Der aktuelle RFC weist ausdrücklich darauf hin, dass Mail-Receiver auch weitere Informationen und lokale Bewertungen berücksichtigen.

Warum sollte man nicht sofort mit p=reject beginnen?

Weil du möglicherweise legitime Absender vergessen hast. Beispielsweise: Website → externer SMTP-Dienst → E-Mail mit deiner Domain. Oder: CRM → Cloud-Mailanbieter → Kunde.

Sind SPF, DKIM oder das Alignment für einen solchen Dienst falsch eingerichtet, könnte eine strengere DMARC-Policy legitime E-Mails beeinträchtigen. Google empfiehlt deshalb ebenfalls, SPF und DKIM zunächst korrekt einzurichten und funktionieren zu lassen, bevor DMARC aktiviert beziehungsweise verschärft wird.

Ein sinnvoller Weg ist deshalb: SPF und DKIM konfigurieren → DMARC mit p=none → Reports beobachten → Fehler beheben → p=quarantine → weiter beobachten → gegebenenfalls p=reject.

Was ist rua bei DMARC?

Ein DMARC-Record kann beispielsweise rua=mailto:dmarc@example.de enthalten. rua definiert die Adresse beziehungsweise URI für aggregierte DMARC-Berichte. RFC 9989 führt rua ausdrücklich als Ziel für Aggregate Feedback Reports.

Diese Reports helfen dir zu erkennen, welche Systeme deine Domain verwenden, welche IP-Adressen E-Mails versenden, ob SPF, DKIM und DMARC erfolgreich sind und ob unbekannte Systeme deine Domain benutzen. Gerade dieser Reporting-Mechanismus macht DMARC für Administratoren besonders interessant.

SPF + DKIM + DMARC zusammen erklärt

So sieht der komplette Ablauf vereinfacht aus: E-Mail wird versendet → Empfänger prüft SPF (Ist der sendende Server erlaubt?) → Empfänger prüft DKIM (Ist die Signatur gültig?) → Empfänger prüft DMARC (Stimmt SPF oder DKIM mit der sichtbaren From-Domain überein?) → DMARC Pass / Fail → Spamfilter, Reputation und weitere Sicherheitsprüfungen.

SPF, DKIM und DMARC sind damit wichtige Bausteine – aber kein Ersatz für Spamfilter, Malware-Schutz oder weitere Sicherheitsmechanismen. Microsoft verwendet beispielsweise zusätzlich Reputation, Senderhistorie, Empfängerhistorie und Verhaltensanalysen zur Bewertung eingehender Nachrichten.

SPF, DKIM und DMARC direkt in einer E-Mail prüfen

Besonders zuverlässig ist ein Test mit einer tatsächlich versendeten Nachricht. Schicke beispielsweise eine E-Mail deiner Domain an ein externes Postfach. Anschließend lässt du dir den vollständigen Header anzeigen.

Dort findest du häufig einen Bereich ähnlich diesem:

Authentication-Results:
spf=pass
dkim=pass
dmarc=pass

Das wäre ein sehr gutes Ergebnis. Problematisch wären beispielsweise spf=fail, dkim=none, dmarc=fail oder spf=permerror. Microsoft dokumentiert die Auswertung von SPF, DKIM und DMARC ebenfalls über den Authentication-Results-Header.

Bei einer korrekt konfigurierten Domain möchtest du idealerweise etwas in dieser Richtung sehen: SPF: PASS, DKIM: PASS, DMARC: PASS. Damit hast du bereits eine sehr solide Grundlage für deine E-Mail-Authentifizierung.

Warum SPF allein nicht genügt

Ein häufiger Irrtum lautet: „Ich habe einen SPF-Eintrag. Damit ist meine Domain geschützt.“ Das stimmt so nicht.

SPF prüft hauptsächlich die beim SMTP-Versand verwendete MAIL-FROM- beziehungsweise Envelope-Domain. Die für den Benutzer sichtbare From:-Adresse ist ein anderer Bestandteil der E-Mail. Genau deshalb wird DMARC benötigt. Microsoft weist ebenfalls darauf hin, dass SPF alleine nicht ausreicht, um das Spoofing sichtbarer Absenderdomains zuverlässig zu verhindern.

Warum DKIM allein nicht genügt

Auch eine gültige DKIM-Signatur bedeutet zunächst nur, dass eine bestimmte Domain Verantwortung für die Signatur übernommen hat und die signierten Bestandteile seit der Signierung nicht unbemerkt verändert wurden. Die DKIM-Signatur muss nicht automatisch mit der sichtbaren Absenderdomain identisch sein. Erst DMARC stellt die Verbindung zwischen der authentifizierten Domain und der für den Benutzer sichtbaren From-Domain her.

Google, Yahoo und Microsoft erhöhen den Druck

SPF, DKIM und DMARC sind inzwischen längst nicht mehr nur ein Thema für besonders sicherheitsbewusste Administratoren. Große Mailanbieter verschärfen seit einigen Jahren ihre Anforderungen.

Google verlangt für Absender an private Gmail-Adressen mindestens SPF oder DKIM. Für Bulk-Sender mit mehr als 5.000 Nachrichten pro Tag gelten zusätzliche Anforderungen: SPF, DKIM und DMARC müssen eingerichtet sein.

Yahoo fordert ebenfalls für alle Absender mindestens SPF oder DKIM und für größere Versender weitergehende Authentifizierung einschließlich SPF, DKIM und DMARC.

Auch Microsoft setzt für High-Volume-Sender zu seinen Consumer-Maildiensten strengere Regeln durch. Ab 5.000 Nachrichten unter derselben From-Domain erwartet Microsoft SPF und DKIM sowie einen veröffentlichten DMARC-Eintrag und erfolgreiches DMARC-Alignment.

Damit wird deutlich: E-Mail-Authentifizierung ist 2026 nicht mehr nur eine optionale Sicherheitsoptimierung. Für professionelle Domains gehört sie zur technischen Grundausstattung.

Häufige Fehler bei SPF, DKIM und DMARC

Fehler 1: Mehrere SPF-Records

Zum Beispiel v=spf1 include:anbieter1.example -all und gleichzeitig v=spf1 include:anbieter2.example -all. Das ist kein sinnvoller Weg, mehrere Anbieter zu konfigurieren. Mehrere gleichzeitig ausgewählte SPF-Records führen laut SPF-Standard zu permerror. Die benötigten Versandquellen müssen in einem gültigen SPF-Konzept zusammengeführt werden.

Fehler 2: Newsletter-Anbieter vergessen

Die normale E-Mail läuft über Microsoft 365. Der Newsletter kommt jedoch über einen externen Anbieter. Wird dieser Dienst nicht korrekt authentifiziert, entstehen SPF-, DKIM- oder DMARC-Probleme.

Fehler 3: Website versendet direkt

Viele Webserver verschicken Formulare oder Shop-E-Mails direkt über PHP, lokale Maildienste oder externe SMTP-Relays. Auch diese Systeme müssen berücksichtigt werden.

Fehler 4: DMARC bleibt dauerhaft auf p=none

p=none ist hervorragend zum Beobachten. Wer seine legitimen Absender identifiziert und alle Fehler behoben hat, sollte anschließend prüfen, ob eine stärkere Policy sinnvoll ist. Sonst erhält man zwar Reports, schöpft das Schutzpotenzial von DMARC aber nicht vollständig aus.

Fehler 5: DMARC ohne Reporting

Ein Record wie v=DMARC1; p=none funktioniert grundsätzlich. Mit einem Reporting-Ziel wie rua=mailto:dmarc@example.de erhält der Domaininhaber jedoch wesentlich mehr Einblick in die tatsächliche Nutzung seiner Domain.

Praktischer E-Mail-Sicherheitscheck

Wer seine Domain prüfen möchte, kann in dieser Reihenfolge vorgehen.

1. SPF prüfen

dig TXT example.de

Fragen: Existiert SPF? Sind alle legitimen Mailserver enthalten? Gibt es nur einen gültigen SPF-Record? Wird das DNS-Lookup-Limit eingehalten?

2. DKIM prüfen

Zuerst eine Testmail versenden. Im Header nach folgendem Eintrag suchen: DKIM-Signature:. Dort Selector und Domain ermitteln. Anschließend:

dig TXT selector._domainkey.example.de

3. DMARC prüfen

dig TXT _dmarc.example.de

Mindestens sollte ein gültiger Record gefunden werden, beispielsweise v=DMARC1; p=none; rua=mailto:dmarc@example.de.

4. Test-E-Mail versenden

Danach den Header kontrollieren: spf=pass, dkim=pass, dmarc=pass.

5. DMARC-Reports auswerten

Kontrolliere anschließend bekannte Absender, unbekannte Versandserver, SPF-Fehler, DKIM-Fehler, Alignment-Probleme und mögliche Spoofing-Versuche. Diese DNS-Abfragen lassen sich außerdem gut zu einem wiederverwendbaren Diagnose-Skript bündeln, das dir ChatGPT auf Wunsch direkt erstellt. Shell-Skripte mit ChatGPT schreiben (Zum Artikel)

Kann SPF, DKIM und DMARC Phishing vollständig verhindern?

Nein. Die Verfahren reduzieren vor allem den erfolgreichen Missbrauch deiner Domain als gefälschten Absender. Ein Angreifer könnte trotzdem eine ähnlich aussehende Domain registrieren. Aus meinefirma.de könnte beispielsweise eine täuschend ähnlich aussehende Domain werden.

Deshalb gehören zu einer umfassenden E-Mail-Sicherheitsstrategie zusätzlich Spam- und Phishing-Filter, Malware-Schutz, sichere Benutzerkonten, Multi-Faktor-Authentifizierung, Schulung der Mitarbeiter, Domain-Monitoring, sichere Passwörter beziehungsweise Passkeys und regelmäßige Sicherheitsupdates.

SPF, DKIM und DMARC bilden eine wichtige technische Schutzschicht, ersetzen aber keine vollständige E-Mail-Sicherheitsstrategie. Auch moderne Mailanbieter kombinieren Authentifizierungsdaten mit zahlreichen weiteren Sicherheitssignalen.

Brauchen auch kleine Unternehmen DMARC?

Ja. Die Frage sollte weniger lauten: „Versenden wir genug E-Mails für DMARC?“, sondern: „Ist unsere Domain wichtig genug, dass niemand sie für gefälschte E-Mails benutzen sollte?“

Eine kleine Steuerkanzlei, ein Handwerksbetrieb oder ein Onlineshop verschickt vielleicht nur wenige hundert E-Mails im Monat. Eine gefälschte Nachricht wie „Bitte überweisen Sie die Rechnung auf unser neues Konto.“ kann trotzdem erheblichen Schaden verursachen. E-Mail-Authentifizierung ist deshalb nicht nur für Konzerne und Newsletter-Anbieter sinnvoll.

Wenn eine solche gefälschte Zahlungsaufforderung tatsächlich zugestellt wird oder ein Postfach kompromittiert wurde, zählt vor allem, wie schnell und strukturiert reagiert wird. Der Cyber Notfall Reaction Plan (Zum Produkt) enthält dafür unter anderem vorbereitete Sofortmaßnahmen für kompromittierte Microsoft-365-Konten.

Fazit: SPF, DKIM und DMARC gehören zu jeder professionellen Domain

SPF, DKIM und DMARC klingen zunächst nach komplizierter Administratorentechnik. Das Grundprinzip ist jedoch einfach: SPF sagt, wer senden darf. DKIM beweist kryptografisch, dass eine Nachricht korrekt signiert wurde. DMARC prüft, ob die authentifizierte Identität zur sichtbaren Absenderdomain passt und veröffentlicht eine Richtlinie für fehlgeschlagene Prüfungen.

Wer eine eigene Domain für E-Mails verwendet, sollte deshalb mindestens überprüfen, ob alle drei Mechanismen korrekt eingerichtet sind. Die wichtigste Zielmarke lautet: SPF: PASS, DKIM: PASS, DMARC: PASS.

Gerade weil Google, Yahoo und Microsoft ihre Anforderungen an authentifizierte E-Mails verschärft haben, gehört eine saubere E-Mail-Authentifizierung 2026 sowohl zur IT-Sicherheit als auch zu einer zuverlässigen Mailzustellung. Wer Diagnosebefehle und Logs ganz allgemein mit ChatGPT auswertet, findet weitere Beispiele im Beitrag Wie ich ChatGPT für Linux-Administration nutze (Zum Artikel).

Häufig gestellte Fragen zu SPF, DKIM und DMARC

Was ist wichtiger: SPF, DKIM oder DMARC?

Die Verfahren erfüllen unterschiedliche Aufgaben und sollten gemeinsam eingesetzt werden. SPF autorisiert Versandquellen, DKIM signiert Nachrichten und DMARC überprüft die Zuordnung zur sichtbaren Absenderdomain.

Wo werden SPF, DKIM und DMARC gespeichert?

Die Informationen werden über das DNS veröffentlicht. SPF und DMARC verwenden TXT-Records; auch DKIM veröffentlicht seinen öffentlichen Schlüssel typischerweise über DNS.

Kann ich SPF mit nslookup prüfen?

Ja. Unter Windows beispielsweise mit nslookup -type=TXT example.de. Für DMARC entsprechend mit nslookup -type=TXT _dmarc.example.de.

Wie erkenne ich, ob DKIM funktioniert?

Versende eine Testmail und überprüfe den vollständigen E-Mail-Header. Ein Ergebnis wie dkim=pass zeigt eine erfolgreiche DKIM-Prüfung.

Was bedeutet DMARC Pass?

DMARC besteht, wenn eine passende authentifizierte Identität vorhanden ist und das erforderliche Domain-Alignment zur sichtbaren Absenderdomain erfüllt wird.

Sollte ich sofort p=reject verwenden?

Nicht ohne vorherige Analyse. Zunächst sollten SPF und DKIM korrekt funktionieren und alle legitimen Versandquellen bekannt sein. Danach kann DMARC schrittweise verschärft werden.

Ist DMARC 2026 Pflicht?

Das hängt vom Empfänger und Versandvolumen ab. Google verlangt SPF, DKIM und DMARC für Bulk-Sender mit mehr als 5.000 Nachrichten täglich an persönliche Gmail-Konten. Microsoft verlangt Vergleichbares für High-Volume-Sender an seine Consumer-Maildienste, Yahoo hat ähnliche Anforderungen für Bulk-Sender.

Was ist der aktuelle DMARC-Standard?

Seit Mai 2026 ist RFC 9989 der aktuelle DMARC-Standard. Er ersetzt unter anderem RFC 7489.

Quellen und technische Referenzen

Für die technischen Aussagen dieses Artikels wurden insbesondere die aktuellen Spezifikationen und Dokumentationen von IETF, Google Workspace, Microsoft und Yahoo Sender Hub berücksichtigt. Der aktuelle DMARC-Standard RFC 9989 wurde im Mai 2026 veröffentlicht und ersetzt RFC 7489; SPF basiert auf RFC 7208 und DKIM auf RFC 6376. Stand und Faktenprüfung: 21. August 2026.