Warum ein SPF-Eintrag auch für den HELO/EHLO-Hostname sinnvoll ist

vhostserver

Wenn es um E-Mail-Zustellbarkeit geht, denken die meisten Administratoren bei SPF (Sender Policy Framework) ausschließlich an die Absenderdomain im „MAIL FROM“ bzw. „Return-Path“. Das ist korrekt – aber nicht vollständig.

Ein oft übersehener Punkt: Auch der HELO/EHLO-Hostname eines sendenden Mailservers kann (und sollte) einen SPF-Eintrag besitzen.

Was ist der HELO/EHLO überhaupt?

Beim Aufbau einer SMTP-Verbindung stellt sich der sendende Server mit einem HELO- oder EHLO-Befehl vor:

EHLO mail.example.com

Dieser Hostname ist nicht zwingend identisch mit der Absenderdomain. In vielen Setups handelt es sich um den tatsächlichen Servernamen, z. B.:

EHLO vhostserver.hostinganbieter.tld

Wie Spamfilter den HELO auswerten

Moderne Spamfilter wie SpamAssassin bewerten nicht nur SPF für die Absenderdomain, sondern auch für den HELO-Hostname. Dabei greifen u. a. folgende Prüfungen:

  • SPF_HELO_NONE
    → Kein SPF-Eintrag für den HELO-Host vorhanden
  • SPF_HELO_PASS / FAIL
    → SPF-Prüfung für den HELO-Host erfolgreich oder fehlgeschlagen

Fehlt ein SPF-Eintrag für den HELO-Host, wird dies typischerweise mit einem negativen Score bewertet. Dieser ist oft nicht hoch genug, um allein Spam auszulösen – aber in Kombination mit anderen Faktoren kann er den Ausschlag geben.

Warum das überhaupt eine Rolle spielt

Der HELO-Hostname wird insbesondere dann relevant, wenn:

  • die eigentliche SPF-Prüfung (MAIL FROM) nicht eindeutig ist
  • mehrere Domains oder dynamische Absender verwendet werden
  • automatisierte Systeme (z. B. Webserver, Cronjobs, WordPress) Mails versenden
  • Spamfilter zusätzliche Signale zur Bewertung heranziehen

In solchen Fällen dient der HELO-Hostname als Fallback-Identität des sendenden Systems.

Fehlt hier eine saubere Konfiguration, wirkt das aus Sicht eines Spamfilters wie ein unvollständig oder unsauber eingerichteter Mailserver – ein typisches Merkmal vieler Spamquellen.

Typisches Problem in der Praxis

Gerade bei Hosting-Umgebungen tritt häufig folgendes Szenario auf:

  • Webserver versenden Mails (z. B. via PHP, PHPMailer, WordPress)
  • Der Server meldet sich per EHLO mit seinem Hostnamen (z. B. vhostserver.provider.tld)
  • Für diesen Hostnamen existiert:
    • zwar ein A/AAAA-Record
    • ggf. auch ein PTR-Record
    • aber kein SPF-Record

Das Ergebnis: Spamfilter vergeben unnötige Minuspunkte.

Best Practice: SPF auch für HELO setzen

Auch wenn es kein „Muss“ im engeren Sinne ist, gehört es heute zu einer sauberen Mailserver-Konfiguration:

  1. Konsistenter Hostname
    • HELO/EHLO-Name sollte ein gültiger FQDN sein
    • sollte mit dem PTR (Reverse DNS) übereinstimmen
  2. Forward DNS
    • A/AAAA-Record muss existieren
  3. SPF-Record für den Hostnamen

Beispiel:

vhostserver.provider.tld. IN TXT "v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 -all"

Damit wird klar signalisiert:
Dieser Host ist berechtigt, Mails von seiner eigenen IP zu versenden.

Was bringt das konkret?

  • Vermeidung von SpamAssassin-Regeln wie SPF_HELO_NONE
  • Bessere Gesamtbewertung der Mail
  • Sauberer technischer Eindruck beim empfangenden System
  • Reduzierung von False Positives

Fazit

SPF wird häufig nur auf die Absenderdomain reduziert. In der Praxis betrachten Spamfilter jedoch mehrere Ebenen der Identität eines Mailservers – dazu gehört auch der HELO/EHLO-Hostname.

Ein SPF-Eintrag für diesen Host ist kein zwingender Standard, aber ein einfach umzusetzendes Detail mit messbarem Effekt auf die Zustellbarkeit.

Oder anders gesagt:
Wenn man ohnehin Wert auf saubere Mailkonfiguration legt, sollte man diesen Punkt nicht auslassen.