Einen Mailserver einrichten, der nicht im Spam landet

"Wir haben Postfix aufgesetzt, und unsere Mails landen im Spam" ist ein Satz, den ich oft höre, und die Lösung liegt fast nie in der Postfix-Konfiguration. Mailserver, Postfix, Exim, was auch immer man wählt, sind der einfache Teil, das sind seit Jahrzehnten gelöste Probleme. Was tatsächlich entscheidet, ob eine E-Mail im Posteingang oder im Spam-Ordner landet, ist eine Kombination aus DNS-Records, die beweisen, dass man berechtigt ist, für die eigene Domain Mails zu versenden, und eine Sende-Reputation, die sich über Zeit aufbaut, oder eben nicht.

SPF: wer darf als man selbst senden

SPF (Sender Policy Framework) ist ein DNS-TXT-Record, der festlegt, welche Server berechtigt sind, Mails im Namen der eigenen Domain zu versenden:

example.com.  TXT  "v=spf1 ip4:203.0.113.10 -all"

Das bedeutet: Mail von example.com sollte nur von 203.0.113.10 kommen, und -all bedeutet, dass alles andere von empfangenden Servern direkt abgelehnt werden sollte. Der häufigste SPF-Fehler ist nicht ein fehlender Record, sondern ein zu großzügiger SPF-Record (~all überall, oder Einträge für Dienste, die längst nicht mehr genutzt werden), oder, genauso schlimm, ein Record, der so streng ist, dass er legitime Mails von einem Weiterleitungsdienst blockiert, den niemand mehr auf dem Schirm hatte.

DKIM: belegen, dass die Nachricht unverändert ist

DKIM (DomainKeys Identified Mail) signiert ausgehende Nachrichten mit einem privaten Schlüssel und veröffentlicht den passenden öffentlichen Schlüssel im DNS, damit empfangende Server prüfen können, dass die Signatur auf dem Weg nicht manipuliert wurde:

mail._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

Die meiste Mailserver-Software (zum Beispiel OpenDKIM neben Postfix) generiert dieses Schlüsselpaar selbst, die eigentliche Arbeit besteht darin, den öffentlichen Teil korrekt zu veröffentlichen und sicherzustellen, dass ausgehende Mails tatsächlich signiert werden, was sich lohnt, direkt zu prüfen statt einfach anzunehmen:

echo "test" | mail -s "DKIM-Test" [email protected]

und dann in den Headern der empfangenen Nachricht nach dkim=pass zu schauen.

DMARC: den Empfängern sagen, was bei einem Fehlschlag passieren soll

DMARC verbindet SPF und DKIM und sagt empfangenden Servern, was mit Mails passieren soll, die bei beiden durchfallen, und wohin Berichte darüber gehen sollen:

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

Mit p=quarantine zu starten (Fehlschläge gehen in den Spam statt komplett abgelehnt zu werden) statt mit p=reject ist der sicherere Rollout, besonders in den ersten Wochen, weil man dadurch Sichtbarkeit auf alles bekommt, was falsch konfiguriert ist, ohne dass diese Mails einfach verschwinden. Die rua-Berichte sind hier wirklich nützlich, sie zeigen genau, welche Quellen Mails im Namen der eigenen Domain versenden und ob sie durchkommen.

PTR-Records: der eine DNS-Eintrag, den nicht man selbst kontrolliert, aber der Provider

Ein PTR-Record (Reverse DNS) bildet die IP-Adresse des Servers zurück auf einen Hostnamen ab, und viele empfangende Mailserver prüfen, ob dieser mit dem Hostnamen übereinstimmt, den der eigene Server in der SMTP-Begrüßung angibt. Anders als die übrigen Records wird dieser vom Hosting-Provider gesetzt, nicht in der eigenen DNS-Zone, die meisten VPS-Anbieter haben dafür eine Option im Control Panel oder ein Support-Ticket für Reverse-DNS auf einer IP. Wenn ein Server Mails als mail.example.com versendet, der PTR-Record der IP aber auf etwas wie vps-1234.providername.com zeigt, reicht diese Diskrepanz allein, um von manchen Filtern markiert zu werden.

Der Teil, den DNS-Records nicht reparieren können: Reputation

Selbst wenn SPF, DKIM, DMARC und PTR alle korrekt sind, hat eine brandneue IP-Adresse, die Mails versendet, keine Historie, und manche Empfänger behandeln unbekannte Absender vorsichtiger, unabhängig davon, wie korrekt sie konfiguriert sind. Hier kommt das "Warmlaufen" ins Spiel: mit geringem Volumen an Adressen anfangen, bei denen man sich sicher ist, dass die Mail tatsächlich gelesen wird (und nicht als Spam markiert), und das Volumen schrittweise erhöhen, statt von einem Server, der gestern null Mails versendet hat, gleich Tausende zu schicken. Ein neuer Mailserver mit perfektem DNS und null Sendehistorie profitiert trotzdem von einem langsamen Start, Reputation baut sich über Tage und Wochen auf, nicht in einer Konfigurationsdatei.

Die vier Records korrekt setzen, mit einem Tool wie mail-tester.com prüfen, dass Mails tatsächlich signiert werden und korrekt aligned sind, und einer neuen Sende-IP Zeit geben, sich eine Reputation aufzubauen, bevor man sich für irgendetwas Zeitkritisches darauf verlässt. Diese Kombination deckt die große Mehrheit der "warum landet unsere Mail im Spam"-Fälle ab, von denen fast keiner an der Mailserver-Software selbst liegt.