E-Mails versenden, die auch ankommen

Mailgun verbinden, die Absenderadresse richtig setzen und wissen, welche Zustellsignale wirklich etwas bedeuten.

Mailgun ist der einzige Versandweg dieses Systems — kein SMTP, kein zweiter Anbieter. "E-Mail einrichten" und "Mailgun verbinden" sind dieselbe Aufgabe.

Zwei Entscheidungen vorab

Deine Versanddomain — die Domain, die du bei Mailgun registrierst und für die du die DNS-Einträge veröffentlichst. Entweder deine Hauptdomain oder eine eigene Subdomain wie mg.deinedomain.de.

Deine Absenderadresse — der From-Header ausgehender Mail. Sie muss auf der Versanddomain liegen oder auf einer über- oder untergeordneten Domain davon; eine fremde Domain, etwa eine Gmail-Adresse, ist ein DMARC-Ausrichtungsfehler, und das Speichern wird abgelehnt. Am einfachsten legst du sie genau auf die Versanddomain: [email protected] bei Versanddomain mg.deinedomain.de. Eine Adresse auf der übergeordneten Domain funktioniert auch — mit einer Einschränkung, siehe Schritt 5.

Die Reihenfolge zählt: Der Mailgun-Dialog lässt sich nicht speichern, solange keine Absenderadresse existiert.

Schritt 1 — Absenderidentität setzen

Admin → General Settings → Tab Branding. ("General Settings" steht in der Seitenleiste unter "Settings", Branding ist ein Tab auf dieser Seite.) Vier Felder bestimmen, wie deine Mail adressiert wird:

Email Sender Name — der Absendername. Ändere diesen, wenn der Absender anders erscheinen soll; änderst du stattdessen Business Name, benennst du dein ganzes Unternehmen um.
Email Sender Address — die Absenderadresse, Platzhalter [email protected]. Trag sie ein.
Contact Email — deine öffentliche Kontaktadresse. Wird nur als Absenderadresse benutzt, wenn Email Sender Address leer ist.
Business Name — der Absendername nur dann, wenn Email Sender Name leer ist.

Die Felder speichern, sobald du herausklickst; einen Speichern-Button gibt es nicht.

Email Sender Address leer zu lassen ist der übliche Fehler: Ersatz ist dann Contact Email, meist auf deiner Hauptdomain statt auf der Versanddomain — und genau diese Abweichung lässt deine Absenderadresse später überschreiben. Beide Werte werden bei jedem Versand frisch gelesen; was hier steht, geht auch so raus.

Schritt 2 — Domain bei Mailgun einrichten

Konto anlegen, Versanddomain hinzufügen, alle von Mailgun aufgelisteten DNS-Einträge veröffentlichen — SPF, DKIM, Tracking-CNAME — und warten, bis Mailgun die Domain als verifiziert führt. Merk dir, ob das Konto in der Region US oder EU liegt.

Schritt 3 — Mailgun verbinden

Admin → Integrations → Tab Email → Mailgun. Vier Felder: API Key (verschlüsselt gespeichert, wird nie zurückgezeigt), Region, Sending Domain und Webhook Signing Key — den versucht die Anwendung beim Speichern selbst von Mailgun zu holen; klappt das nicht, kopierst du ihn aus Mailgun → API Security. From Email und From Name stehen hier nur lesend, mit Link zurück nach Branding.

Drei verschiedene Dinge verhindern das Speichern:

Keine Absenderadresse — Save bleibt ausgegraut, darunter ein gelber Hinweis: "Contact Email must be configured in Branding Settings to send emails".
Absender auf der falschen Domain — ein rotes Feld nennt beide Domains, gespeichert wird nicht.
Demo-Modus — eine Installation mit eingeschaltetem DEMO_MODE lehnt Änderungen an Zugangsdaten ab und meldet trotzdem Erfolg. Eine normale Installation setzt das nie.

Ein erfolgreiches Speichern registriert automatisch acht Webhooks unter deine-seite/api/webhooks/mailgun: accepted, delivered, opened, clicked, permanent failure, temporary failure, complained, unsubscribed. Sie speisen jede Zustellstatistik im Produkt.

Den Signing Key nicht überspringen

Ohne hinterlegten Signing Key nimmt der Webhook-Endpunkt Ereignisse ohne Signaturprüfung an — er schreibt eine Warnung ins Log und verarbeitet sie trotzdem. Wer die URL findet, kann Zustell-, Beschwerde- und Abmelde-Ereignisse fälschen, und Abmelde-Ereignisse verändern Kontaktdatensätze. Trag ihn ein und prüfe, ob in der Webhook-Karte "Signature verification: Enabled" steht.

