DMARC ist 2026 neu standardisiert – was Website-Betreiber jetzt wirklich prüfen sollten

Im Mai 2026 wurde DMARC neu standardisiert: RFC 9989 hat RFC 7489 und RFC 9091 abgelöst. Gleichzeitig wurden Aggregate Reports und Failure Reports in RFC 9990 und RFC 9991 ausgelagert.

Für Website-Betreiber klingt das zunächst nach Mailserver-Nischenwissen. Praktisch stellt das Update aber eine sehr nützliche Frage:

Wissen Sie vollständig, welche Systeme im Namen Ihrer Domain E-Mails versenden – und ob deren reale Nachrichten korrekt authentifizieren?

Kontaktformular, Shop, Newsletter, CRM, WordPress-Plugin, Buchungssystem, Passwort-Reset und Support-Tool können alle dieselbe sichtbare Absenderdomain verwenden. DMARC ist deshalb keine DNS-Dekoration, sondern Teil der Betriebsqualität einer Website.

Was sich mit RFC 9989 geändert hat – und was nicht

Die wichtigste Entwarnung zuerst: Es gibt kein DMARC2. RFC 9989 verlangt weiterhin v=DMARC1.

Neu beziehungsweise relevant ist vor allem:

• Der frühere pct-Tag wurde aus der aktuellen Spezifikation entfernt.
• RFC 9989 führt t als Testmodus für eine Policy ein.
• Die Ermittlung der organisatorischen Domain ist über einen DNS Tree Walk präziser definiert.
• Aggregate Reporting ist jetzt in RFC 9990, Failure Reporting in RFC 9991 beschrieben.

Das bedeutet nicht, dass jede bestehende Domain sofort einen neuen Record braucht. Es bedeutet aber, dass alte DMARC-Anleitungen überprüft werden sollten.

Red Flag: Ihr Rollout-Plan hängt noch an pct=10

Ältere Guides empfehlen häufig, p=reject schrittweise mit pct=10, pct=25 oder pct=50 auszurollen.

RFC 9989 hat pct bewusst entfernt. Die Begründung ist operativ interessant: Prozentwerte wurden von Empfängern nicht zuverlässig einheitlich umgesetzt. Die aktuelle Spezifikation führt stattdessen t=y als Testsignal ein. Das ist jedoch kein neuer Prozentregler.

Wer heute noch auf pct= als verlässliche Sicherheitsleine setzt, sollte DNS, Dokumentation und Infrastructure-as-Code prüfen. Ein alter Wert kann weiterhin in Konfigurationen stehen, ohne dass er unter der aktuellen Spezifikation die erwartete portable Wirkung hat.

Ein DMARC-Record beweist noch keinen DMARC-Pass

Der häufigste Denkfehler lautet: „DMARC ist eingerichtet, der TXT-Record existiert.“

DMARC prüft aber Alignment. Mindestens ein authentifizierter Identifier aus SPF oder DKIM muss zur Domain im sichtbaren From: passen.

Genau hier brechen Website-Setups gern auseinander: Die Website zeigt kontakt@example.de als Absender, der Versanddienst authentifiziert aber über eine andere Provider-Domain. SPF oder DKIM können technisch erfolgreich sein, ohne dass die Nachricht für die sichtbare Absenderdomain DMARC besteht.

Deshalb sollte ein Audit nicht nur DNS prüfen, sondern echte Testnachrichten und deren Header.

Der klassische Kontaktformular-Fehler

Ein Besucher trägt kunde@gmail.com ein. Das Formular verschickt anschließend eine Nachricht mit From: kunde@gmail.com über den Server der Website.

Damit behauptet die Website technisch, im Namen von Gmail zu senden.

Robuster ist typischerweise:

• From: verwendet eine Adresse auf einer eigenen, authentifizierten Domain,
• Reply-To: enthält die Adresse des Besuchers,
• der Versand läuft über einen bewusst konfigurierten SMTP- oder Transaktionsmail-Dienst.

So bleibt die Antwortfunktion erhalten, ohne eine fremde Domain als Absender zu imitieren.

SPF: Gibt es ein Inventar aller Sender?

SPF beschreibt, welche Systeme eine Domain für den SMTP-Absender verwenden dürfen. RFC 7208 erlaubt nicht mehrere unabhängige SPF-Records für denselben Namen.

Das praktische Risiko ist Konfigurationsdrift. Ein Unternehmen beginnt mit einem Mailprovider und ergänzt später Newsletter, CRM, Shop, Helpdesk oder Website-Plugin. Irgendwann kennt niemand mehr alle Versandquellen.

Prüfen Sie deshalb:

• Welche Systeme senden aktuell?
• Welche Domains und Subdomains verwenden sie?
• Sind ehemalige Anbieter noch im SPF enthalten?
• Fehlt ein aktiver Anbieter?
• Gibt es versehentlich zwei v=spf1-Records?
• Wer ist für DNS-Änderungen verantwortlich?

DKIM: Signiert der richtige Dienst mit der richtigen Domain?

