Mail Transfer Agent (MTA): Was ist das und wie kommt E-Mail an?

Was ist ein Mail Transfer Agent (MTA)?

Ein Mail Transfer Agent (MTA) ist die Software, die Mails von einem Server zum nächsten befördert. Er nimmt eine Nachricht an, sucht über den MX Record der Empfängerdomain den richtigen Server und übergibt die Nachricht per SMTP. Die Zustellung ins Postfach übernimmt ein anderer Baustein, der MDA. Postfix, Exim und Sendmail sind zum Beispiel bekannte Vertreter.

Dieser Ratgeber richtet sich an Betreiber von Websites und Onlineshops sowie an Entwickler, die ihren eigenen Hostingaccount verwalten. Zunächst erklären wir den Weg einer E-Mail und die vier Rollen auf diesem Weg. Danach behandeln wir den Unterschied zwischen Port 25 und 587, die Warteschlange, das Relaying und das Risiko eines offenen Relays.

Wir sind ein Team für digitales Marketing und Webentwicklung, kein Hostinganbieter. Deshalb stützen sich die Erklärungen auf RFC Dokumente und die offiziellen Richtlinien von Google für E-Mail Absender. Eine Installationsanleitung geben wir daher nicht. Stattdessen möchten wir Ihnen helfen, Entscheidungen zur E-Mail Infrastruktur zu verstehen und Ihrem Anbieter die richtigen Fragen zu stellen.

Die Frage "Was ist ein MTA?" taucht meist zu einem ungünstigen Zeitpunkt auf. Eine Benachrichtigung aus dem Kontaktformular kommt nicht an, ein Newsletter landet im Spam, oder eine Rückläufer Nachricht erscheint. Dieser Artikel zeigt Ihnen, was Sie in jedem dieser Fälle prüfen. Noch ein Hinweis zur Schreibweise: RFC 5598 nennt den Begriff "Message Transfer Agent", im Alltag sagt man meist "Mail Transfer Agent". In der Praxis meinen beide denselben Baustein.

Wie unterscheiden sich MTA, MUA, MSA und MDA?

E-Mail ist nicht die Arbeit eines einzelnen Programms, denn mehrere Rollen arbeiten zusammen. Die Kette besteht aus vier Rollen, und RFC 5598 (die Architektur der Internet E-Mail) definiert jede davon. Allerdings kann in kleinen Umgebungen eine Software mehrere Rollen übernehmen. Dennoch hilft die Trennung der Rollen, die Fehlerquelle zu finden.

RFC 5598 vergleicht einen MTA mit einem Paketvermittler oder einem IP Router. Das heißt, seine Aufgabe ist eine Routing Entscheidung, die die Nachricht näher zum Empfänger bringt. Die Verwaltung des Postfachs oder der Benutzeroberfläche gehört nicht dazu. Zum Beispiel liegt das Problem beim MSA, wenn Sie sich nicht anmelden können. Verlässt die Nachricht Ihren Server, kommt aber nie an, schauen Sie auf den MTA und Ihre DNS Einträge.

Welchen Weg nimmt eine E-Mail vom Absender zum Empfänger?

Wenn Sie den Weg Schritt für Schritt verfolgen, wird die Stellung des MTA klar. Die Reihenfolge unten zeigt also eine typische Zustellung in vereinfachter Form. Allerdings kommen in echten Umgebungen oft weitere Server, Sicherheitsscanner und Weiterleitungen hinzu.

1. Zunächst schreibt der Absender die Nachricht im MUA und klickt auf Senden.
2. Danach übergibt der MUA sie an den MSA, der die Identität prüft und sie an den ausgehenden MTA weitergibt.
3. Dann fragt dieser MTA im DNS den MX Record der Empfängerdomain ab.
4. Anschließend verbindet er sich mit dem Server aus dem MX Record und liefert die Nachricht per SMTP aus.
5. Dort nimmt der MTA des Empfängers die Nachricht an und gibt sie an den MDA weiter.
6. Schließlich schreibt der MDA die Nachricht ins Postfach des Empfängers.
7. Zuletzt öffnet der Empfänger das Postfach in seinem eigenen MUA und liest die Nachricht.