Schritt 4 — Prüfen, ob wirklich verbunden ist

Nach dem Speichern erscheint eine Karte Email Tracking Webhooks. Sie fragt Mailgun jetzt, statt dem zu vertrauen, was beim Einrichten gespeichert wurde — eine frühere Fassung zeigte ein grünes "Configured", während Mailgun überhaupt keine Webhooks hielt und jede Nachricht auf QUEUED stehen blieb. Drei Dinge lesen.

Das Badge, unterlegt mit Live at Mailgun: n/8 events. Active heißt: alle acht Ereignistypen sind aktiv und zeigen hierher. Missing at Mailgun oder Incomplete heißt, sie sind es nicht — dann Reconfigure drücken. Unverified in Gelb heißt "konnte nicht prüfen", nicht "kaputt".
Eine rote Zeile mit Ereignistypen. Die existieren bei Mailgun, zeigen aber auf eine andere URL — der gefährliche Fall, weil nichts kaputt aussieht, während die Ereignisse woanders landen.
Webhook Endpoint URL. Prüfe, dass das deine echte öffentliche Adresse ist. Sie stammt aus der Adresse, mit der diese Installation konfiguriert ist; wurde die nie gesetzt, steht dort der Eigenname der Hosting-Plattform (etwa deineapp.fly.dev) — und dorthin zeigen dann auch die Abmeldelinks. Stimmt sie nicht, setz APP_URL in der Umgebung und drück Reconfigure.

Dann eine Testmail. Das Feld Send Test Email erscheint erst, wenn die Integration verbunden ist — beim ersten Ausfüllen des Dialogs suchst du es vergeblich: speichern, den Dialog offen lassen, dann ist es da. Es baut seinen Absender aus der beim letzten Speichern hinterlegten Adresse, echte Sendungen dagegen aus der aktuellen Email Sender Address. Ein bestandener Test beweist also Key, Region und Domain, nicht die Adresse, die deine Kundschaft sieht. Schlägt er fehl, verdächtige zuerst die Region: Ein US-Key gegen den EU-Host oder umgekehrt zeigt sich nur als "Failed to send test email. Please check your API key and domain.", während Mailguns eigentliche Fehlermeldung im Server-Log liegen bleibt.

Vor der Mailgun-Verbindung meldet jeder Versand Erfolg

Ohne Mailgun-Konfiguration meldet die Versandfunktion Erfolg, schreibt eine Warnung in die Konsole und verschickt nichts — in der Produktion genau wie in der Entwicklung. Nichts wird protokolliert, und die ganze Anwendung glaubt, die Mail sei raus: Testest du einen Anmeldeprozess vor dem Verbinden, bekommst du "Schau in dein Postfach" für einen Code, den nie jemand verschickt hat. Dasselbe gilt, wenn du die Integration später über ihren Schalter abschaltest — das pausiert nicht das Tracking, sondern macht jeden Versand zur stillen Nulloperation.

Schritt 5 — Die Health-Seite lesen

Admin → Email Health, unter Administration; dieselbe Karte sitzt auch im Tab Branding unter den Absenderfeldern. Sie läuft nicht von allein: Du drückst Run check, dann werden die DNS-Abfragen live gemacht, zwischengespeichert wird nichts.

SPF — schlägt fehl bei null Einträgen und ebenso bei mehr als einem. Zwei SPF-Einträge sind nicht doppelter Schutz, sie machen beide ungültig.
DKIM — geprüft werden die Selektoren s1, mg2048, google, k1, mail. Ein Schlüssel unter einem anderen Selektor erscheint als "kein Schlüssel gefunden", obwohl DKIM funktioniert; schau ins Mailgun-Dashboard, bevor du dem nachjagst.
DMARC — deine Policy und ob eine rua=-Adresse existiert.
MX, From alignment und der Gateway-Status, den Mailgun für die Domain meldet.

unknown heißt, DNS hat nicht geantwortet, nicht dass der Eintrag fehlt. Der Tracking-CNAME wird hier nicht geprüft.

