Ratgeber

E-Mails aus deiner App versenden (und im Posteingang landen)

Um E-Mails aus deiner App zuverlässig zu versenden, nutze einen E-Mail-Versanddienst statt deines eigenen Postfachs, versende von einer Adresse auf deiner eigenen Domain und trage die DNS-Einträge ein, die der Anbieter dir gibt, damit SPF, DKIM und DMARC alle bestehen. Halte transaktionale E-Mails wie Passwort-Zurücksetzungen, Quittungen und Bestätigungen getrennt von Marketing-E-Mails. Verschicke jede Art nur an Menschen, die damit rechnen, und kümmere dich um Bounces und Abmeldungen. Die Authentifizierung zuerst richtig einzurichten ist entscheidend, denn sie ist der häufigste Grund, warum App-E-Mails im Spam landen.

Transaktionale vs. Marketing-E-Mail

Diese beiden Arten von E-Mail sehen im Code ähnlich aus, werden aber von Posteingangsdiensten und vom Gesetz sehr unterschiedlich behandelt.

TransaktionalMarketing (Massenversand)
Ausgelöst durchEine Handlung des NutzersDeinen Zeitplan oder eine Kampagne
BeispieleAnmeldebestätigung, Passwort-Zurücksetzung, Magic Link, Quittung, Buchungserinnerung, „Jemand hat geantwortet“Newsletter, Produktankündigung, Aktion, Reaktivierung
EmpfängerEine Person nach der anderenViele auf einmal
EinwilligungErgibt sich aus der HandlungBraucht eine Erlaubnis und eine einfache Abmeldemöglichkeit
TimingMuss in Sekunden ankommenMinuten sind in Ordnung
Wo versendenAus deiner App, über eine APIEin Newsletter-Tool oder die Broadcast-Funktion eines Anbieters

Trenne sie. Wenn eine Marketing-Kampagne Spam-Beschwerden auslöst, sollen Passwort-Zurücksetzungen über denselben Kanal nicht darunter leiden. Ein verbreiteter Ansatz sind getrennte Subdomains, zum Beispiel mail.example.com für Konto-E-Mails und news.example.com für Newsletter. Manche Anbieter trennen beide intern. Postmark beschreibt seine transaktionalen und Broadcast-„Message Streams“ beispielsweise als Versand über getrennte Infrastruktur (Stand September 2026).

Den Anbieter wählen

Deine App sollte nicht selbst von ihrem eigenen Server aus E-Mails versenden. Versanddienste übernehmen die Infrastruktur, die IP-Reputation, Wiederholungsversuche und die Verarbeitung von Bounces. Bekannte Anbieter sind unter anderem Postmark, Resend, SendGrid, Amazon SES und Mailgun. Jeder bietet eine HTTP-API und SMTP-Zugang. Preise und Tarife ändern sich, vergleiche sie daher auf den Webseiten der Anbieter.

Worauf du achten solltest:

  • Schwerpunkt. Manche Anbieter konzentrieren sich auf transaktionale E-Mail, andere kombinieren transaktionale und Marketing-E-Mail.
  • Entwicklererfahrung. Klare API, offizielle Bibliotheken für deine Sprache und nützliche Logs, die zeigen, ob jede Nachricht zugestellt, abgewiesen oder als Spam markiert wurde.
  • Webhooks für Bounces, Beschwerden und Zustellungen, damit deine App reagieren kann.
  • Vorlagen, entweder beim Anbieter gespeichert oder in deinem eigenen Code. Vorlagen im Code zu halten macht sie versioniert und testbar.
  • Region und Datenverarbeitung, falls du Anforderungen daran hast, wo Daten verarbeitet werden.
  • Kosten bei deinem Volumen, auch was passiert, wenn du das kostenlose Kontingent überschreitest.

Für Newsletter an eine Liste ist ein eigenes Newsletter- oder E-Mail-Marketing-Tool oft besser geeignet, als Kampagnenfunktionen in deine App zu bauen.

Deine Versanddomain einrichten

Versende von deiner eigenen Domain, zum Beispiel hallo@example.com, nicht von einer Gmail- oder Outlook-Adresse. Mails von einem kostenlosen Postfach, die über einen Drittanbieter laufen, scheitern an den Authentifizierungsprüfungen und werden wahrscheinlich gefiltert.