Schritt vier befördert die Nachricht von Server zu Server, und genau das ist die eigentliche Arbeit des MTA. Dagegen bereiten die übrigen Schritte die Nachricht vor oder schließen die Zustellung ab.

Daher nutzen Sie diese Reihenfolge bei der Fehlersuche als Landkarte. Hängt die Nachricht bei Schritt zwei, haben Sie ein Authentifizierungsproblem. Hängt sie dagegen bei Schritt drei, fehlt der DNS Eintrag oder er ist falsch. Bei Schritt vier lehnt der Empfangsserver die Nachricht ab oder meldet einen vorübergehenden Fehler. Probleme bei den Schritten fünf und sechs liegen meist im System des Empfängers, zum Beispiel in einem vollen Postfach.

Wie hängt ein Mail Transfer Agent mit dem MX Record zusammen?

Ein MX Record ist der DNS Eintrag, der Absendern sagt, welcher Server die Mails einer Domain annimmt. Der ausgehende MTA fragt den MX Record der Empfängerdomain ab und verbindet sich mit dem Server, den er zurückbekommt. Laut RFC 5321 Abschnitt 3.6.2 ist ein Relay Server meist das Ziel eines MX Records und nicht das endgültige Zustellsystem.

Hat eine Domain zum Beispiel mehrere MX Records, trägt jeder einen Prioritätswert. Der MTA probiert zuerst den niedrigsten Wert, also den bevorzugten Server. Antwortet dieser nicht, geht er dann zum nächsten Eintrag über. Fehlt der MX Record ganz, erlaubt RFC 5321 in Abschnitt 5.1 den Rückgriff auf den A oder AAAA Record.

Folglich schickt ein falscher MX Record Mails zum falschen Server oder ins Leere. Ihre Einträge prüfen Sie mit unserer DNS Abfrage. Kontrollieren Sie sie vor allem nach einem Wechsel des E-Mail Anbieters. Eine DNS Änderung braucht Zeit, bis sie überall ankommt, und in dieser Phase können manche Nachrichten zum alten und manche zum neuen Server gehen.

Was ist SMTP und wie sprechen MTAs miteinander?

SMTP (Simple Mail Transfer Protocol) ist das Protokoll, mit dem MTAs Mails weiterreichen, und RFC 5321 definiert es. Es ist ein Textprotokoll, also sendet der Client sendet einen Befehl, und der Server antwortet mit einem dreistelligen Code. Zum Beispiel zeigt die gekürzte Sitzung unten den Ablauf mit Beispieldomains.

S: 220 mx.example.net ESMTP bereit
C: EHLO mail.example.com
S: 250-mx.example.net
S: 250 STARTTLS
C: MAIL FROM:<absender@example.com>
S: 250 OK
C: RCPT TO:<empfaenger@example.net>
S: 250 OK
C: DATA
S: 354 Nachricht senden, mit einem Punkt beenden
C: (Kopfzeilen und Nachrichtentext)
C: .
S: 250 In Warteschlange
C: QUIT

Das S am Zeilenanfang steht für den Server, das C für den Client. Zuerst stellen sich beide Seiten vor (EHLO). Dann folgen die Umschlagdaten (MAIL FROM und RCPT TO), und zuletzt kommt die Nachricht selbst (DATA). Sagt der Server "In Warteschlange", hat er die Verantwortung übernommen, und dieser Punkt spielt im Abschnitt zur Warteschlange eine Rolle. Daher heißt "gesendet" nicht zwingend "angekommen". Es bedeutet nur, dass der erste MTA die Nachricht angenommen hat.

Was ist der Unterschied zwischen Port 25, 587 und 465?

Port 25 dient dem Transfer zwischen Servern, Port 587 ist der Submission Port, über den ein Client eine Nachricht zum ersten Mal abgibt. Laut RFC 6409 muss ein MSA auf Port 587 standardmäßig den MAIL Befehl ablehnen, wenn die Sitzung nicht authentifiziert ist. Port 465 kommt in RFC 6409 nicht vor, und manche Anbieter bieten ihn mit implizitem TLS an.

