Mailversand ist einfach

Markus Bode

E-Mails wirken simpel: Schreiben, Senden, fertig. Technisch steckt dahinter aber ein ziemlich komplexer Ablauf mit vielen Stationen. Genau an diesen Zwischenstationen entstehen unterschiedliche “Merkwürdigkeiten”.

Im Folgenden schauen wir uns das Schritt für Schritt an und klären dabei häufige Fragen.

Kurzüberblick: Der Weg einer E-Mail

Grober Standard-Ablauf:

  1. Sie schreiben die Mail im Mailprogramm am Computer oder am Smartphone - oder per Webmail.
  2. Das Gerät verbindet sich mit einem SMTP-Server (Ausgangsserver).
  3. Der SMTP-Server nimmt die Mail an, prüft sie und versucht sie an den Empfänger-Mailserver zu übergeben.
  4. Hierbei kann die Mail ggf. schon abgelehnt werden, u.a. wenn der Empfänger nicht existiert.
  5. Der Empfänger-Mailserver nimmt die Mail an, prüft sie (u. a. Spamfilter, Virenscanner). Durch Greylisting kann die Mail auch temporär abgelehnt werden, was die Zustellung verzögert.
  6. Wenn alles ok ist, landet die Mail im Postfach des Empfängers (z. B. in “Posteingang“ oder im Spam-Ordner). Es ist auch möglich, dass die Empfängeradresse nur eine Weiterleitung war. Dann geht das Spiel wieder von vorne los - u.U. aber mit einer umgeschriebenen “SRS”-Mailadresse.
  7. Es ist auch möglich, dass die Mail von Filter-Regeln beim Empfänger still und heimlich gelöscht wird.
  8. Das Mailprogramm zeigt als Info “Erfolgreich gesendet“ an. Das bezieht sich auf die erfolgreiche Übergabe an den ersten SMTP-Server, nicht an den Empfänger.
  9. Das Mailprogramm sorgt dafür, dass die gesendete Nachricht als Kopie auf dem eigenen Server unter “Gesendete Mails” gespeichert wird.

Warum ist eine erfolgreich verschickte Mail nicht im IMAP-Ordner “Gesendete Mails”?

Dass eine Mail als “erfolgreich gesendet” angezeigt wird, heißt technisch nur: Das Mailprogramm konnte die Mail an den SMTP-Server übergeben. Dass sie im Ordner “Gesendete Mails” erscheint, ist ein zweiter, separater Vorgang, der je nach Setup unterschiedlich läuft.

Typische Ursachen

Viele Mailprogramme (Outlook, Apple Mail, Thunderbird, Smartphone-Apps) speichern eine Kopie der Mail selbstständig im IMAP-Ordner “Gesendete Mails”. Mögliche Fehlerquellen:

  • Falscher Ordner zugeordnet (z. B. “Sent”, nicht “Gesendete Mails”). Das ist häufig der Fall, wenn man unterschiedliche Clients verwendet. Gerät A speichert in “Sent Items”, Gerät B zeigt nur “Gesendete Mails” an.
  • Die Verbindung zum IMAP-Server bricht genau beim Speichern ab.
  • Es wurde ein “lokaler Ordner” benutzt, nicht der IMAP-Ordner.
  • Quota/Platz ist voll, die Mail wird versendet, aber nicht mehr im Ordner gespeichert.
  • Mail bereits aus Versehen aus dem Ordner der gesendeten Mails archiviert oder gelöscht. Ggf. auch durch eine Thread-Ansicht. Häufig liegen die Mails noch auf dem Server, nur nicht im erwarteten Ordner.

Wichtig: Dass die Mail nicht im Ordner “Gesendet” liegt, heißt nicht automatisch, dass sie nicht verschickt wurde. Der Versand und die Ordnerspeicherung sind zwei getrennte Prozesse.

Warum können Mails Minuten, Stunden oder sogar Tage unterwegs sein?

E-Mail ist technisch ein “Best-Effort” - Dienst: Es gibt keine garantierten Zustellzeiten. Die allgemeinen Gründe für Verzögerungen sind:

Zwischenspeicherung in Warteschlangen (Queues)

Jeder Mailserver hat eine Mailqueue: Wenn der Empfänger-Server vorübergehend nicht erreichbar ist (Netzwerkproblem, Wartung, Überlastung), wird die Mail in die Warteschlange gelegt. Der Server versucht in Intervallen erneut zuzustellen (z. B. alle 5–30 Minuten, später mit größeren Abständen).

Greylisting beim Empfänger

Viele Spamfilter nutzen Greylisting: Die erste Zustellung wird absichtlich mit einer temporären Fehlermeldung abgelehnt (“try again later”). Ein legitimer Mailserver versucht es später erneut und Spammer mit einfachen Bots tun das oft nicht.

