Versand vieler E-Mails per PHP – Herausforderungen und Lösungen
Newsletter sind eine zentrale Methode, um mit den Besucher der Website in Kontakt zu bleiben, diese auf Neuerscheinungen hinzuweisen und insgesamt die Verbindung zu stärken. Auch andere Webanwendung können dazu führen, dass recht viele E-Mail versendet werden müssen: Beispielsweise ein Online-Shop, ein Forum, oder ein Soziales Netzwerk.
Ein paar hundert E-Mails pro Tag zu versenden stellt noch keine technische Herausforderung dar. Erfordert die Anwendung aber, dass ihr mehrere zehntausende E-Mails pro Tag versendet, ist die technische Umsetzung gar nicht mehr so einfach.
In diesem Artikel erläutere ich die Herausforderungen vor denen ihr steht und gute technische Lösungen, um das Problem zu lösen.
Warum man nicht per mail()-Befehl E-Mails senden sollte
Eine E-Mail ist in PHP schnell versendet: Man nutzt einfach den mail-Befehl und bereits wird die E-Mail vom Webserver versendet. Zu mindestens meistens.
Bei größeren Mail-Mengen kann dies aber schnell zu Problemen führen:
- Viele Webserver sind für den Versand von vielen E-Mails nicht konfiguriert. Der Server stürzt ab, blockiert neue E-Mails oder verwirft E-Mails.
- E-Mail-Spam ist eine große Herausforderung: Viele Webserver haben nicht die notwendige Konfiguration und Zertifikate, um als vertrauenswürdig eingestuft zu werden. Gerade wenn man einen Newsletter versendet, der an mehrere hundert Empfänger bei GMail / Web.de / Gmx.de etc. gesendet wird, gerät der Webserver schnell auf Spam-Listen. Die E-Mails werden dann bei vielen Empfängern gar nicht mehr zugestellt. Gerade bei Apps aus dem Finanz-Bereich, wie z.B. Bitqt App, ist das zuverlässige Zustellen von E-Mails pflicht.
- Versendete E-Mail gelten oft als nicht vertrauenswürdig. Auch wenn ihr die Domain und das E-Mail-Postfach vom selben Anbieter habt, hat der Webserver erst mal nichts mit eurer E-Mail-Adresse zu tun. Schickt der Webserver also eine E-Mail mit dem Absender [email protected], so kann dies beim Empfänger als vertrauensunwürdig aussehen, da die E-Mail nicht von eurem offiziellen E-Mail-Server versendet wurde. Oft werden solche E-Mails als Spam blockiert.
- Nicht jede E-Mail kann sofort zugestellt werden. Manchmal erfordert der Empfänger, dass die E-Mail später noch mal zugestellt werden soll (unter Anderem als Schutz vor Spam). Viele Webserver sind dort nicht optimal konfiguriert und diese Empfänger werden eure E-Mail nicht erhalten.
Viele Webhoster im Shared Webhosting Bereich haben ebenfalls Limits, wie viele E-Mails mittels dem mail()-Befehl versendet werden können. Oder die Funktion ist komplett deaktiviert.
E-Mail per SMTP versenden
Die meisten Webhoster beinhalten ebenfalls ein E-Mail-Postfach in der Form [email protected].
Zu diesem E-Mail-Postfach gehört ebenfalls ein SMTP-Server, der für den Versand von E-Mail zuständig ist. Dieser lässt sich ebenfalls mittels PHP nutzen, um über diesen speziellen E-Mail-Ausgangsserver die E-Mail zu versenden. Dazu kann ich empfehlen die Bibliothek PHPMailer zu verwenden.
Der Versand von E-Mail per SMTP ist entsprechend einfach:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
<?php use PHPMailer\PHPMailer\PHPMailer; use PHPMailer\PHPMailer\Exception; require 'vendor/autoload.php'; $mail = new PHPMailer(TRUE); $mail->Subject = 'Betreff'; $mail->Body = 'Der Inhalt eurer E-Mail'; /* SMTP parameters. */ $mail->isSMTP(); $mail->Host = 'smtp.web.de'; $mail->SMTPAuth = TRUE; $mail->SMTPSecure = 'tls'; $mail->Password = 'euer passwort'; $mail->Port = 587; //Senden der E-Mail $mail->send(); |
Achtung: Bei den meisten Anbieter ist die Anzahl an E-Mail die man versenden kann begrenzt. Das Limit kann ein stündliches Limit sein (z.B. nur 100 Email pro Stunde) oder ein Limit pro Tag (nur 500 E-Mail pro Tag). Die Limits sind je nach Webhosting-Anbieter sehr verschieden. Neben den eigenen Webserver kann man die E-Mails auch über andere Anbieter senden wie Beispielsweise von GMail. Dort existieren aber ebenfalls Limits, bei GMail lassen sich nur 500 E-Mails pro Tag versenden. Für eine Website mit vielen Usern, wie Beispielsweise Bitcoin Era, wäre so etwas keine passende Lösung.
E-Mail Bounces
Je älter eure E-Mail Liste ist, desto wahrscheinlicher existieren die E-Mail-Postfächer nicht mehr. In dem Fall, dass eine E-Mail nicht mehr zugestellt werden kann, erhält euer E-Mail-Server eine Benachrichtigung (Bounce Message), dass das Postfach von dem Empfänger nicht mehr existiert oder voll ist.
Diese Bounces darf man auf keinen Fall ignorieren. Sendet ihr weiterhin E-Mails an diese Adressen, wird dies beim Empfänger (z.B. GMail) negativ registriert und die Wahrscheinlichkeit, dass ihr als Spammer klassifiziert wird steigt.
Habt ihr in eurem Newsletter z.B. 100 tote, nicht mehr existente GMail Adressen, so registriert GMail dass ihr weiterhin regelmäßig E-Mails versucht an diese zu senden. Irgendwann kommt GMail dies zu verdächtig vor, und blockiert sämtliche E-Mails die ihr sendet.
Daher solltet ihr eure Empfänger-Liste stets aufräumen, sobald es zu einem E-Mail Bounce kommt. Ihr solltet dann keine weiteren E-Mail mehr an diesen Empfänger senden.
Spezialisierte E-Mail-Dienste nutzen
Wer das SMTP-Limit von seinem Anbieter übersteigt, dem ist zu empfehlen einen externen, spezialisierten E-Mail-Dienst zu nutzen. Dies hat diverse Vorteile:
- Der E-Mail-Dienst ist auf den Versand von zehntausenden E-Mail spezialisiert. Dass dieser abstürzt oder E-Mails löscht (weil zu viele gesendet werden), passiert nicht. Die SMTP-Server von vielen Webhosting-Anbieter haben dagegen massiv Probleme, wenn ihr auf einmal 10,000 E-Mails versenden wollt.
- Der E-Mail-Dienst ist meistens entsprechend akkreditiert bei den großen E-Mail-Postfach-Anbietern (GMail, Web.de/Gmx.de, Microsoft). Sprich, dass eure E-Mails als Spams klassifiziert werden passiert damit deutlich seltener.
- Oftmals haben die Anbieter auch spezialisierte Methoden implementiert, um tote E-Mail-Postfächer zu erkennen (über die bounce Nachrichten). Ihr müsst dann nichts mehr machen, tote Postfächer werden erkannt und zukünftig werden keine E-Mails mehr an diese gesendet.
Mailgun
Für einen Kunden, für den wir einen Newsletter mit 20,000 Empfängern versenden mussten, haben wir uns schlussendlich für Mailgun entschieden. Die Konfiguration war einfach, man bekommt einfach neue SMTP-Daten die man im PHP-Script verwenden kann. Die Abrechnung erfolgt pro gesendete E-Mail. Aktuell zahlt man $0,80 pro 1000 Emails.
Der Preis pro E-Mail ist bei Mailgun ist etwas höher als bei Amazon Web Services (AWS), ein großer Vorteil für dieses Projekt war das automatische Handling von bouncing E-Mails: E-Mails die an nicht mehr existente Postfächer gehen, gehen automatisch zurück an Mailgun. Mailgun passt dafür die ausgehenden E-Mail automatisch an, so dass diese Fehlermeldungen an Mailgun gesendet werden. Diese E-Mail-Adressen kommen auf eine Blacklist und es werden keine weiteren E-Mail versendet. Das spart Kosten und man läuft nicht Gefahr, als Spammer klassifiziert zu werden.
Amazon SES
Ein weiter, großer Anbieter ist Amazon SES. Technisch war die Einrichtung etwas aufwendig als bei Mailgun, aber dennoch machbar. SES überzeugt durch besonders günstigen E-Mail-Versand: Nur $0,10 pro 1000 E-Mails.
E-Mail bounces werden allerdings nicht automatisch bearbeitet und geblockt: Dies müsste man selber implementieren und in der Anwendung umsetzen. Ebenfalls ist SES im Handling etwas aufwendiger als Mailgun und eher auf sehr große Enterprise-Kunden ausgelegt, die Millionen von E-Mails pro Monat versenden.
Sendgrid
Der letzte große Anbieter ist sendgrid. Da dieser aber ein fixes Abo-Modell hat ($15 / Monat für 40,000 E-Mails), war dies für unser Projekt eher uninteressant. Sendgrid ist eher bei größeren Unternehmen beliebt, während Mailgun sich auf kleinere und mittlere Unternehmen spezialisiert hat.
Autor: Nils Reimers