Mailgun: SPF, DKIM und DMARC-Ausrichtung per Subdomain

Von Thomas · virtueller CISO · 06. September 2026

Mailgun richtet sich zuerst an technische Teams: eine Versand-API, ein SMTP-Relais, Ereignis-Webhooks, alles für transaktionale Post und große Anwendungsvolumina gebaut. Diese Entwicklerausrichtung zeigt sich in der Art, wie die Plattform die Authentifizierung handhabt — expliziter, stärker segmentiert als eine Office-Suite, und auf einem Prinzip gegründet, das die Plattform von Beginn der Einrichtung an hervorhebt: Der Versand läuft über eine eigene Subdomain, getrennt von der Hauptdomain.

Diese Wahl ist nicht kosmetisch. Sie bestimmt sowohl die Versandreputation als auch die Art, wie DMARC greift. Eine zu Mailgun hinzugefügte Domain ohne gesetzte Einträge versendet unter der Identität der Plattform: Die DKIM-Signatur und der Umschlag haben keinerlei Bezug zur Domain im From-Header, und eine p=reject-Richtlinie weist diesen an sich legitimen Verkehr ab. Solange SPF und DKIM nicht veröffentlicht und dann verifiziert sind, richtet sich nichts aus.

Dieser Leitfaden behandelt die Logik der Versand-Subdomain, die zu setzenden SPF- und DKIM-Einträge, die daraus folgende DMARC-Ausrichtung im entspannten Modus, die Frage der Region — US oder EU, mit ihren Folgen für die Datenresidenz — sowie die häufigsten Konfigurationsfehler und den abschließenden Gegenbeweis über die RUA-Berichte.

Die Versand-Subdomain: die Reputation isolieren

Mailgun empfiehlt, den Versand auf einer Subdomain zu konfigurieren — etwa mg.beispiel.de — statt auf der Root-Domain. Der Grund liegt in der Reputation. Transaktionale Post mit hohem Volumen, Kampagnen und Anwendungsbenachrichtigungen haben ein ganz anderes Versandprofil als die menschliche Post der Hauptdomain; ihre Isolierung auf einer Subdomain verhindert, dass ein Zustellvorfall auf der Kampagnenseite die Reputation der Root-Domain beschädigt, aus der die Post der Menschen ausgeht.

Diese Trennung hat eine unmittelbare Folge für die Authentifizierung: Die SPF- und DKIM-Einträge werden in der Zone der Subdomain gesetzt, nicht der Root-Domain. Die DKIM-Signatur trägt d=mg.beispiel.de, der Umschlag liegt auf der Subdomain — und im entspannten Modus richten sich diese Elemente an beispiel.de aus. Die Root-Domain behält ihr eigenes SPF und ihre eigene Konfiguration für die menschliche Post, ohne Interferenz.

Ob der Versand über die HTTP-API oder das SMTP-Relais läuft, ändert an dieser Mechanik nichts: In beiden Fällen bringt Mailgun dieselbe DKIM-Signatur an und verwendet denselben Umschlag. Die Wahl zwischen API und SMTP ist eine Frage der Anwendungsintegration, niemals der Authentifizierung — ein nützlicher Punkt, wenn dieselbe Versanddomain mehrere Anwendungen über verschiedene Wege bedient.

Die Einträge: SPF, DKIM, MX und Nachverfolgung

Der Assistent von Mailgun erzeugt einen Satz von Einträgen, die in die Zone der Versand-Subdomain zu setzen sind:

mg.beispiel.de.            TXT    "v=spf1 include:mailgun.org ~all"
k1._domainkey.mg.beispiel.de.  TXT    "k=rsa; p=MIIBIjANBgkq…"
mg.beispiel.de.            MX     10 mxa.mailgun.org.
mg.beispiel.de.            MX     10 mxb.mailgun.org.
email.mg.beispiel.de.     CNAME  mailgun.org.

Der SPF-Eintrag autorisiert die Server von Mailgun, für die Subdomain zu senden. Der DKIM-TXT veröffentlicht den öffentlichen Schlüssel unter einem von der Plattform gelieferten Selektor (oft k1): Die von Mailgun angebrachte Signatur ist über diesen Selektor überprüfbar. Die beiden MX-Einträge lassen Mailgun die an die Subdomain gerichteten Bounces und Antworten empfangen; sie sind empfohlen, sobald die Zustellnachverfolgung zählt. Der email.-CNAME dient schließlich der Nachverfolgung von Öffnungen und Klicks — ohne Wirkung auf die Authentifizierung, aber oft im selben Zug gesetzt.

