Mailgun: DMARCbis ist tot

Mailgun: DMARCbis ist tot. Lang lebe DMARC. 

Der aktualisierte DMARC-Standard ist da. Hier erfahren Sie, was sich geändert hat, was nicht, und was es bedeutet, wenn Sie über Mailgun versenden. 

Gerade als Sie sich an die neuen DMARC-Richtlinien gewöhnt hatten…
Im Mai 2026 veröffentlichte die IETF einen neuen Satz von DMARC-RFC, der RFC 7489 ersetzt: RFC 9989 (Kern-DMARC), RFC 9990 (aggregierte Berichte) und RFC 9991 (Fehlerberichte).  DMARCbis, das bisher als Entwurf der „nächsten Version von DMARC“ bezeichnet wurde, ist nun der veröffentlichte DMARC-Standard. 

Warum ist das wichtig?
Diese Änderung ist wichtig, da E-Mail-Anbieter zunehmend authentifizierte, übereinstimmende E-Mails als grundlegendes Absenderverhalten erwarten. Die aktualisierten DMARC-RFC ändern diese Erwartungen nicht grundlegend, aber sie klären und formalisieren Praktiken, nach denen viele Absender und E-Mail-Anbieter heute bereits arbeiten. 

Für Absender, die mit Mailgun versenden, ist es zwar wichtig, dies zu verstehen, aber es bedeutet nicht, dass Sie „Ihr DNS bis Freitag rauswerfen müssen“. Die Grundlagen sind dieselben: Authentifizieren Sie Ihre E-Mails, sorgen Sie dafür, dass Ihre Identifikatoren übereinstimmen, überwachen Sie Ihre Berichte und reparieren Sie Streams, die nicht übereinstimmen. 

Der aktualisierte Standard ist sauberer, expliziter und besser darauf abgestimmt, wie E-Mail-Authentifizierung im großen Maßstab in einer Produktionsumgebung betrieben wird. Für die meisten Absender, die bereits authentifizierte Domains und übereinstimmende Identifikatoren korrekt verwenden, ist diese RFC-Aktualisierung eher evolutionär als disruptiv.

Die aktualisierten RFC restrukturieren, klären und modernisieren hauptsächlich die DMARC-Dokumentation; sie ändern das zentrale Evaluierungsmodell von DMARC –„übereinstimmendes SPF oder übereinstimmendes DKIM“ – nicht grundlegend.

• Drei RFC statt einem: RFC 9989 behandelt die Richtlinie und Übereinstimmung, RFC 9990 behandelt aggregierte Berichte und RFC 9991 behandelt Fehlerberichte. 

• DNS-Tree-Walk zur Richtlinienfindung:  Empfänger können in der DNS-Hierarchie nach oben gehen, anstatt sich auf eine statische Liste öffentlicher Suffixe (Public-Suffix-Liste) zu verlassen. In der Praxis betrifft dies meist sehr große oder komplexe Domain-Strukturen (wie einige .edu-, .gov- oder Public-Suffix-Umgebungen) und erfordert Implementierungsänderungen auf der Empfängerseite. Die meisten Absender sollten weiterhin explizite DMARC-Einträge auf den Domains veröffentlichen, die sie aktiv für E-Mails nutzen, anstatt sich auf das Fallback-Verhalten der Domain der Organisation zu verlassen.

• Tag-Änderungen: Neue Tags wie np (Richtlinie für nicht existierende Subdomains) und psd (Public-Suffix-Domain) wurden hinzugefügt; veraltete Tags wie pct rf und ri wurden entfernt; ein neues t -Tag beschreibt das Testverhalten besser. 

Wenn Sie DMARC-Einträge verwalten, können Sie sich irgendwann entscheiden, ausrangierte Tags wie pct, rf und ri zu entfernen, um die Sauberkeit und Lesbarkeit zu verbessern, obwohl von Empfängern erwartet wird, dass sie unbekannte oder veraltete Tags ignorieren. Die meisten Absender werden das neue psd-Tag wahrscheinlich nicht benötigen, während np für Organisationen relevant sein kann, die große oder komplexe Subdomain-Strukturen verwalten.

Der Aspekt, den Kunden von Mailgun weiterhin beachten sollten: 

DMARC lässt den Versand weiterhin zu, wenn die sichtbare From-Domain  entweder mit SPF oder mit DKIM übereinstimmt, und nicht nur, wenn beide übereinstimmen. 

DMARC prüft weiterhin, ob die Autorendomain (sichtbares From) mit einem der folgenden authentifizierten Identifikatoren übereinstimmt: 

• SPF (MAIL FROM / Return-Path-Domain) 

• DKIM (d= Signaturdomain) 

Die Übereinstimmung bleibt strikt (exakte Übereinstimmung) oder entspannt (die gleiche organisatorische Domain, wie etwa mg.example.com und example.com). 

Es lohnt sich auch, die Domain-Übereinstimmung von der IP-Reputation zu trennen. Gemeinsam genutzte IP-Adressen wirken sich im Vergleich zu dedizierten IP-Adressen auf das Reputationsmanagement, das Aufwärmen und die Sichtbarkeit bei der Fehlerbehebung aus, ändern jedoch die Funktionsweise der DMARC-Übereinstimmung nicht grundlegend. Unabhängig davon, ob Sie über eine geteilte oder dedizierte Infrastruktur senden, prüft DMARC weiterhin, ob Ihre sichtbare From-Domain mit den folgenden übereinstimmt: authentifizierte SPF- oder DKIM-Identifikatoren. 

