Webshop-Bestellungen per Mail bestätigen

Der Mailversand über den Webserver – ein trivialer Akt? Dem Webshop Mailversand wird meist keine Achtung geschenkt. Erst wenn es zu Ausfällen kommt und die E-Mails den Empfänger nicht erreichen, kommt es zu Aufschreien und Ratlosigkeit. Nebensächlich ist das Thema dann doch nicht, denn wenn Kunden keine Bestellbestätigung per Mail erhalten tritt Verwirrung und Unsicherheit auf. Der Kunde bestellt ein zweites oder drittes Mal – nichts passiert. Der Transaktionsstatus bleibt unbekannt.

Top 9 Gründe, weshalb Ihre Mails nicht ankommen

1. Return-Path nicht richtig gesetzt

Jedes Mail hat zwei Absender, einerseits das "From" das auch im Mailclient angezeigt wird und andererseits den "Return-Path" der sich im Mailheader befindet.

Der "Return-Path" – auch Envelope Sender oder Envelope From genannt – wird, wenn er nicht explizit gesetzt wird, vom lokalen MTA nach dem Schema "user@hostname" gesetzt. Im besten Fall ist das dann so etwas wie www-data@www.toscom.at, im schlechtesten Fall www-data@ip-172-310-25-61.eu-central-1.compute.internal. Der Letztere hat das Problem, dass es sich dabei um keinen auflösbaren Hostnamen handelt, solche müssen aber per RFC 2821 Sektion 3.6 verwendet werden.

2. PTR Record

Der PTR Record, auch als Reverse Lookup bekannt, enthält verdächtige Zeichenketten.

Der PTR-Record ist ein DNS Eintrag der für die Auflösung einer IP-Adresse in einen Namen zuständig ist. Beim Mail gibt es keinen Standard der vorschreibt wie es auszusehen hat, weshalb keine konkreten Aussagen darüber getroffen werden, wie die Empfänger das handhaben.

Namen im PTR die so aussehen als wären sie automatisch generiert, also z.B.: die IP-Adresse ist in irgendeiner Form enthalten oder Wörter wie adsl, dynamic oder ähnliches sind enthalten, haben in der Regel schlechte Karten.

Beispiele:

static.88-198-348-267.clients.your-server.de

213-225-334-78.nat.highway.a1.net

3. FCRDNS

Bei "Forward-confirmed reverse DNS" geht es vereinfacht gesagt darum, dass der Forward und der Reverse Lookup zusammenpassen. Es gibt zwar keinen zwingenden Standard, der das vorschreibt sondern nur ein paar RFCs die das als "Best Practice" empfehlen, doch leider gibt es Mailanbieter und Spamfilterhersteller, die trotzdem aus diesem Grund blocken.

4. SPF

Die Webserver-IP wurde nicht im SPF-Record berücksichtigt.

SPF ist ein Mechanismus mit dem im DNS hinterlegt werden kann welche Server für eine Domain Mails verschicken dürfen. Wenn der Webshop am Webserver eigenständig Mails (also nicht über den eigentlichen Mailserver) verschickt muss bedacht werden, dass ein eventuell bestehender SPF oder SenderID-Record um die IP des Webservers ergänzt werden muss.

5. DNSBL (RBL)

Die IP-Adresse befindet sich auf einer Blacklist. Es kann passieren, dass man mit einem neuen Server eine IP mit einem Blackliststatus vom Vorbesitzer übernimmt.

Dies kann z.B.: mit https://www.rbls.org/, https://mxtoolbox.com/blacklists.aspx oder https://multirbl.valli.org/ überprüft werden. Nicht jede Blacklist ist hier ernst zu nehmen.

6. IP Reputation

Größere Anbieter führen Buch darüber ob sie schon mal von einer IP legitime Mails oder Spam bekommen haben. Bei manchen ist es schon verdächtig, wenn noch nie ein Mail gekommen ist.

Da kommt man dann oft nicht darum herum den Support des Mailproviders zu bemühen, um manuell gewhitelisted zu werden. Leider gibt es bei diesen Reputationslisten in den allermeisten Fällen keine Möglichkeit den Status abzufragen.

7. Mail direkt aus der Applikation und Mailserver ist down

Werden die Mails aus der Applikation nicht an den lokalen MTA übergeben, sondern direkt an einen externen Mailserver oder eine API kann das zu Problemen führen. Wenn der externe Mailserver nicht erreichbar ist, gehen in den meisten Fällen die Mails verloren, da ein Queueing Mechanismus fehlt. Also am besten den lokalen MTA verwenden.

8. Greylisting – Mailzustellung verzögert sich

Unter der Annahme das Spambots kein zweites Mal vorbeikommen, liefert Greylisting bei der ersten Verbindung einen temporären Fehler. Bei neuerlicher Verbindung kommt man dann für bestimmte Zeit auf eine Whitelist.

Greylisting kann auch conditional eingesetzt werden, d.h. wenn es keinen SPF Record gibt, das FCRDNS nicht passt oder der Spamfilter einen Score größer als X liefert.

9. Throttling – Mailzustellung verzögert sich

Viele Mailserver drosseln die Anzahl der eingehenden Verbindungen, und manche Hoster drosseln auch die ausgehenden Verbindungen.

Amazon z.B.: drosselt ausgehende Verbindungen auf Port 25. Wenn also die EC2 Instanz direkt Mails verschickt, kann sich bei einem größeren Aufkommen ein Rückstau bilden.

toscom – Ihr Partner mit der Lösung

Um einen reibungslosen Webshop Mailversand sicherzustellen, kümmern wir uns um die Anforderungen, die große Mailprovider an Mailserver stellen – egal ob sie Standards entsprechen oder nicht. Wir überwachen die Reputation der IP-Adressen der Server, die wir für den Versand verwenden und helfen durch den Dschungel von SPF, SenderID, DKIM, DMARC, DANE und dergleichen.

Sollte der Webserver irgendwann eine Schwachstelle aufweisen, die für den Versand von Spams ausgenützt werden könnten, erkennen wir das bereits im Vorfeld durch unsere eingesetzte Technologie. Bevor ein Schaden entsteht, können wir so das Problem beheben.