Zur Schlüssellänge bietet Mailgun 1024 und 2048 Bit; 2048 ist die zu behaltende Länge, da mehrere Mail-Betreiber 1024 inzwischen als schwach einstufen. Die Erneuerung der Signaturschlüssel erfolgt durch Veröffentlichung eines neuen Selektors vor dem Entfernen des alten, ohne Ausfallfenster.

Größere Aufbauten betreiben oft mehr als eine Versand-Subdomain — etwa mg.beispiel.de für Produktpost und news.beispiel.de für Kampagnen —, jede mit eigenen SPF- und DKIM-Einträgen und eigener Reputation. DMARC behandelt sie einheitlich: Jede richtet sich im entspannten Modus an beispiel.de aus, und jede erscheint als eigene Quelle in den Berichten. So wird die Diagnose Strom für Strom möglich, statt in einem einzigen undurchsichtigen Block „Mailgun-Verkehr" zu verschwimmen — ein Vorteil, sobald mehrere Anwendungen denselben Anbieter nutzen.

Die DMARC-Ausrichtung: der entspannte Modus in Aktion

DMARC validiert eine Nachricht nur, wenn SPF oder DKIM besteht und sich an der From-Domain ausrichtet. Die Subdomain-Anordnung von Mailgun stützt sich auf die entspannte Ausrichtung, den Standardmodus von DMARC.

Im entspannten Modus richtet sich eine Subdomain an ihrer Organisationsdomain aus: mg.beispiel.de richtet sich an beispiel.de aus. So besteht eine Nachricht mit einem From auf @beispiel.de, einer DKIM-Signatur d=mg.beispiel.de und einem Umschlag auf der Subdomain DMARC auf beiden Mechanismen. Unter DMARCbis wird die Organisationsdomain über den DNS Tree Walk bestimmt statt über die alte Public Suffix List, das Ergebnis bleibt jedoch gleich: Subdomain und Root-Domain gelten als derselben Organisation zugehörig.

Ein Detail verdient Erwähnung zum From-Header. Zwei Anordnungen bestehen nebeneinander: ein From auf @beispiel.de — das häufigste, die Markenidentität —, das sich auf die entspannte Ausrichtung der Subdomain stützt, oder ein From direkt auf @mg.beispiel.de, das dann im strikten wie im entspannten Modus ausrichtet, aber die technische Subdomain den Empfängern zeigt. Das erste ist für die Lesbarkeit der angezeigten Adresse fast immer vorzuziehen; das zweite begegnet nur bei rein maschinellen Strömen, bei denen das Erscheinungsbild der Adresse kaum zählt.

Der einzige Fall, in dem diese Anordnung scheitert, ist die strikte Ausrichtung, die eine exakte Domain-Übereinstimmung verlangt. Eine DMARC-Richtlinie, die adkim=s oder aspf=s erzwingt, bräche die Ausrichtung eines Versands über mg.beispiel.de unter einem From @beispiel.de. Ohne besonderen Bedarf bleibt der entspannte Modus die richtige Wahl — er macht die Subdomain-Anordnung überhaupt erst tragfähig. Die kommentierten Beispiele, Tag für Tag zeigen, wo diese Ausrichtungs-Tags gesetzt werden.

Region US oder EU: die Datenresidenz

Mailgun betreibt zwei getrennte Regionen, eine amerikanische und eine europäische, gewählt bei der Erstellung der Versanddomain. Die Wahl hat zwei Wirkungen. Die erste ist technisch: Die API und der SMTP-Einstiegspunkt unterscheiden sich, und eine in einer Region erstellte Domain muss über den Endpunkt dieser Region gesteuert werden — eine häufige Verwechslung, wenn ein Alt-Skript für eine europäische Domain noch auf den US-Endpunkt zeigt.

Die zweite Wirkung betrifft die Datenresidenz. Für eine Organisation mit Souveränitätsanforderungen hält die europäische Region die Verarbeitung der E-Mails und der zugehörigen Protokolle innerhalb der EU. Das ist weniger eine Frage der Authentifizierung als der Konformität, wird aber im selben Moment entschieden — bei der Erstellung der Domain — und lässt sich nachträglich schlecht korrigieren: Ein Regionswechsel bedeutet, die Versanddomain neu zu erstellen und alle Einträge neu zu setzen. Besser gleich zu Beginn geklärt.