DMARC basiert auch weiterhin auf „SPF oder DKIM mit Übereinstimmung“, nicht auf „SPF und DKIM und DMARC sind alle unabhängig voneinander erfolgreich“. Wenn DMARC erfolgreich ist, garantiert dies immer noch keine Posteingangsplatzierung; es belegt die autorisierte Nutzung der Domain, während Reputation, Engagement und Inhalt weiterhin entscheiden, wo die Nachricht landet. 

Hier trifft die Spezifikation auf das, was Sie im Mailgun-Dashboard tun. 

Wie Mailgun Ihre authentifizierten Domains verwendet 

Wenn Sie eine Absenderdomain (oft eine Subdomain wie mg.example.com) in Mailgun hinzufügen: 

• Mailgun stellt Ihnen SPF- und DKIM-TXT-Einträge sowie MX- und optionale Tracking-CNAME-Einträge zur Veröffentlichung auf dieser Domain zur Verfügung. 

• Die Domain muss verifiziert werden, bevor Sie versenden können. Der standardmäßige Ablauf für authentifizierte Domains von Mailgun erwartet einen gültigen DKIM-Schlüssel im DNS, bevor die Domain als vollständig authentifiziert behandelt wird. 

Wenn das erledigt ist, geschieht Folgendes: 

• Mailgun signiert ausgehende E-Mails mit DKIM und verwendet dazu Ihre Absenderdomain im d=-Wert, zum Beispiel d=mg.example.com. 

• Der MAIL FROM / Return-Path basiert typischerweise auf Ihrer Absenderdomain bei Mailgun 

Mailgun ist in der Lage, standardmäßig vollständig SPF-konforme E-Mails über Ihre authentifizierten Subdomains und nicht nur MAIL-FROMs auf einer im Besitz des Anbieters befindlichen Domain zu senden. 

Mit anderen Worten: Im standardmäßigen Ablauf für authentifizierte Domains authentifiziert Mailgun E-Mails auf Ihren Domains, sodass die Übereinstimmung auf Ihrer Seite liegt. 

Wenn Sie das herkömmliche Mailgun-Muster mit dedizierten Absender-Subdomains, von Mailgun bereitgestelltem SPF und DKIM auf diesen Domains und einer passenden From-Domain verwenden, sind sowohl SPF-Übereinstimmung als auch DKIM-Übereinstimmung ohne spezielle Workarounds möglich. 

Automatic Sender Security (ASS) ändert an dieser Tatsache nichts: Es automatisiert die Schlüsselerstellung und -rotation für die Selektoren Ihrer Domain, aber die Signatur verwendet weiterhin Ihre Domain in d=. 

Sie können Ihre aktuelle Architektur beibehalten. Aber Sie müssen sicherstellen, dass sie dem entspricht, was DMARC nun klarer beschreibt. 

1. Bestandsaufnahme der Mailgun-Domains und deren Nutzung 
   • Listen Sie alle von Mailgun verifizierten Domains auf und welche Streams (Transaktions-, Marketing-, App-Benachrichtigungen) diese jeweils nutzen. 
   • Mustern Sie DMARC auf Domains aus oder verschärfen Sie es, wenn diese nicht mehr aktiv genutzt werden, insbesondere wenn sie noch freizügige Einträge haben. 
2. Überprüfen Sie, dass SPF und DKIM übereinstimmen, und nicht nur „erfolgreich“ sind 
   • Bestätigen Sie, dass SPF auf jeder Absenderdomain von Mailgun korrekt veröffentlicht ist und dass diese Domains eine organisatorische Domain mit dem sichtbaren From teilen. 
   • Verwenden Sie einen Kopfzeilen-Analysator, um zu bestätigen, dass d= in der DKIM-Signatur mit Ihrer Absenderdomain von Mailgun (oder einer Subdomain Ihrer Organisation) übereinstimmt und nicht mit einem nicht verwandten Hostnamen. 
3. Säubern Sie Ihre DMARC-Einträge 
   • Entfernen Sie die Tags pct, rf und ri , die in der neuen Spezifikation wegfallen. 
   • Prüfen Sie, ob np und psd für Ihre Domain-Struktur relevant sind. 
   • Bestätigen Sie, dass Ihr sp=-Verhalten für Subdomains beabsichtigt ist. 

4. Behandeln Sie aggregierte Berichte als Frühwarnsystem 
   • Verwenden Sie aggregierte DMARC-Berichte, um neue Mailgun-Domains, vergessene alte Streams oder nicht übereinstimmende Drittanbieter-Absender zu erkennen, die Ihre Domain nutzen. 
   • Wenn Sie bei p=none sind, behandeln Sie dies als aktive Überwachung und nicht als „Wir schauen irgendwann mal nach“. 

5. Trennen Sie DMARC und DKIM2 gedanklich 
   • Sie werden mehr über DKIM2 hören, aber das ist eine separate Protokollinitiative, die sich auf Signaturmodelle und Replay-Schutzmaßnahmen konzentriert. 
   • Die Aktualisierung der DMARC-RFCs macht DKIM2 nicht zu einer Anforderung, und die heutigen DMARC-Auswertungen verlassen sich genau wie zuvor weiterhin auf SPF und DKIM. In der IETF wird weiterhin darüber diskutiert, ob DKIM2 irgendwann eine Rolle bei zukünftigen DMARC-ähnlichen Auswertungen spielen könnte, aber diese Arbeit bleibt vorerst separat und ist noch geklärt.

DMARCbis ist tot. Lang lebe DMARC. Für die meisten Kunden von Mailgun, die authentifizierte Domains und übereinstimmende Identifikatoren bereits korrekt verwenden, sollten sich die neuen RFCs eher wie eine Klarstellung bestehender Best Practices anfühlen als eine große operative Umstellung. 

Autor: Alison Gootee