Einen Mailserver aufsetzen, der nicht im Spam landet

"Wir haben Postfix aufgesetzt und alle unsere E-Mails wandern direkt in den Spam" ist ein Satz, den ich ständig höre. Und die Lösung für dieses Problem findet man so gut wie nie in den Konfigurationsdateien von Postfix.

Mailserver – egal ob Postfix, Exim oder was auch immer Sie wählen – sind der unglaublich einfache Teil. Das sind Probleme, die seit buchstäblich Jahrzehnten gelöst sind. Was tatsächlich darüber entscheidet, ob eine E-Mail sicher in der Inbox landet oder aggressiv in den Spam-Ordner verbannt wird, ist eine Kombination aus DNS-Einträgen, die mathematisch beweisen, dass Sie berechtigt sind, im Namen Ihrer Domain Mails zu versenden, und einer Sender-Reputation (Reputation), die man sich über Zeit sorgfältig aufbauen muss.

SPF: Wer darf eigentlich in Ihrem Namen senden?

SPF (Sender Policy Framework) ist ein DNS-TXT-Eintrag, der strikt auflistet, welche spezifischen IP-Adressen überhaupt berechtigt sind, E-Mails zu versenden, die behaupten, von Ihrer Domain zu stammen:

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

Das besagt effektiv: E-Mails von example.com dürfen absolut nur von 203.0.113.10 kommen, und das -all teilt den empfangenden Servern mit, dass alles andere aggressiv und komplett abgelehnt (rejected) werden soll.

Der häufigste SPF-Fehler ist witzigerweise kein fehlender Eintrag. Es ist ein SPF-Eintrag, der viel zu permissiv (durchlässig) ist (überall ~all, oder er beinhaltet irgendwelche Third-Party-Services, die Sie längst nicht mehr nutzen). Oder, was genauso schlimm ist, es ist ein Eintrag, der derart restriktiv ist, dass er völlig legitime E-Mails von einem Forwarding-Service zerschießt, den jemand vergessen hat in die Liste einzutragen.

DKIM: Der Beweis, dass die Nachricht unterwegs nicht verändert wurde

DKIM (DomainKeys Identified Mail) signiert ausgehende Nachrichten kryptografisch mit einem Private Key. Der dazugehörige Public Key wird direkt im DNS veröffentlicht, sodass die empfangenden Server sofort verifizieren können, dass die Signatur (und somit die Mail) auf dem Transportweg nicht manipuliert wurde:

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

Die meisten modernen Mailserver (wie OpenDKIM, das neben Postfix läuft) generieren dieses Schlüsselpaar automatisch für Sie. Die eigentliche Arbeit besteht darin, die öffentliche Hälfte korrekt im DNS zu publizieren und zwingend zu überprüfen, ob ausgehende Mails tatsächlich signiert werden. Das ist etwas, das man absolut selbst verifizieren sollte, anstatt einfach blind zu hoffen, dass es schon funktionieren wird:

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

Schauen Sie sich danach explizit den Raw-Header der empfangenen Nachricht an und suchen Sie nach dem Eintrag dkim=pass.

DMARC: Den Empfängern sagen, was zu tun ist, falls SPF oder DKIM fehlschlagen

DMARC bindet SPF und DKIM zusammen. Es sagt empfangenden Servern explizit, was sie mit E-Mails tun sollen, die bei beiden Checks komplett durchfallen, und genau wohin sie die täglichen Berichte (Reports) darüber schicken sollen:

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

Mit p=quarantine anzufangen (was bedeutet, dass fehlgeschlagene Mails in den Spam-Ordner geschickt werden, anstatt sie sofort komplett abzuweisen) anstatt direkt mit p=reject, ist eine deutlich sicherere Rollout-Strategie – besonders in den ersten Wochen. Das gibt Ihnen sofortige Sichtbarkeit über alles, was Sie versehentlich falsch konfiguriert haben, ohne dass diese Mails einfach im Nichts verschwinden. Die rua-Berichte sind hier wirklich Gold wert; sie zeigen exakt, welche Quellen überhaupt versuchen, E-Mails in Ihrem Namen zu versenden und ob sie Ihre strengen Checks bestehen.

PTR-Records: Der eine DNS-Eintrag, den Sie nicht kontrollieren

Ein PTR-Record (Reverse DNS) bildet die IP-Adresse Ihres Servers strikt auf seinen Hostnamen ab. Eine gigantische Menge an empfangenden Mailservern prüft aktiv, ob dies perfekt mit dem Hostnamen übereinstimmt, den Ihr Server bei seiner initialen SMTP-Begrüßung (Greeting) präsentiert.

Im Gegensatz zu den anderen drei Einträgen wird dieser komplett von Ihrem Hosting-Provider kontrolliert und liegt nicht in Ihrer eigenen DNS-Zone. Die meisten VPS-Anbieter haben eine simple Option im Control-Panel oder eine eigene Support-Ticket-Kategorie, um Reverse DNS für eine IP zu setzen. Wenn Ihr Server stolz E-Mails als mail.example.com verschickt, der PTR-Eintrag seiner IP aber blind auf etwas Hässliches wie vps-1234.providername.com zurückauflöst, reicht diese Diskrepanz allein völlig aus, um sofort von aggressiven Spamfiltern geflaggt zu werden.

Das, was DNS-Einträge nicht reparieren können: Reputation

Selbst wenn SPF, DKIM, DMARC und PTR absolut makellos konfiguriert sind, hat eine nagelneue IP-Adresse einfach buchstäblich null Sende-Historie. Viele der ganz großen E-Mail-Empfänger (wie Gmail oder Microsoft) behandeln unbekannte Absender höchst vorsichtig, völlig unabhängig davon, wie technisch perfekt deren DNS eingerichtet ist.

Genau hier ist das "Aufwärmen" (Warming up) Ihrer IP so extrem wichtig. Fangen Sie mit einem sehr kleinen Volumen an Adressen an, von denen Sie absolut sicher sind, dass sie aktiv mit der E-Mail interagieren werden (sie öffnen, antworten, nicht einfach ignorieren). Steigern Sie dieses Volumen schrittweise, anstatt plötzlich tausende von Nachrichten über einen Server rauszuballern, der gestern noch exakt null gesendet hat.

Ein brandneuer Mailserver mit perfektem DNS und null Historie braucht immer noch zwingend diesen langsamen Start. Eine Sender-Reputation wird über Tage und Wochen schmerzhaft aufgebaut; sie wird nicht einfach in einer Textdatei konfiguriert.

Setzen Sie diese vier spezifischen DNS-Einträge exakt auf. Verifizieren Sie mit einem Tool wie mail-tester.com, dass die Mails tatsächlich signiert werden und das Alignment perfekt passt. Geben Sie einer brandneuen Sender-IP dann die echte Zeit, die sie braucht, um sich einen soliden Track Record aufzubauen, bevor Sie sich für irgendetwas Zeitkritisches aggressiv auf sie verlassen. Diese Kombination löst extrem zuverlässig die überwältigende Mehrheit aller "Warum gehen unsere Mails in den Spam"-Fälle. Und so gut wie keiner davon entpuppt sich am Ende als ein Fehler in der Mailserver-Software selbst.