Kurz gesagt: Wenn der Server Spam verschickt, gibt es meist eine von drei Ursachen: ein eingeschleustes oder missbrauchtes PHP-Skript, ein Postfach mit gestohlenem Passwort oder ein falsch konfigurierter Mailserver. Sichern Sie einige der wartenden Mails, lesen Sie deren Kopfzeilen und das Mail-Log, und Sie finden in den meisten Fällen die Quelle. Danach Versand stoppen, Ursache schliessen und erst dann die Entfernung von Sperrlisten beantragen.
Wenn Kunden Ihre Rechnungen im Spam-Ordner finden
Es beginnt selten mit einer Sicherheitsmeldung. Meist melden sich Kunden, die Ihre Angebote nicht mehr erhalten, oder das Postfach füllt sich mit Rücklaufmeldungen zu Mails, die nie jemand geschrieben hat. Manchmal sperrt der Hoster den Versand und nennt als Grund auffälligen Mailverkehr.
Für das Unternehmen hat das schnell spürbare Folgen. Steht die Adresse des Servers auf einer Sperrliste, lehnen andere Mailserver auch Ihre echten Mails ab: Rechnungen, Auftragsbestätigungen, Passwort-Links aus dem Shop. Der Ruf der Domain leidet, und der Schaden wächst mit jeder Stunde, in der der Versand weiterläuft.
Spamversand gehört zu den bekannten Folgen einer Kompromittierung. Nach PHP2Shell, den Lücken CVE-2026-109618 und CVE-2026-109619 mit Codeausführung ohne Anmeldung, ist das ein Grund mehr, genauer hinzusehen. Ein spezifischer PHP2Shell-Hinweis ist Spam aber nicht; bestätigte Indicators of Compromise gibt es nicht. Weitere allgemeine Anzeichen beschreibt Bin ich schon kompromittiert?.
Drei typische Ursachen, wenn der Server Spam verschickt
| Ursache | Typisches Bild | Wo Sie nachsehen |
|---|---|---|
| Eingeschleustes PHP-Skript | Mails ohne Anmeldung, lokal über sendmail eingeliefert |
Kopfzeilen, PHP-Mail-Log, neue PHP-Dateien |
| Missbrauchtes Formular | Mails über ein Kontakt- oder Empfehlungsformular an fremde Empfänger | Zugriffslog des Formulars, Kopfzeilen |
| Gekapertes Postfach | Versand mit gültiger Anmeldung am Mailserver | Mail-Log mit Anmeldename, Anmeldeorte |
| Offener Mailserver | Fremde Absender nutzen Ihren Server als Weiterleitung | Mailserver-Konfiguration, externe Prüfung |
Die ersten beiden Ursachen betreffen die Website, die dritte die Mailkonten, die vierte die Serverkonfiguration. Die Unterscheidung ist wichtig, weil die Gegenmassnahmen völlig verschieden sind.
Die Mail-Warteschlange lesen
Auf Servern mit Postfix zeigt die Warteschlange, was gerade versendet werden soll. Die folgenden Befehle lesen nur:
# Inhalt der Warteschlange anzeigen (entspricht mailq)
postqueue -p | tail -30
# Kopfzeilen einer einzelnen Mail anzeigen (Queue-ID aus der Liste einsetzen)
sudo postcat -q -h QUEUE-ID
# Erfolgreiche Anmeldungen am Mailserver mit Benutzername
sudo grep 'sasl_username=' /var/log/mail.log | awk -F'sasl_username=' '{print $2}' | sort | uniq -c | sort -rn | head
Die Kopfzeilen verraten oft schon die Quelle. Stammt die Mail von einem angemeldeten Postfach, erscheint der Anmeldename im Mail-Log. Häuft sich dort ein einzelnes Konto mit Anmeldungen aus fremden Ländern, ist das Passwort dieses Postfachs sehr wahrscheinlich bekannt geworden. Wurde die Mail dagegen lokal eingeliefert, kommt sie meist von einem Skript auf dem Server.
Läuft auf Ihrem Server ein anderer Mailserver, etwa Exim, heissen die Befehle anders, das Prinzip bleibt gleich: Warteschlange ansehen, Kopfzeilen lesen, Anmeldungen im Log zählen. Bei Shared Hosting ohne Shell-Zugang bitten Sie den Hoster schriftlich um einen Auszug aus dem Mail-Log und um einige Beispielmails mit vollständigen Kopfzeilen. Viele Hoster liefern diese Angaben auf Nachfrage, weil sie selbst ein Interesse daran haben, den Versand zu beenden.
Sichern Sie einige vollständige Mails, bevor Sie die Warteschlange anhalten oder leeren. Sie sind Belege für die spätere Analyse und für Gespräche mit Hoster oder Sperrlisten-Betreibern.
Das verantwortliche PHP-Skript finden
Läuft der Versand über PHP, hilft die Mail-Konfiguration von PHP. Laut PHP-Handbuch protokolliert mail.log jeden Aufruf der mail()-Funktion mit vollem Skriptpfad, Zeilennummer, Empfänger und Kopfzeilen. mail.add_x_header schreibt zusätzlich eine Kopfzeile X-PHP-Originating-Script mit der Benutzerkennung und dem Dateinamen in jede Mail.
; In php.ini oder im FPM-Pool, danach alle Worker neu starten
mail.add_x_header = On
mail.log = /var/log/php/mail.log
Die Logdatei muss für den PHP-Prozess beschreibbar sein. Die Kopfzeile verrät Empfängern einen Dateinamen; schalten Sie sie nach der Analyse wieder ab, wenn Sie das nicht dauerhaft wollen.
Findet sich als Absender eine unbekannte Datei, etwa im Upload- oder Cache-Ordner, ist das ein Hinweis auf eine Webshell. Wie Sie solche Dateien einordnen, beschreibt Webshells erkennen und entfernen. Ist es dagegen ein bekanntes Kontaktformular, wurde es wahrscheinlich missbraucht, etwa weil Empfänger oder Kopfzeilen aus Formulareingaben übernommen werden. Das ist ein Fehler im Code, kein Einbruch, muss aber ebenso schnell behoben werden.
Nicht jeder Spam nutzt die mail()-Funktion. Schadcode kann auch direkt eine Verbindung zu fremden Mailservern aufbauen. Dann taucht der Versand weder in der Warteschlange noch im PHP-Mail-Log auf, wohl aber als ausgehende Verbindungen auf Port 25. Wie Sie diese prüfen, steht unter Ausgehende Verbindungen eines Servers prüfen.
Versand stoppen und sauber wieder anfahren
Ist die Quelle gefunden, folgt die Bereinigung in dieser Reihenfolge:
- Versand anhalten: Den betroffenen Weg sperren, also das Skript deaktivieren, das Postfach sperren oder die Warteschlange anhalten. Wartende Mails als Beleg sichern.
- Ursache schliessen: Bei einer Webshell PHP auf einen behobenen Stand bringen (8.5.12, 8.4.27, 8.3.36, 8.2.35 oder bestätigter Backport), alle Worker neu starten und die Website bereinigen. Bei einem Formular den Code korrigieren. Bei einem Postfach das Passwort ändern und das Gerät des Nutzers prüfen.
- Nach weiteren Spuren suchen: Wer Spam über eine Webshell versendet, hat oft weitere Hintertüren angelegt.
- Ausgang begrenzen: Ausgehende Verbindungen auf Port 25 nur für den Mailserver erlauben, nicht für den Webserver-Benutzer.
- Sperrlisten bereinigen: Erst jetzt bei den Betreibern der Sperrlisten die Entfernung beantragen und kurz beschreiben, was behoben wurde.
Prüfen Sie bei dieser Gelegenheit SPF, DKIM und DMARC Ihrer Domain. Diese DNS-Einträge legen fest, welche Server im Namen Ihrer Domain senden dürfen, und erschweren es Fremden, Ihre Absenderadresse zu missbrauchen.
Wie hilft PHP SOS konkret?
- Wir werten Warteschlange, Kopfzeilen und Mail-Logs aus und ermitteln, ob Skript, Formular, Postfach oder Konfiguration die Ursache ist.
- Wir stoppen den Versand kontrolliert und sichern Belege für Hoster und Sperrlisten.
- Wir bereinigen die Website im Rahmen der Malware-Entfernung und schliessen das Einfallstor.
- Wir begrenzen ausgehenden Mailverkehr auf Serverebene und begleiten die Entfernung von Sperrlisten.
Häufige Fragen
Woran merke ich, dass mein Server Spam verschickt?
Typisch sind Rücklaufmeldungen zu Mails, die niemand geschrieben hat, Hinweise des Hosters, eine volle Mail-Warteschlange und Kunden, die Ihre Mails plötzlich im Spam-Ordner finden. Auch Einträge Ihrer Server-Adresse auf öffentlichen Sperrlisten sind ein deutliches Zeichen.
Wie finde ich das PHP-Skript, das Spam versendet?
PHP kann jeden Aufruf der mail()-Funktion mit Skriptpfad protokollieren, wenn mail.log gesetzt ist. Mit mail.add_x_header schreibt PHP den Skriptnamen zusätzlich in den Kopf jeder Mail. In bereits versendeten oder wartenden Mails hilft ein Blick in die Kopfzeilen.
Soll ich die Mail-Warteschlange sofort leeren?
Nicht bevor Sie einige Mails als Beleg gesichert haben. Die Kopfzeilen zeigen oft, welches Skript oder welches Postfach den Versand ausgelöst hat. Anhalten ist meist besser als Löschen, bis die Quelle bekannt ist.
Wie komme ich wieder von Sperrlisten herunter?
Erst die Ursache beseitigen, dann bei den jeweiligen Betreibern der Sperrlisten die Entfernung beantragen. Die meisten verlangen eine Erklärung, was behoben wurde. Wer zu früh beantragt und weiter Spam sendet, wird erneut gelistet.