In der Praxis tragen Sie beim Einrichten eines Mailprogramms oder eines WordPress Plugins den Port und die Verschlüsselung ein, die Ihr Anbieter vorgibt. Daher probieren Sie nicht wahllos Ports aus. Verlassen Sie sich stattdessen auf die Hilfeseite Ihres Anbieters.

Welche Mail Transfer Agents gibt es: Postfix, Exim oder Sendmail?

Postfix, Exim und Sendmail sind verschiedene Programme, die dieselbe Arbeit leisten. Alle sprechen SMTP, führen eine Warteschlange und leiten Mails weiter. Allerdings zeigen sich die Unterschiede im Stil der Konfiguration, im Standardverhalten und in der Distribution oder dem Hostingpanel, das sie mitbringt. Die Tabelle unten gibt nur einen groben Rahmen.

Welcher davon läuft, entscheiden Sie oft nicht selbst. Bei Shared Hosting trifft der Anbieter diese Wahl. Deshalb stellen Sie besser nicht die Frage, welcher MTA besser ist, sondern diese: Wie organisiert mein Anbieter die E-Mail Zustellung?

Was ist die MTA Warteschlange und warum warten Mails?

Die Warteschlange ist der Ort, an dem ein MTA Nachrichten zwischenspeichert, die er noch nicht zustellen konnte. Ist der Empfangsserver ausgelastet, meldet er einen vorübergehenden Fehler oder ist er nicht erreichbar, löscht der MTA die Nachricht nicht. Stattdessen versucht er es in Abständen erneut. RFC 5321 Abschnitt 4.5.4 sieht vor, dass dieser Wiederholungsprozess mehrere Tage läuft.

Postfix nutzt zum Beispiel mehrere Bereiche: incoming für neue Mails, active für Mails in der Zustellvorbereitung, deferred für zurückgestellte Mails und hold für von Hand angehaltene Mails. Diese Namen stehen im Postfix Dokument QSHAPE. Was gerade wartet, sehen Sie mit den folgenden Befehlen.

postqueue -p
mailq

Der zweite Befehl entspricht dem ersten. Die Ausgabe zeigt zu jeder Nachricht die Queue ID, die Größe sowie Absender und Empfänger. Stauen sich Tausende Nachrichten, liegt die Ursache meist beim Empfänger, oder unerwünschte Mails verlassen Ihren Server. Löschen Sie die Warteschlange in diesem Fall also nicht auf eigene Faust. Informieren Sie stattdessen Ihren Anbieter.

Was bedeuten SMTP Fehlercodes: 4xx oder 5xx?

Die erste Ziffer einer SMTP Antwort verrät, ob das Problem vorübergehend oder dauerhaft ist. Codes mit einer 4 am Anfang sind vorübergehend, daher behält der MTA die Nachricht und versucht es erneut. Codes mit einer 5 sind dauerhaft, also gibt der MTA auf und erzeugt eine Rückläufer Nachricht für den Absender.

Existiert die Empfängeradresse zum Beispiel nicht, erhalten Sie einen 5xx Fehler und müssen die Adresse korrigieren. Ist der Empfangsserver gerade ausgelastet, bekommen Sie einen 4xx Fehler, und der MTA versucht es von selbst noch einmal. Lesen Sie den Text einer Rückläufer Nachricht immer genau, denn die Ursache steht meist direkt darin.

Warum kommt eine Rückläufer Nachricht mit leerem Absender?

Eine Rückläufer Nachricht teilt dem Absender mit, dass eine E-Mail nicht zugestellt werden konnte. RFC 5321 Abschnitt 4.5.5 verlangt für solche Benachrichtigungen eine leere Rückleitungsadresse: MAIL FROM:<>. Das Ziel ist, eine Endlosschleife zu verhindern, falls auch die Rückläufer Nachricht nicht ankommt.

Außerdem hilft dieses Detail bei der Fehlersuche. Wirkt das Absenderfeld einer Rückläufer Nachricht leer oder wie eine Systemadresse, ist das normal. Wichtig ist vor allem die technische Erklärung im Text. Konkret finden Sie dort den Namen des Empfangsservers, den Fehlercode und eine kurze Begründung.