Erwäge eine Subdomain nur für den Versand. Resend empfiehlt zum Beispiel, von Subdomains wie updates.example.com zu senden, um die Versandreputation zu isolieren (Stand September 2026). So bleiben die E-Mail-DNS-Einträge außerdem von denen deiner Hauptseite getrennt.

Der Anbieter gibt dir dann DNS-Einträge, die du dort hinterlegst, wo die DNS-Verwaltung deiner Domain liegt. Wenn dir DNS neu ist, erklärt wie Domains und DNS funktionieren zuerst die Einträge.

SPF

SPF (Sender Policy Framework) ist ein TXT-Eintrag, der festlegt, welche Server E-Mails für deine Domain versenden dürfen. Empfänger prüfen, ob der sendende Server auf dieser Liste steht.

  • Eine Domain sollte nur einen SPF-Eintrag haben. Wenn du einen Anbieter hinzufügst, führe ihn in den bestehenden Eintrag zusammen, statt einen zweiten anzulegen.
  • Bei der Auswertung erlaubt SPF höchstens 10 DNS-Abfragen. Lange Ketten von include:-Einträgen können dieses Limit überschreiten und zu Fehlern führen.
  • Viele Anbieter setzen SPF auf einer Return-Path-Subdomain, die sie dich anlegen lassen. Dann musst du deinen Haupt-SPF-Eintrag möglicherweise gar nicht anfassen.

DKIM

DKIM (DomainKeys Identified Mail) fügt jeder Nachricht eine kryptografische Signatur hinzu. Der Anbieter signiert mit einem privaten Schlüssel, und du veröffentlichst den passenden öffentlichen Schlüssel als DNS-Eintrag (je nach Anbieter TXT oder CNAME). Empfänger prüfen die Signatur, um zu bestätigen, dass die Nachricht von einem berechtigten Absender stammt und unterwegs nicht verändert wurde.

Der Schritt „Domain verifizieren“ beim Anbieter dreht sich größtenteils um DKIM. Überspring ihn nicht.

DMARC

DMARC verbindet die beiden anderen Verfahren. Es ist ein TXT-Eintrag unter _dmarc.deinedomain.com, der Empfängern mitteilt:

  • Ausrichtung: Die Domain der sichtbaren Absenderadresse muss zu der Domain passen, die SPF oder DKIM bestanden hat.
  • Richtlinie: Was mit Mails passieren soll, die fehlschlagen: p=none (nur melden), p=quarantine (als verdächtig behandeln, oft im Spam) oder p=reject (ablehnen).
  • Berichte: Wohin aggregierte Berichte gesendet werden (rua=), damit du siehst, wer in deinem Namen als deine Domain sendet.

Ein sinnvoller Weg: Starte mit p=none und einer Berichtsadresse, prüfe, ob deine legitimen Mails bestehen, und wechsle dann zu quarantine und schließlich zu reject. Eine strenge Richtlinie macht es anderen außerdem deutlich schwerer, deine Domain zu fälschen.

Was Gmail verlangt

Seit September 2026 sagen Googles Absender-Richtlinien Folgendes:

  • Alle Absender an persönliche Gmail-Konten brauchen SPF oder DKIM, gültige Forward- und Reverse-DNS-Einträge für sendende Server, TLS und eine Spam-Rate unter 0,3 % in den Postmaster Tools.
  • Massenabsender (mehr als 5.000 Nachrichten am Tag an Gmail) brauchen SPF und DKIM, einen DMARC-Eintrag (eine Richtlinie p=none ist erlaubt), Ausrichtung der Absenderdomain sowie Ein-Klick-Abmeldung und einen sichtbaren Abmeldelink in Marketing- und Abo-Nachrichten.

Dein Anbieter übernimmt die serverseitigen Teile. Die DNS-Einträge und die Abmeldung sind deine Aufgabe. Auch wenn du weit von 5.000 pro Tag entfernt bist, ist das Erfüllen der Massenabsender-Regeln der einfachste Weg, auf der sicheren Seite zu sein.

Den Versand in deine App einbauen