Die Folge: Die erste Zustellung kann sich um einige Minuten bis zu einer Stunde verzögern.

Überlastete oder fehlerhafte Server

Hohe Last (z. B. Newsletter-Flut, Spam-Wellen, Wartungsarbeiten), interne Probleme im Mail-Cluster des Providers oder DNS-Probleme beim Auflösen der Empfänger-Domain sorgen für Verzögerungen.

Spam- und Sicherheitsprüfungen

Eingehende Mails laufen durch Virenscanner, Content-Filter, Spamfilter, ggf. externe Prüf-APIs. Bei Problemen oder Timeouts in diesen Systemen kann die Mail im Prüfprozess “festhängen”, bevor sie ins Postfach einsortiert wird.

Warum kommen “Unzustellbar”-Meldungen erst nach mehreren Tagen?

Eine “Unzustellbar”-Mail (Mailer-Daemon, Bounce) ist in der Regel eine Nachricht vom sendenden Mailserver, nicht vom Empfänger.

Das Standard-Verhalten vieler Mailserver:

  1. Der Server versucht, eine Mail zuzustellen.
  2. Er erhält temporäre Fehlermeldungen (4xx-Status, z. B. “Mailbox full”, “Try again later”).
  3. Statt sofort aufzugeben, probiert er es immer wieder: Anfangs im Minuten- oder Stundenrhythmus, später in größeren Abständen.
  4. Erst nach einem definierten Zeitraum (üblich 2–5 Tage) wird endgültig aufgegeben.
  5. Dann erzeugt der Server eine Bounce-Mail (“Unzustellbar”) an den Absender.

Deshalb kann es sein, dass Sie mehrere Tage gar nichts hören und dann plötzlich eine Fehlermeldung kommt, obwohl die Mail schon kurz nach dem Versand dauerhaft unzustellbar war (z. B. Postfach nie wieder erreichbar).

Kann eine Mail unzustellbar sein, ohne dass ich eine “Unzustellbar”-Mail zurückbekomme?

Ja, das ist in mehreren Szenarien möglich:

  1. Silent Drop durch Spamfilter. Einige Empfänger-Mailserver (oder vorgeschaltete Spam-Gateways) nehmen die Mail technisch an (melden dem sendenden Server “OK”), entscheiden erst danach, dass sie Spam oder unerwünscht ist und werfen sie einfach weg, ohne Bounce, ohne Zustellung, ohne Info an den Absender.

Aus Sicht des Mailservers: Zustellung erfolgreich. Aus Sicht des Empfängers: Nichts angekommen.

  1. Bounce geht an eine andere Adresse (z. B. modifizierter Absender) Wenn der Envelope-From (technische Absenderadresse) abgeändert ist, geht die Bounce-Mail an diese andere Adresse. Manche Systeme und Weiterleitungen (z.B. im Rahmen von SRS) verändern den Envelope-From so, dass Bounces umgeleitet werden.

  2. Bounces selbst werden gefiltert Der eigene Spamfilter und auch Filterregeln können die “Unzustellbar”-Mails als verdächtig einstufen (Bounces sind ein beliebtes Mittel für Spam) und in den Spamordner verschieben. In seltenen Fällen werden Bounces auch komplett abgewiesen oder durch Filterregeln gelöscht.

Welche Rolle spielen Spamfilter beim Empfänger?

Spamfilter sind heute zentrale Entscheidungsträger bei der Frage, ob und wo eine Mail landet. Sie kombinieren viele Signale:

  • IP-Reputation: Ist die sendende IP-Adresse als Spamquelle bekannt?
  • DNSBL-Listen: Steht der sendende Server auf Blacklists?
  • SPF / DKIM / DMARC: Darf dieser Server Mails im Namen der Domain senden? Ist die Mail kryptografisch signiert und unverändert? Was soll passieren, wenn SPF/DKIM nicht passen?
  • Inhaltliche Analyse: Schlagwörter, typische Spam-Formulierungen, Links, Dateianhänge. HTML- vs. Textverhältnis, Tracking-Pixel, obszöner Inhalt etc.
  • Statistische/ML-basierte Bewertung: Lernende Filter, die aus dem Verhalten der Nutzer lernen (“Spam” / “Kein Spam”).

Mögliche Ergebnisse

  1. Direkt in den Posteingang. Bewertung: unkritisch.
  2. Im Spam-/Junk-Ordner: Der Empfänger bekommt die Mail, aber häufig ohne direkte Benachrichtigung. Viele Nutzer schauen selten in diesen Ordner.
  3. Quarantäne / Web-Portal: Bei Firmen oft so: Die Mail landet in einer Quarantäne und der Nutzer muss sie in einem Portal freigeben.
  4. Silent Drop: Die Mail wird ohne Benachrichtigung verworfen (siehe oben). Besonders verbreitet bei aggressiven Anti-Spam-Systemen oder bei strengen DMARC-Policies.