• Prüfen Sie, ob der Fehlercode mit 4 oder 5 beginnt.
• Suchen Sie den Begründungstext in Anführungszeichen in einer Suchmaschine.
• Erkennen Sie am Namen des Empfangsservers, auf welcher Seite das Problem liegt.
• Leiten Sie bei Bedarf die vollständige Nachricht an Ihren Anbieter weiter.

Was bedeutet ein gehosteter E-Mail Dienst für Ihren Mail Transfer Agent?

Nutzen Sie einen Cloud Dienst wie Google Workspace oder Microsoft 365, betreibt der Anbieter den MTA für Sie. Sie richten nur Ihre MX Records auf die Werte aus, die der Dienst nennt. Dadurch liegen Warteschlange, TLS, Relay Beschränkungen und Sicherheitsupdates nicht mehr bei Ihnen.

Allerdings geben Sie nicht alles ab. Die SPF, DKIM und DMARC Einträge Ihrer Domain verwalten Sie weiterhin selbst. Außerdem legen Sie fest, wie die eigenen Mails Ihrer Website, etwa Bestellbenachrichtigungen und Formularantworten, zu diesem Dienst gelangen. Prüfen Sie deshalb beim Wechsel zu einem neuen Dienst zwei Dinge: Ihre MX Records und die Art, wie Ihre Website Mails versendet.

Die Anbieterwahl ist allerdings ein eigenes Thema, und wir vergleichen hier keine Anbieter. Die Optionen und die Vorteile einer Adresse mit eigener Domain finden Sie in unserem Ratgeber zur Firmenadresse.

Was bedeuten Smarthost und Weiterleitung für einen MTA?

Ein Smarthost liegt vor, wenn ein MTA ausgehende Mails an einen anderen Server übergibt, statt sie selbst zuzustellen. Der lokale MTA auf Ihrem Server sendet zum Beispiel nicht direkt an den Empfänger. Er reicht die Nachricht an einen authentifizierten E-Mail Dienst weiter. Die Reputation der Zustellung hängt dann von der Infrastruktur dieses Dienstes ab.

Eine Weiterleitung ist dagegen etwas anderes. Eine Nachricht an eine Adresse geht automatisch an eine andere Adresse weiter. Dabei bleibt der ursprüngliche Absenderserver gleich, aber der sendende Server ist nun der Weiterleiter. Deshalb können manche Empfangsserver weitergeleitete Nachrichten bei der SPF Prüfung durchfallen lassen.

• Ein Smarthost bestimmt, über welchen Server ausgehende Mails den Weg nehmen.
• Eine Weiterleitung bringt eingehende Mails an eine andere Adresse.
• In beiden Fällen achten Sie auf Authentifizierung und passende Einträge.
• Die Einstellungswerte entnehmen Sie der Hilfeseite Ihres Anbieters.

Was ist ein Relay und warum ist ein offenes Relay gefährlich?

Ein Relay liegt vor, wenn ein MTA Mails für eine fremde Domain an einen anderen Server weitergibt. Legitimes Relaying funktioniert für authentifizierte Nutzer oder definierte Netzwerke. Ein offenes Relay ist dagegen ein falsch konfigurierter Server, der Mails von jedem an jede Adresse weiterleitet.

Die Gefahr ist einfach. Ein Angreifer kann über ein offenes Relay Millionen unerwünschter Mails unter dem Namen Ihres Servers verschicken. Folglich landet Ihre IP Adresse auf Sperrlisten, Ihre legitimen Mails fallen in den Spam, und Ihr Anbieter kann Ihr Konto sperren. Schlimmer noch: Oft merken Sie das wochenlang nicht.

RFC 5321 Abschnitt 3.6.2 sagt, dass ein Server aus Richtlinien Gründen das Relaying an eine bestimmte Adresse ablehnen darf und dann mit 550 antworten soll. Moderne MTA Software erlaubt ein offenes Relay standardmäßig nicht. Das Risiko entsteht meist durch zu weit gefasste Freigaben, die jemand von Hand eingetragen hat.