Sobald die Domain verifiziert ist:

  1. Speichere den API-Schlüssel als serverseitiges Geheimnis, niemals im Frontend-Code. Mehr dazu in was Umgebungsvariablen und Geheimnisse sind.
  2. Versende vom Server aus, nachdem die auslösende Aktion erfolgreich war.
  3. Lass Nutzer nicht auf die E-Mail warten. Bei allem, was über die einfachste App hinausgeht, stell den Versand in eine Warteschlange und wiederhole bei vorübergehenden Fehlern, damit eine langsame Antwort des Anbieters die Anmeldung nicht ausbremst.
  4. Protokolliere das Ergebnis, also die Nachrichten-ID und den Status des Anbieters, aber ohne den Schlüssel oder vollständige Nachrichtentexte mit personenbezogenen Daten.
  5. Verarbeite Webhooks für Bounces und Beschwerden. Hör auf, an Adressen zu senden, die dauerhaft abgewiesen werden oder dich als Spam markieren.

Ein Prompt, der die Grundlagen abdeckt:

Sende transaktionale E-Mails mit [ANBIETER] über das serverseitige Geheimnis [ENV_NAME], von „Acme hallo@mail.acme.com“. Sende nach der Anmeldung eine Willkommens-E-Mail und nach dem Speichern einer Buchung eine Buchungsbestätigung. Halte die Vorlagen im Code, mit einer Textversion neben der HTML-Version. Stelle Versandvorgänge in eine Warteschlange und wiederhole vorübergehende Fehler bis zu dreimal. Protokolliere Fehler mit der Fehlermeldung des Anbieters, aber niemals den API-Schlüssel. Füge einen Webhook-Endpunkt hinzu, der Adressen bei dauerhaften Bounces und Beschwerden als nicht zustellbar markiert und sie künftig überspringt.

Konto-E-Mails wie Bestätigungslinks, Magic Links und Passwort-Zurücksetzungen gehören zur Anmeldung. Wie du Login in deine App einbaust erklärt, wie diese Abläufe zusammenpassen. Mach diese Links einmalig verwendbar und kurzlebig.

Gewohnheiten für gute Zustellbarkeit

Die Authentifizierung sorgt dafür, dass du überhaupt beachtet wirst. Dein Verhalten hält dich im Posteingang.

  • Sende nur, womit Menschen rechnen. Bestätigte Anmeldungen, klare Zustimmung für Marketing, keine gekauften Listen.
  • Mach Abmelden einfach bei allem, was nicht streng transaktional ist, und respektiere es sofort.
  • Wärme neue Domains auf. Eine brandneue Domain, die am ersten Tag Tausende Nachrichten verschickt, wirkt verdächtig. Beginne mit deinen transaktionalen Mails und steigere das Volumen schrittweise.
  • Halte Listen sauber. Entferne dauerhafte Bounces sofort und erwäge, Menschen zu entfernen, die lange nichts geöffnet haben.
  • Schreib wie ein Mensch. Ein klarer Betreff, ein wiedererkennbarer Absendername, ein Textteil und wenige Bilder und Links, die auf deine eigene Domain zeigen. Vermeide Link-Verkürzer.
  • Überwache es. Registriere deine Domain in den Google Postmaster Tools und lies hin und wieder die DMARC-Berichte.
  • Nutze eine echte Antwortadresse, die tatsächlich jemand liest. Antworten sind ein gutes Signal und liefern nützliches Feedback.

Testen, ohne jemanden zuzuspammen

  • Nutze den Testmodus oder die Sandbox deines Anbieters, sofern vorhanden, oder sende an Adressen, die dir gehören.
  • Schick in der Entwicklung an ein Test-Postfach, das alles empfängt, statt an echte Nutzer. Eine Datenbank voller echt aussehender Adressen ist ein einfacher Weg, aus Versehen Fremde anzuschreiben.
  • Prüfe jede Vorlage in mehreren Clients: Gmail im Browser, einer Mail-App auf dem Handy, Outlook, und auch im Dunkelmodus.
  • Schau dir die Kopfzeilen einer Test-Mail an. Dort siehst du, ob SPF, DKIM und DMARC bestanden wurden.

Rechtliche Grundlagen

Die Regeln unterscheiden sich je nach Land. Grob gesagt braucht Marketing-E-Mail in vielen Ländern eine Einwilligung, muss den Absender nennen und eine funktionierende Abmeldung bieten. Transaktionale E-Mail wird anders behandelt, sollte aber nicht dazu genutzt werden, Werbung unterzuschieben. Wenn du Adressen über eine Warteliste sammelst, sag klar, was du versendest und speicherst, und wann und wie sich jede Person angemeldet hat. Im Zweifel prüfe die Regeln in den Ländern, in denen deine Nutzer sitzen.