Rechne mit einer Unstimmigkeit. Diese Seite prüft die Ausrichtung strenger als die Regel, die das Speichern kontrolliert: Sie akzeptiert nur Adressen auf der Versanddomain selbst oder darunter. [email protected] über mg.deinedomain.de lässt sich speichern, geht unverändert raus und steht auf System Status auf OK — Email Health markiert From alignment trotzdem als Fehler. Die Mail ist in Ordnung; willst du den dauerhaften roten Punkt vermeiden, leg den Absender genau auf die Versanddomain.

Wenn der Absender aus der Ausrichtung läuft

Erzwungen wird die Ausrichtung beim Speichern, nicht beim Versenden. Änderst du Branding nach dem Verbinden, schlägt nichts fehl — der Absender wird still auf noreply@deine-versanddomain umgeschrieben, und höchstens einmal pro Stunde erscheint eine Meldung mit dem Titel "Email sender address is misconfigured". Deine Kundschaft bekommt Mail von einer Adresse, die du nicht gewählt hast, und Antworten laufen in ein Postfach, das niemand liest: Dieses Produkt setzt nirgends einen Reply-To-Header, die Absenderadresse ist die Antwortadresse. System Status weist ebenfalls darauf hin.

Beide Schutzmechanismen greifen nur bei einer Verbindung über die Admin-Oberfläche. Eine Installation, die über MAILGUN_*-Umgebungsvariablen konfiguriert ist, umgeht sie.

Die Reputationszahlen

Der Rest der Seite kombiniert deine eigenen Versandergebnisse mit Mailguns Sperrlisten. Die Schwellen hinter den Farben sind fest: Beschwerden über 0,3 % sind ein hartes Problem, Bounces über 5 %, Zustellung unter 95 %. Zahlen mit "mindestens" sind Untergrenzen, weil die Liste seitenweise zu je 1000 Einträgen gelesen wird.

Zwei Grenzen. Mailguns Sperrliste ist reine Anzeige und wird nie in deine Kontakte zurückgeschrieben. Und eine Beschwerde oder Abmeldung setzt den Kontakt auf UNSUBSCRIBED, ein harter Bounce dagegen ändert am Kontakt nichts — Mailgun weist die Adresse selbst ab, das kostet dich nichts weiter, aber der Kontakt sieht in deiner Liste weiter gesund aus.

Double Opt-in — was echt ist und was nicht

Admin → General Settings → Tab Contacts, Karte "Double opt-in". Vier Optionen: Newsletter signups, Widget & lead forms, Event registrations, Purchases. Newsletter und Widgets sind standardmäßig an; Events und Purchases sind aus und tragen eine Warnung, denn wer erst einen Code verlangt, bevor jemand seinen Zugangslink oder seine Rechnung bekommt, macht aus der Bestätigung eine verpasste Buchung.

Auf der Karte steht, unbestätigte Kontakte würden angelegt, aber nicht angeschrieben. So funktioniert es heute nicht:

Nur der Newsletter-Schalter tut etwas. Die anderen drei speichern und zeigen sich korrekt, aber kein Anmeldeweg liest sie aus.
Nur ein Formular fragt nach einer Bestätigung — die Newsletter-Anmeldung als Site-Component. Kontakte aus Widgets, Veranstaltungen, Käufen, der Admin-Oberfläche, der API oder einem Import werden nie gefragt.
Beim Versand wird die Bestätigung nicht geprüft. Wer einen Code bekommen und nie eingegeben hat, erhält weiterhin Marketing- und Newsletter-Sendungen.

Betrachte es als Weg, Bestätigungen zu sammeln, nicht als Sperre — und verlass dich für eine rechtliche Anforderung nicht darauf, ohne das selbst zu prüfen.

Wo es läuft, wird ein sechsstelliger Code verschickt und auf der öffentlichen Seite /confirm eingegeben, 24 Stunden gültig und nach fünf Fehlversuchen tot. Der Code steht absichtlich in der Betreffzeile, damit er sich aus der Handy-Benachrichtigung ablesen lässt; der Text dieser Mail lässt sich im Vorlagen-Editor nicht ändern.

Abmeldungen

Eine Abmelde-Fußzeile hängt das System automatisch nur an Marketing- und Newsletter-Mail; System- und Transaktionsmail bekommt keine. Der Link führt auf eine Präferenzseite mit vier Möglichkeiten: Pause einlegen (7, 14, 30, 60 oder 90 Tage, 30 vorausgewählt), keine Newsletter, gar kein Marketing, oder Abmeldung von allem.

Eigener Code, der ohne Vorlagentyp verschickt, bekommt still keine Fußzeile, einen leeren Abmeldelink und keine Opt-out-Prüfung — die mitgelieferten Vorlagen geben ihren Typ mit.