Wie stellen Sie sicher, dass Ihr Server kein offenes Relay ist?

Klären Sie zuerst, wer den Server verwaltet. Bei Shared Hosting oder einem verwalteten VPS liegen die Relay Einstellungen in der Verantwortung des Anbieters. Bitten Sie ihn in diesem Fall um eine schriftliche Zusicherung. Betreiben Sie Ihren eigenen VPS, lesen und prüfen Sie die Relay Beschränkungen in der offiziellen Dokumentation des MTA.

Bei Postfix sind die Parameter smtpd_relay_restrictions und mynetworks maßgeblich. Ihre genaue Bedeutung und sichere Werte lesen Sie in der offiziellen Postfix Dokumentation nach. Wir empfehlen hier keine Werte, denn ein falscher Eintrag bei mynetworks kann Ihren Server für das ganze Netz öffnen.

• Achten Sie auf ungewöhnlich viele ausgehende Mails des Servers.
• Beobachten Sie, ob die Warteschlange auffällig wächst.
• Werden Sie misstrauisch, wenn viele Rückläufer eintreffen.
• Prüfen Sie gemeinsam mit Ihrem Anbieter, ob Ihre IP Adresse auf einer Sperrliste steht.

Überschwemmen Sie keine fremden Server mit Testnachrichten. Testen Sie nur mit Adressen unter Ihrer Kontrolle und mit Wissen Ihres Anbieters.

Sollten Sie einen eigenen Mail Transfer Agent betreiben oder dem Hoster überlassen?

Für die meisten Websitebetreiber ist die Antwort klar: Überlassen Sie die E-Mail Infrastruktur Ihrem Anbieter oder einem verwalteten E-Mail Dienst. Einen eigenen MTA zu betreiben heißt, DNS Einträge, TLS, Warteschlange, Sperrlisten und Sicherheitsupdates dauerhaft im Blick zu halten. Ein einziger Fehler kann den Ruf Ihrer ganzen Domain beschädigen.

In diesen Fällen sollten Sie den MTA nicht selbst übernehmen:

• Sie haben keine Erfahrung mit der Diagnose von Zustellproblemen.
• Ihre Website versendet wichtige Nachrichten wie Kundenmails und Bestellbenachrichtigungen.
• Sie haben keine Zeit, Sicherheitsupdates regelmäßig zu verfolgen.
• Ihr Server steht bei Shared Hosting, wo Sie ohnehin keinen Zugriff haben.

Verwalten Sie Ihren eigenen VPS und möchten trotzdem einen MTA einrichten, lesen Sie zuerst unseren Ratgeber zur Hostingauswahl. Unsere Anleitungen zu Fail2ban und zur CSF Firewall helfen Ihnen zudem beim Schutz des Servers.

Wie hängen SPF, DKIM und DMARC mit dem MTA zusammen?

SPF, DKIM und DMARC sind Einträge im DNS, die der empfangende MTA prüft, um zu bestätigen, dass eine Nachricht wirklich von Ihnen stammt. Laut den Richtlinien von Google müssen alle Absender SPF oder DKIM einrichten. Wer mehr als 5.000 Nachrichten pro Tag verschickt, muss alle drei einrichten: SPF, DKIM und DMARC.

• SPF listet auf, welche Server im Namen Ihrer Domain Mails senden dürfen.
• DKIM fügt der Kopfzeile eine digitale Signatur hinzu und zeigt, dass der Inhalt unverändert ist.
• DMARC legt fest, was der Empfänger tun soll, wenn die Prüfung fehlschlägt.

Kurz gesagt: Der MTA befördert die Nachricht, und diese drei Einträge belegen, dass die beförderte Nachricht vertrauenswürdig ist. Ihre Einträge testen Sie mit unserem SPF, DKIM und DMARC Check. Listen Sie vor jeder Änderung alle Dienste auf, die Mails für Sie senden, etwa Website, CRM und Newsletter Tool. Denn ein fehlender Eintrag schickt die Mails dieses Dienstes in den Spam.

