Ein Inbound-E-Mail-API empfängt E-Mails, die an eine Adresse oder Domain gesendet werden, die Ihnen gehört, parst sie und liefert sie als strukturierten HTTP-POST an Ihre Anwendung. Statt einen Mailserver zu betreiben und eine Mailbox über IMAP abzufragen, richten Sie die MX-Records Ihrer Domain auf den Anbieter, und jede eingehende Nachricht erreicht Ihren Endpunkt mit bereits in JSON geparsten Headern, Body und Anhängen.
Wie funktioniert Inbound-E-Mail?
Das Routing beginnt bei DNS. Sie setzen die MX-Records für eine Domain oder Subdomain (z. B. reply.yourapp.com) auf die Mailserver des Inbound-Anbieters. Wenn jemand eine Nachricht an eine beliebige Adresse dieser Domain sendet, landet sie auf der Infrastruktur des Anbieters statt auf Ihrer. Der Anbieter nimmt die Nachricht an, parst sie und sendet einen POST-Request an eine von Ihnen registrierte URL mit dem geparsten Inhalt.
Ein geparster Payload enthält typischerweise Absender und Empfänger, den Betreff, den Klartext- und HTML-Body, den vollständigen Header-Satz und eventuelle Anhänge (oft base64-kodiert oder per URL referenziert). Ihre App liest diesen JSON und reagiert darauf, ohne SMTP- oder IMAP-Code pflegen zu müssen. Der Zustellmechanismus ist ein Webhook, daher gelten dieselben Regeln: Antworten Sie schnell mit einem 2xx und verarbeiten Sie die Nachricht asynchron.
Wofür wird es verwendet?
Inbound-E-Mail wandelt empfangene Nachrichten in Anwendungsereignisse um. Gängige Muster sind:
- Antwortverarbeitung. Sie senden eine Benachrichtigung von
notifications@yourapp.com, und wenn ein Benutzer antwortet, kommt die Antwort als POST an, sodass Sie sie in eine Konversation einordnen können. - Support-Ticketing. E-Mails an
support@yourapp.comwerden zu einem neuen Ticket, wobei Absender und Inhalt direkt in Ihren Helpdesk übernommen werden. - Parsen in die Datenbank. Weitergeleitete Belege oder strukturierte E-Mails werden geparst und in eine Tabelle geschrieben, ohne manuelle Eingabe.
- E-Mail als Aktion. Eine Nachricht an eine spezielle Adresse löst einen Workflow aus: Datensatz erstellen, Job starten, in einen Channel posten.
Was ist der Unterschied zum Versenden von E-Mails?
Outbound und Inbound sind getrennte Aufgaben. Outbound bedeutet, dass Ihre App E-Mails über SMTP oder eine HTTP-Send-API an Empfänger zustellt. Inbound ist das Gegenteil: Externe Absender liefern E-Mails an Ihre App. Eine vollständige E-Mail-Integration nutzt in der Regel beides – Benachrichtigungen versenden und Antworten empfangen –, aber beide Seiten werden unabhängig konfiguriert, und die Inbound-Seite hängt von Ihren MX-Records ab.
Warum nicht stattdessen eine Mailbox über IMAP abfragen?
Sie können einen IMAP-Poller gegen eine echte Mailbox betreiben, aber das verursacht laufende Kosten. Sie verwalten Zugangsdaten, legen fest, wie oft abgefragt wird (was Latenz und Leerlaufverbindungen erzeugt), parsen selbst rohes MIME und verfolgen, welche Nachrichten bereits verarbeitet wurden. Ein Inbound-API beseitigt das meiste davon: Der Anbieter parst das MIME, sendet jede Nachricht einmal als sauberes JSON und Sie reagieren nahezu in Echtzeit. Einen Vergleich der zugrunde liegenden Protokolle finden Sie unter SMTP vs. IMAP.
Häufig gestellte Fragen
Welche DNS-Änderungen brauche ich?
Sie setzen die MX-Records für die Domain oder Subdomain, auf der Sie E-Mails empfangen möchten, auf Ihren Inbound-Anbieter. Nach der Propagierung fließen E-Mails an jede Adresse dieser Domain zum Anbieter, der sie parst und an Ihren Endpunkt postet. Eine dedizierte Subdomain hält das Inbound-Routing getrennt vom E-Mail-Verkehr Ihrer Hauptdomain.
Wie werden Anhänge verarbeitet?
Der geparste Payload enthält Anhänge, in der Regel entweder base64-kodiert inline oder als URLs, die Sie separat abrufen. Ihr Handler dekodiert oder lädt sie herunter und speichert sie dort, wo Sie Dateien ablegen. Größere Anhänge werden typischerweise per URL referenziert, um den Payload klein zu halten.
Ist Inbound-E-Mail dasselbe wie ein Webhook?
Die Zustellung nutzt einen Webhook: Der Anbieter sendet Ihrer App für jede Nachricht einen HTTP-POST. Der Unterschied ist, dass der Payload eine vollständig geparste E-Mail statt eines generischen Events ist. Behandeln Sie ihn wie jeden Webhook, indem Sie ihn verifizieren, schnell antworten und asynchron verarbeiten.
Um zu sehen, wie Bird beide E-Mail-Richtungen abdeckt, beginnen Sie mit der E-Mail-Produktübersicht und dem Leitfaden zu E-Mail-Events, der das Event-Zustellmodell beschreibt, auf dem Ihr Inbound-Handler aufbaut.