DKIM versieht Nachrichten mit einer kryptografischen Signatur. Für DMARC reicht aber nicht die Aussage „DKIM ist gültig“. Relevant ist auch die Domain im d=-Wert und deren Alignment mit dem sichtbaren From:.

Bei mehreren Versanddiensten sollten Provider, DKIM-Selector, Signing-Domain und Ownership dokumentiert sein. RFC 6376 weist außerdem auf einen sauberen Key-Lifecycle hin: Bei Rotation sollte der alte öffentliche Schlüssel nicht vorschnell entfernt werden.

p=none ist Monitoring – wenn jemand hinschaut

RFC 9989 beschreibt p=none zusammen mit Aggregate Reporting als Monitoring Mode. Das ist sinnvoll, weil Reports legitime, aber falsch konfigurierte Versandquellen sichtbar machen können.

Ein rua=-Postfach voller ungelesener XML-Dateien ist allerdings kein Monitoring.

Ein belastbarer Prozess beantwortet:

• Kommen Reports an?
• Werden sie maschinell ausgewertet oder regelmäßig geprüft?
• Können neue Versandquellen erkannt werden?
• Ist klar, welche Quellen legitim sind?
• Werden Altanbieter aus DNS und Dokumentation entfernt?

RFC 9990 definiert das aktuelle Aggregate Reporting. RFC 9991 behandelt Failure Reporting separat.

Gmail und Yahoo machen Authentifizierung zur Zustellfrage

Die aktuellen Gmail-Richtlinien verlangen für alle Absender an persönliche Gmail-Konten mindestens SPF oder DKIM, TLS sowie weitere Infrastruktur- und Formatvorgaben. Für Absender mit mehr als 5.000 Nachrichten pro Tag an Gmail gelten zusätzliche Anforderungen: SPF und DKIM, DMARC, Alignment der sichtbaren From-Domain und One-Click-Unsubscribe für Marketing- und abonnierte Nachrichten.

Yahoo verlangt ebenfalls Authentifizierung für alle Sender und verschärfte Anforderungen für Bulk Sender. Die Yahoo-FAQ stellt klar, dass One-Click-Unsubscribe nicht pauschal für transaktionale Nachrichten wie Bestellbestätigungen oder Passwort-Resets verlangt wird.

Für Website-Teams ist die Konsequenz simpel:

Nicht jede E-Mail ist Marketing. Aber jeder Versandstrom sollte bewusst identifiziert, authentifiziert und überwacht werden.

Acht Fragen für den Website-Mail-Check

1. Welche Anwendungen, Plugins und SaaS-Dienste senden im Namen unserer Domains?
2. Welche sichtbaren From:-Domains verwenden sie?
3. Bestehen reale Testnachrichten SPF, DKIM und DMARC?
4. Stimmen From:, SPF-Envelope-Domain und DKIM-d= für DMARC-Alignment zusammen?
5. Gibt es alte SPF-Includes, DKIM-Selector oder pct=-Anweisungen?
6. Verwenden Kontaktformulare Besucheradressen korrekt als Reply-To: statt als fremdes From:?
7. Sind Marketing- und transaktionale Versandströme getrennt und dokumentiert?
8. Können wir Bounce-, Deferred- und Provider-Events für kritische Mails nachvollziehen?

Der letzte Punkt ist wichtig: Ein grünes „Nachricht wurde gesendet“ im Frontend beweist nicht, dass sie im Postfach angekommen ist. Bei Passwort-Reset, Buchung oder Bestätigung ist Zustellbarkeit Teil des Produkts.

Was Website-Pflichtencheck prüfen würde

Je nach Setup umfasst ein technischer Check unter anderem:

• öffentliche SPF-, DKIM- und DMARC-Konfiguration,
• Versanddomains und Subdomains,
• kontrollierte Testnachrichten und Authentication-Results,
• From:-/Reply-To:-Logik von Formularen,
• Alignment-Lücken,
• veraltete DNS-Einträge und alte Provider,
• tatsächliche Nutzung von DMARC-Reports,
• Trennung von Marketing- und Transaktionsmail,
• One-Click-Unsubscribe dort, wo der konkrete Versandstrom und Provider es verlangen,
• Bounce- und Fehlerbeobachtung für kritische Website-Mails,
• dokumentierte Ownership für spätere Providerwechsel.

Das Ergebnis sollte nicht nur „DMARC vorhanden: ja“ heißen. Sinnvoll ist eine nachvollziehbare Versandlandkarte mit konkreten Lücken.

RFC 9989 ist ein guter Anlass für diesen Check: pct ist kein aktueller Rollout-Mechanismus mehr, v=DMARC1 bleibt bestehen und Reporting wurde sauber getrennt.

Die größere operative Wahrheit ist aber zeitlos:

Eine Website kann perfekt funktionieren und trotzdem ihre wichtigsten E-Mails unzuverlässig versenden.

Wenn Kontaktanfragen, Logins, Bestellungen oder Buchungen von E-Mail abhängen, gehört die Versandkette zur Website-Infrastruktur – und sollte auch so geprüft werden.