Warum sind PTR Records und TLS für die Zustellung wichtig?

Empfangende MTAs prüfen auch die Identität des verbindenden Servers. Laut den Google Richtlinien muss die sendende IP Adresse zur IP Adresse des Hostnamens im PTR Record passen. Zudem muss der Forward DNS Eintrag (A oder AAAA) auf dieselbe IP Adresse zeigen. Fehlt diese Übereinstimmung, kann eine Nachricht abgelehnt werden oder im Spam landen.

Dieselben Richtlinien verlangen eine TLS Verbindung für den E-Mail Versand. TLS erschwert es, eine Nachricht auf dem Weg zwischen Servern mitzulesen. Somit helfen PTR und TLS Ihrem Server, wie ein ordentlich betriebener MTA zu wirken.

Den PTR Record setzt in der Regel der Besitzer der IP Adresse, also Ihr Hosting oder Cloud Anbieter. In Ihrem eigenen DNS Panel können Sie keinen PTR Record anlegen. Wenden Sie sich deshalb an Ihren Anbieter. Stellen Sie sich eine Beispieladresse wie 203.0.113.10 vor: Nur die Stelle, die Ihnen die Adresse zugeteilt hat, kann den Reverse Eintrag ändern. Fragen Sie den Support konkret, auf welchen Hostnamen der PTR Record Ihrer Server IP zeigt.

Versenden WordPress Websites Mails über einen MTA?

Ja, aber auf zwei verschiedenen Wegen. Standardmäßig nutzt WordPress die Mailfunktion von PHP, die die Nachricht an den lokalen MTA des Servers übergibt. Die Alternative ist die authentifizierte Verbindung zu einem externen E-Mail Dienst über ein SMTP Plugin. Plugins wie WP Mail SMTP erleichtern diesen zweiten Weg.

Hier wird die Frage, was ein Mail Transfer Agent leistet, ganz praktisch. Die E-Mail Ihrer Website verlässt das System über einen lokalen MTA oder einen externen Dienst, und der Empfänger beurteilt sie nach dieser Quelle. Formularbenachrichtigungen im Spam sind oft die Folge der ersten Methode. Absenderdomain und sendender Server passen nicht zusammen, daher schlagen SPF und DKIM fehl.

Unser Ratgeber zur Firmenadresse behandelt die geschäftliche Seite ausführlicher. Die Einrichtung des Plugins erklären wir hier nicht. Verwenden Sie die SMTP Werte, die Ihr Anbieter Ihnen nennt.

Wie diagnostizieren Sie Mails, die nicht zugestellt werden?

Klären Sie zuerst, wer verantwortlich ist: der Absender, der Empfänger oder ein Server dazwischen. Die Reihenfolge unten geht von der günstigsten Prüfung zur aufwendigsten. So belästigen Sie Ihren Anbieter nicht unnötig, verlieren aber auch keine Zeit, wenn Sie ihn brauchen.

1. Zunächst lesen Sie die Rückläufer Nachricht und notieren, ob der Code mit 4 oder 5 beginnt.
2. Danach prüfen Sie, ob Sie die Empfängeradresse richtig geschrieben haben.
3. Dann kontrollieren Sie die MX Records der Domain mit einer DNS Abfrage.
4. Anschließend testen Sie die SPF, DKIM und DMARC Einträge.
5. Außerdem prüfen Sie die IP Adresse Ihres Servers und den Reverse DNS Eintrag.
6. Fragen Sie dann Ihren Anbieter, ob Nachrichten in der Warteschlange hängen.
7. Schließlich eröffnen Sie bei anhaltendem Problem ein Supportticket mit der vollständigen Rückläufer Nachricht.

Mit der IP Abfrage sehen Sie außerdem, wem eine IP Adresse gehört. Dieser Schritt zeigt Ihnen, ob das Problem auf Ihrem Server oder bei einem Dritten liegt.

Was ändert sich für das E-Mail Marketing bei der Wahl eines MTA?

