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 senden. 

Gerade als Sie sich an die neuen DMARC-Richtlinien gewöhnt hatten…
Im Mai 2026 veröffentlichte die IETF einen neuen Satz von DMARC-RFCs, der RFC 7489 ersetzt: RFC 9989 (Kern-DMARC), RFC 9990 (aggregierte Berichte) und RFC 9991 (Fehlerberichte). DMARCbis, zuvor als der Entwurf „nächste Version von DMARC“ bekannt, 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 Verhalten der Absender erwarten. Die aktualisierten DMARC-RFCs ändern diese Erwartungen nicht grundlegend, aber sie klären und formalisieren Praktiken, nach denen viele Absender und ESPs heute bereits arbeiten. 

Für Absender von Mailgun ist dies wichtig zu verstehen, aber es ist kein „Werfen Sie Ihr DNS bis Freitag über den Haufen“-Moment. Die Grundlagen sind dieselben: Authentifizieren Sie Ihre E-Mails, halten Sie Identifikatoren übereinstimmend, überwachen Sie Ihre Berichte und reparieren Sie Streams, die nicht übereinstimmen. 

Der aktualisierte Standard ist sauberer, expliziter und besser darauf abgestimmt, wie großflächige E-Mail-Authentifizierung in der Produktion 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 RFCs 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 RFCs statt einem: RFC 9989 behandelt Richtlinie und Übereinstimmung, RFC 9990 behandelt aggregierte Berichte und RFC 9991 behandelt Fehlerberichte. 

• DNS-Tree-Walk zur Richtlinienfindung: Empfänger können die DNS-Hierarchie nach oben wandern, 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 organisatorischen Domain zu verlassen.

• Tag-Änderungen: Neue Tags wie np (Richtlinie für nicht existierende Subdomains) und psd (Public-Suffix-Domain) werden hinzugefügt; veraltete Tags wie pct, rf und ri werden 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 aus Gründen der Sauberkeit und Lesbarkeit zu entfernen, 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 Teil, den Kunden von Mailgun im Kopf behalten sollten: 

DMARC ist immer noch erfolgreich, 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 (gleiche organisatorische Domain, wie mg.example.com und example.com). 

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

DMARC verlässt sich weiterhin auf „SPF oder DKIM mit Übereinstimmung“, nicht auf „SPF und DKIM und DMARC sind alle unabhängig voneinander erfolgreich“. Ein erfolgreiches DMARC garantiert 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-Control-Panel 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 zur Veröffentlichung auf dieser Domain zur Verfügung, zusammen mit MX- und optionalen Tracking-CNAME-Einträgen. 

• Die Domain muss verifiziert werden, bevor Sie senden 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. 

Sobald das erledigt ist: 

• Mailgun signiert ausgehende E-Mails mit DKIM unter Verwendung Ihrer Absenderdomain im d=-Wert, beispielsweise 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 zu senden, und nicht nur MAIL-FROMs auf einer Domain im Besitz des Anbieters. 

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 erreichbar. 

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. Inventory Mailgun domains and usage 
   • 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. Verify aligned SPF and DKIM, not just “pass” 
   • 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. Clean up your DMARC records 
   • 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. Treat aggregate reports as an early‑warning system 
   • 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. Keep DMARC and DKIM2 mentally separate 
   • 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 weiterhin auf SPF und DKIM, genau wie zuvor. In der IETF wird weiterhin darüber diskutiert, ob DKIM2 irgendwann eine Rolle bei zukünftigen DMARC-artigen Auswertungen spielen könnte, aber diese Arbeit bleibt vorerst separat und ungeklärt.

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

Author: Alison Gootee