Einen One-Click-Unsubscribe-Header gibt es nicht. Es wird kein List-Unsubscribe gesendet und es existiert kein One-Click-Endpunkt, obwohl die Regeln von Gmail und Yahoo für Massenversender genau das verlangen. Bei größeren Mengen ist das eine echte Zustelllücke, und keine, die sich über die Admin-Oberfläche schließen lässt.

Rundsendungen laufen über Admin → Newsletter, das Sequenzen und Einzelsendungen abdeckt. Empfänger werden gefiltert auf angemeldete Kontakte ohne Marketing-Widerspruch, ohne Newsletter-Widerspruch und ohne laufende Pause; sie gehen in Blöcken zu je bis zu 1000 pro Mailgun-Aufruf raus. Es gibt weder Drosselung noch Wiederholung, Mailguns Ratenlimits schlagen also unverändert durch.

Nachrichten, die auf QUEUED hängen, haben zwei sehr verschiedene Ursachen. Bleiben Rundsendungs-Zeilen auf QUEUED, während einzelne Nachrichten normal weiterlaufen, ist das ein bekannter Anzeigefehler im Batch-Weg: Diese Zeilen lassen sich eingehenden Ereignissen nie zuordnen, und deren Ereignisse können zusätzlich doppelte Zeilen erzeugen. Die Mail ist raus — beurteile eine Rundsendung an den Reputationszahlen und an Mailguns eigenen Logs. Steht dagegen alles auf QUEUED, Passwort-Zurücksetzungen und Rechnungen eingeschlossen, erreichen die Webhooks diese Installation nicht: zurück zur Webhook-Karte aus Schritt 4.

Optionales

DMARC-Berichte und Beschwerde-Feedback-Loops haben auf Email Health eigene Einrichtungskarten, solange der jeweilige Abschnitt keine Daten hat. Beide nutzen denselben Ingest-Token, der genau einmal angezeigt wird — erzeugst du ihn neu, brichst du jeden Cloudflare Worker, der den alten hält, und zwar für beide Kanäle. Nimm dafür eine eigene Domain: Cloudflare Email Routing ersetzt MX und SPF am Apex der Zone, in der du es einschaltest — auf deiner Versanddomain zerlegst du damit eingehende Mail und ausgehende Autorisierung auf einen Schlag.

Google Postmaster Tools wird separat verbunden und zeigt Gmails eigene Sicht auf deinen Versand. Google veröffentlicht aber nichts unterhalb von etwa 100–200 Nachrichten pro Tag an verschiedene Gmail-Empfänger; darunter bleibt die Anzeige dauerhaft leer.

Eine Sache, die still allen Mailversand stoppt

API Key und Webhook Signing Key liegen verschlüsselt in der Datenbank. Ist ENCRYPTION_KEY nicht gesetzt, wird der Schlüssel dafür aus AUTH_SECRET abgeleitet. Rotierst du dann AUTH_SECRET, sind die gespeicherten Schlüssel dauerhaft unlesbar — der Versand hört mit einem Entschlüsselungsfehler auf, nicht mit einem erkennbaren Konfigurationsfehler. Wenn du rotierst, verschlüssele die Zugangsdaten im selben Zug mit scripts/reencrypt-secrets.ts neu, oder trag beide Schlüssel danach in der Admin-Oberfläche wieder ein.

Bevor echte Kundschaft das zu sehen bekommt

Admin → Email Builder → Tab Email Templates enthält die zehn mitgelieferten System-Vorlagen: Passwort zurücksetzen, Veranstaltungsanmeldung, Absage und Terminverschiebung, Kontoerstellung, abgebrochener Checkout, Kaufbestätigung, Zahlungsbeleg und zwei Einladungsvorlagen. Jede davon erreicht irgendwann echte Kundschaft — lies sie vorher.

Eine Anmerkung zum Bearbeiten: Der Preheader einer Vorlage wird als unsichtbarer Text an den Anfang der Nachricht gesetzt. Schreib ihn als Vorschautext für den Posteingang, nicht als Fließtext.

Für Mail mit Zugangsdaten schaltet das System das Tracking automatisch ab — Passwort-Zurücksetzungen, Einladungen, Kontoerstellung und alles, was als Verification oder Magic-Link markiert ist. Diese Nachrichten tragen unabhängig von deinen übrigen Einstellungen kein Öffnungs- und kein Klick-Tracking.