Bei Newslettern und Kampagnen zählt die Absenderreputation mehr als der MTA selbst. Das Verhalten aller, die über dieselbe IP Adresse senden, beeinflusst deren Ruf. Zudem können Empfangsserver beim Massenversand Ratenlimits setzen und Nachrichten mit einem vorübergehenden 4xx Fehler abweisen.

Deshalb ist es keine gute Idee, Kampagnen über denselben Weg wie Ihr normales Postfach zu verschicken. Transaktionsmails wie Bestellungen und Passwort Rücksetzungen von Marketingmails zu trennen, ist sinnvoll, weil die Probleme des einen Stroms den anderen nicht treffen sollten. Die Dokumentation Ihres E-Mail Dienstes zeigt, wie Sie diese Trennung umsetzen.

Die Google Richtlinien verlangen, die in den Postmaster Tools gemeldete Spamrate unter 0,3 Prozent zu halten. Also sind Listenpflege und einfaches Abmelden ebenso wichtig wie technische Einstellungen. Wie KI zu Kampagnen passt, lesen Sie in unserem Artikel KI im E-Mail Marketing.

Welche verbreiteten Irrtümer gibt es über MTAs?

Wir hören immer wieder dieselben Irrtümer über MTAs. Wenn Sie sie kennen, sparen Sie Zeit im Gespräch mit Ihrem Anbieter und bei der Fehlersuche. Unten nennen wir jeweils die richtige Version.

• "Der MTA ist das Postfach." Nein, der Baustein, der ins Postfach schreibt, ist der MDA.
• "Port 25 und 587 sind dasselbe." Nein, einer dient dem Transfer zwischen Servern, der andere der Abgabe durch Clients.
• "Ohne MX Record kommt keine E-Mail an." Nicht immer, denn RFC 5321 erlaubt den Rückgriff auf einen A oder AAAA Record.
• "Nachrichten in der Warteschlange sind verloren." Meist nicht, der MTA versucht es erneut.
• "Ich habe SPF eingerichtet, also bin ich fertig." Das reicht nicht, Sie brauchen auch DKIM und DMARC.

Die meisten Irrtümer entstehen, weil man E-Mail auf eine einzige Software reduziert. In Wirklichkeit ist E-Mail eine Kette aus DNS, Authentifizierung, Reputation und mehreren Programmen, die zusammenarbeiten. Sind Sie an irgendeinem Punkt unsicher, ist der Support Ihres Hostinganbieters der sicherste Weg, denn er hat den Zugriff und die Verantwortung für die Einstellungen auf dem Server.

Wo sollten Sie beim Thema Mail Transfer Agent anfangen?

Zusammengefasst ist ein MTA die Software, die Mails von Server zu Server befördert, und er bildet mit MUA, MSA und MDA eine Kette. Der MX Record zeigt den Weg, SMTP liefert die Sprache, und die Warteschlange sorgt für Ausfallsicherheit. Ein offenes Relay ist der teuerste Fehler in diesem Aufbau. Um zu entscheiden, was zu tun ist, klären Sie zuerst Ihre eigene Lage.

1. Zunächst klären Sie, wer Ihre Mails befördert: Ihr Hoster, ein E-Mail Dienst oder Ihr eigener Server.
2. Danach prüfen Sie Ihre MX, SPF, DKIM und DMARC Einträge.
3. Dann finden Sie heraus, ob Ihre Website Mails mit der PHP Funktion oder per SMTP versendet.
4. Außerdem fragen Sie Ihren Anbieter nach Relay und PTR Einstellungen.
5. Trennen Sie wichtige Mails von Marketingmails.
6. Schließlich sichern Sie eine Kopie Ihrer aktuellen DNS Einträge, bevor Sie etwas ändern.

Möchten Sie die E-Mail, Geschwindigkeit und Sicherheit Ihrer Website gemeinsam prüfen lassen, werfen Sie einen Blick auf unsere Leistung Webdesign. Unser Ratgeber zum SSL Zertifikat deckt zudem die Sicherheitsseite ab. Dieser Artikel gibt weder eine rechtliche noch eine technische Garantie. Einzelheiten lesen Sie in RFC 5321, RFC 5598, RFC 6409 und in den Richtlinien von Google für E-Mail Absender.