Spamfilter können also dafür sorgen, dass Sie als Absender keine Fehlermeldung bekommen, der Empfänger die Mail nie sieht, oder die Mail erst nach manuellem Freigeben auftaucht.

Was ist SRS?

SRS bedeutet Sender Rewriting Scheme. Es löst ein ganz konkretes Problem bei E-Mail-Weiterleitungen und SPF.

SPF (Sender Policy Framework) ist ein E-Mail-Authentifizierungsverfahren, bei dem im DNS einer Domain festgelegt wird, welche Mailserver E-Mails für diese Domain versenden dürfen, um Spoofing und Spam zu verhindern.

Ausgangsproblem: SPF und Weiterleitung

SPF prüft: “Darf diese IP für diese Absender-Domain Mails versenden?”

Beispiel-Absender: alice@example.com, der Empfangs-Mailserver leitet alles an alice@gmail.com weiter. Aus Sicht von Gmail: Absender-Domain: example.com sendende IP: Der Empfangs-Mailserver Server (mail.deine-domain.tld) SPF für example.com kennt den Server aber nicht, das sorgt für einen SPF-Fehler und höhere Spam-Wahrscheinlichkeit oder Ablehnung.

Weiterleitungen “brechen” also SPF, wenn man nichts besonderes tut.

Lösung: SRS

SRS ändert beim Weiterleiten die Envelope-From-Adresse (den technischen Absender), damit SPF wieder logisch stimmt.

Aus: MAIL FROM:alice@example.com

wird z. B.: MAIL FROM:SRS0=XYZ=example.com=alice@forwarder.eine-domain.tld

Wichtig: Die Domain hinter dem @ gehört jetzt dem weiterleitenden Server (forwarder.eine-domain.tld). Die SPF-Prüfung läuft jetzt gegen diese Domain und natürlich ist der Server dort als legitimer Sender eingetragen. SPF: PASS, obwohl weitergeleitet wurde.

SPF bleibt bei Weiterleitungen korrekt und sorgt somit für weniger False Positives im Spam. Bounces kommen beim richtigen Absender an, obwohl weitergeleitet wurde. Und es ermöglicht eine saubere Zusammenarbeit von: SPF, DMARC (wenn auf SPF basiert) und Forwardern/Aliasen

Nachforschung: Was man in Logfiles herausfinden kann

Wenn eine Mail scheinbar “verschwunden” ist (keine Zustellung, keine Bounce-Mail, Empfänger hat nichts bekommen), sind Server-Logfiles oft die einzige verlässliche Quelle, um den Weg der Mail nachzuvollziehen.

Was man in Logfiles sehen kann

Typische Informationen:

  • Wurde die Mail vom sendenden Server angenommen?
  • Wann genau (Datum/Uhrzeit, Zeitzone)?
  • An welche Empfängeradresse(n)?
  • Wurde ein Zustellversuch zum Empfänger-Mailserver unternommen?
  • Welche Antwort/Fehlermeldung kam vom Empfänger-Server (inkl. Statuscodes)?
  • Wurde die Mail erneut versucht zuzustellen? Wie oft?
  • Wurde sie letztlich zugestellt, aufgegeben oder verworfen?

Damit lässt sich in vielen Fällen sehr genau rekonstruieren:

  • ob die Mail tatsächlich gesendet wurde,
  • ob sie beim Empfänger-Server angekommen ist,
  • und welcher Server auf dem Weg Probleme gemacht hat.

Angebot: Nachforschungsauftrag (49,00 EUR)

Ich biete einen Nachforschungsauftrag an, bei dem anhand der Logfiles geprüft wird, wie der aktuelle Stand einer konkreten Mail ist, insbesondere dann, wenn die Mail kürzlich verschickt wurde, der Empfänger sie nicht erhalten hat und noch keine Mailer-Daemon-/“Unzustellbar”-Mail zurückgekommen ist.

Wichtige Rahmenbedingung

Die Mail muss innerhalb der letzten 10 Tage verschickt worden sein und der Preis für diese Recherche beträgt 49,00 EUR (Festpreis pro Fall).

Für die Recherche benötige ich diverse Basisdaten.

  • Kundennummer
  • Absenderpostfach und Absender-Adresse
  • Empfängeradresse(n)
  • Versandzeit (Datum und Uhrzeit)

In den Logfiles suche ich nach genau dieser Nachricht. Für die Auswertung schaue ich, ob die Mail auf dem direkten Weg an einen externen Server ging. Falls nicht dokumentiere ich die Zustellversuche und was letzendlich zum aktuellen Stand mit dieser Mail los ist.

So lässt sich in vielen Fällen klären, ob ein Problem auf der eigenen Seite, auf der des Empfängers oder unterwegs im “E-Mail-Nirwana” liegt.