Geteilte IP, dedizierte IP und Hochlauf

Mailgun bietet zwei Regime für Absendeadressen. Standardmäßig laufen die Sendungen über einen geteilten IP-Pool: Die Reputation wird dort über Kunden hinweg geteilt, was für moderate Volumina passt und ohne Aufwärmen startet. Ab einem gewissen regelmäßigen Volumen wird eine dedizierte IP sinnvoll — die Reputation gehört dann allein der Organisation, muss aber aufgebaut werden: Eine frische IP ist zu wärmen, also über mehrere Tage schrittweise im Volumen hochzufahren, sonst behandeln empfangende Anbieter sie als verdächtig.

Diese Wahl hat keine Wirkung auf die DMARC-Ausrichtung — DKIM und SPF richten sich unabhängig von der sendenden IP gleich aus —, wiegt aber auf der Zustellbarkeit und damit auf dem Lesen der Berichte. Eine frische dedizierte IP kann während des Aufwärmens einen Teil ihrer Nachrichten verzögert sehen, ohne dass auf der Authentifizierungsseite etwas nicht stimmt. Ein Reputationsproblem von einem Ausrichtungsproblem zu unterscheiden, ist genau das, was die aggregierten Berichte erlauben: Das erste liest sich in den Zustellraten, das zweite in den Spalten SPF und DKIM.

Häufige Konfigurationsfehler

Mehrere Fallen tauchen im Korpus der Berichte regelmäßig auf, die der kostenlose DMARC-Analyzer täglich verarbeitet.

Die Einträge auf der Root-Domain setzen. Mailgun auf beispiel.de statt mg.beispiel.de zu konfigurieren, verliert die Reputationsisolierung und vermischt das SPF der Plattform mit dem der menschlichen Post — ein Geflecht, das jede spätere Diagnose erschwert.

Die Regionen verwechseln. Eine auf der EU-Seite erstellte, aber über den US-Endpunkt gesteuerte Domain authentifiziert sich nicht wie erwartet, und die Berichte zeigen es.

Vergessen, die Domain in der Konsole zu verifizieren. Wie bei anderen Plattformen genügt das Veröffentlichen der Einträge nicht: Mailgun muss ihre Propagierung feststellen und die Domain als verifiziert markieren, bevor die Signaturen tatsächlich angebracht werden.

Die Richtlinie zu früh verschärfen. Der Wechsel zu p=reject — oder schlimmer zur strikten Ausrichtung —, bevor die Berichte bestätigen, dass sich der gesamte legitime Verkehr ausrichtet, bedeutet, die Abweisung der eigenen Post zu riskieren.

Der Gegenbeweis: die RUA-Berichte

Der einzige Beleg dafür, dass eine Konfiguration hält, ist nicht die Mailgun-Konsole, sondern das, was die Empfänger melden. Sobald ein _dmarc-Eintrag mit einer rua=-Adresse veröffentlicht ist, treffen die aggregierten Berichte binnen weniger Tage ein und schlüsseln Quelle für Quelle auf, was sich ausrichtet und was scheitert. Das Lesen der aggregierten DMARC-Berichte bestätigt, ob der Mailgun-Verkehr der Domain korrekt zugeordnet wird: Die der Versand-Subdomain entsprechende Quelle sollte dort mit ausgerichtetem DKIM und SPF erscheinen.

Eine einfache Kadenz genügt: eine erste Durchsicht wenige Tage nach der Veröffentlichung des _dmarc-Eintrags, sobald mehrere Empfänger gemeldet haben, danach ein wöchentlicher Blick, solange die Richtlinie bei p=none bleibt. Der Mailgun-Verkehr ist an seinen stabilen Adressbereichen schnell zu erkennen; jede neue oder nicht ausgerichtete Quelle fällt sofort auf — eine vergessene zweite Versanddomain, eine falsch verbundene Region, ein nie verifizierter DKIM-Selektor. Sobald die Ausrichtung über mehrere Tage und über alle Ströme bestätigt ist, erfolgt der Wechsel zu p=reject ohne Risiko. Der Online-Analyzer setzt diesen Zustand aus den veröffentlichten Einträgen und den empfangenen Berichten zusammen und verortet die Domain auf dem Weg, der zu p=reject führt.