E-Mail-Checkliste

  • Versanddienst gewählt; API-Schlüssel als serverseitiges Geheimnis gespeichert
  • Versand von deiner eigenen Domain oder Subdomain, nicht von einem kostenlosen Postfach
  • SPF-, DKIM- und DMARC-Einträge hinzugefügt und bestanden
  • Transaktionale und Marketing-Mails getrennt
  • Versand in eine Warteschlange gestellt und wiederholt; Ergebnisse protokolliert
  • Webhooks für Bounces und Beschwerden verarbeitet
  • Abmeldung bei nicht transaktionalen Mails, sofort respektiert
  • Vorlagen in mehreren Clients getestet; Test-Mails erreichen nie echte Nutzer

E-Mails aus einer Mythex-App versenden

Mythex enthält keinen eingebauten E-Mail-Versanddienst für die Apps, die du baust. Du bringst daher einen Anbieter wie Resend, SendGrid oder Postmark mit. Speichere dessen API-Schlüssel als Projektgeheimnis. Der Agent kann dich im Chat über eine Geheimnis-Karte danach fragen. Beschreibe die E-Mails, die du brauchst, in einfachen Worten. In der Dokumentation gibt es einen Starter-Prompt unter E-Mail aus deiner App versenden. Wenn du deine Domain im Pro-Tarif über Mythex gekauft hast, kannst du die TXT- und CNAME-Einträge des Anbieters in den DNS-Einstellungen der Domain hinterlegen. Details dazu stehen unter Custom Domains.

Fragen

Was ist der Unterschied zwischen transaktionaler und Marketing-E-Mail?

Transaktionale E-Mail wird durch eine Handlung des Nutzers ausgelöst und wird erwartet, etwa eine Passwort-Zurücksetzung, eine Quittung oder eine Buchungsbestätigung. Marketing-E-Mail geht nach deinem Zeitplan an viele Menschen, zum Beispiel Newsletter und Ankündigungen. Für beide gelten unterschiedliche Einwilligungsregeln, deshalb versendet man sie am besten über getrennte Kanäle oder Subdomains.

Warum landen die E-Mails meiner App im Spam?

Meist fehlen SPF, DKIM und DMARC für die Versanddomain, oder die Mails werden über einen Drittanbieter mit einer kostenlosen Adresse wie Gmail verschickt. Auch eine brandneue Domain ohne Reputation oder Inhalte und Links, die nach Spam aussehen, können die Ursache sein. Richte zuerst die Authentifizierung ein und prüfe dann Inhalt und Versandmenge.

Kann ich E-Mails für meine App über mein Gmail-Konto senden?

Für ein paar persönliche Testnachrichten vielleicht, aber nicht für eine echte App. Nutze einen E-Mail-Versanddienst mit deiner eigenen Domain, richte die DNS-Einträge ein, die er dir gibt, und versende von einer Adresse auf dieser Domain.

Brauche ich DMARC?

In der Praxis ja. Seit September 2026 verlangt Google DMARC von allen, die mehr als 5.000 Nachrichten am Tag an Gmail-Adressen senden. Ein DMARC-Eintrag schützt außerdem deine Domain vor Fälschung. Eine Richtlinie mit p=none ist zum Start in Ordnung, solange du die Berichte prüfst.

Mythex · Pricing · Alles mit KI bauen · Vorlagen für Websites und Apps · Mythex im Vergleich · Glossar zum App-Bau mit KI · Kostenlose Tools für den App-Bau mit KI · English

English አማርኛ العربية Български বাংলা Bosanski Català Čeština Dansk Ελληνικά Español Español (España) Eesti فارسی Suomi Français Français (Canada) ગુજરાતી हिन्दी Hrvatski Magyar Հայերեն Bahasa Indonesia Íslenska Italiano 日本語 ქართული Қазақ тілі ಕನ್ನಡ 한국어 Lietuvių Latviešu Македонски മലയാളം Монгол मराठी Bahasa Melayu မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Polski Português (Brasil) Português (Portugal) Română Русский Slovenčina Slovenščina Soomaali Shqip Srpski Svenska Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)