EHLO und HELO sind zwei kurze Befehle, die ganz am Anfang jeder SMTP-Verbindung stehen - sie können aber erheblichen Einfluss auf die Zustellbarkeit, die Spam-Filterung und die Bewertung Ihres E-Mail-Verkehrs durch Mailbox-Anbieter haben.
Wer in Logs Begriffe wie "HELO domain", "EHLO string" oder "HELO does not resolve" gesehen hat, blickt genau auf diesen Teil des E-Mail-Handshakes. Die meisten Teams bemerken das erst, wenn etwas nicht stimmt: Nachrichten landen im Spam-Ordner, ein E-Mail-Gateway lehnt eine Verbindung ab, oder ein DMARC-Projekt bringt verdächtigen Traffic in den Berichten ans Licht.
Dieser Leitfaden erklärt, was EHLO/HELO ist, wie es funktioniert, wie eine korrekte Konfiguration aussieht und wie Sie häufige Probleme beheben.
Wenn sich ein Mailserver mit einem anderen über SMTP verbindet, stellt er sich vor. Historisch geschah das mit HELO - dem ursprünglichen SMTP-Gruß. Später wurde SMTP um zusätzliche Funktionen erweitert (als ESMTP bekannt), und der Gruß wurde zu EHLO (Extended HELO).
Kurz zusammengefasst:
Der Gruß enthält einen Hostnamen (manchmal auch eine Domain). Dieser Wert wird häufig als HELO-Domain oder EHLO-Name bezeichnet. Er ist nicht identisch mit der "Von"-Domain, die Empfänger in ihrem E-Mail-Client sehen. Es handelt sich um einen Server-zu-Server-Identifier, der bei Verbindungs- und Reputationsprüfungen verwendet wird.
EHLO/HELO helfen dabei, die Reihenfolge der Ereignisse bei einer typischen SMTP-Zustellung zu verstehen:
Obwohl DMARC die Ausrichtung anhand der "Von"-Domain bewertet, nutzen viele Mailbox-Anbieter und Sicherheits-Gateways HELO/EHLO als wichtiges Signal für:
DMARC basiert nicht direkt auf EHLO/HELO. DMARC bewertet die Ausrichtung zwischen der sichtbaren "Von"-Domain und der Authentifizierung via SPF oder DKIM. HELO/EHLO kann Ihr E-Mail-Programm jedoch auf mehrere wichtige Arten beeinflussen.
SPF bewertet, ob ein Absender berechtigt ist, E-Mails für eine Domain zu versenden. Die von SPF verwendete "Domain" ist üblicherweise die MAIL FROM-Domain (Return-Path), es gibt jedoch auch das Konzept der HELO-Identität in SPF. Manche Empfänger prüfen, ob der HELO/EHLO-Name plausibel und konsistent ist - insbesondere wenn andere Signale verdächtig wirken.
Wenn Ihr Projekt die SPF-Ausrichtung für DMARC umfasst (zum Beispiel bei der Durchsetzung), werden Sie wahrscheinlich gleichzeitig auch Infrastruktur-Signale bereinigen. Dieser Prozess wird ausführlicher beschrieben in So beheben Sie DMARC-Probleme: Schritt für Schritt.
SPF, DKIM und DMARC können korrekt konfiguriert sein, und dennoch treten Zustellprobleme auf, wenn der SMTP-Gruß eindeutig falsch konfiguriert ist - zum Beispiel:
Das ist besonders relevant für Massenversender, bei denen die Inbox-Platzierung im Vordergrund steht. Falls die Zustellbarkeit Priorität hat, finden Sie in E-Mail-Zustellbarkeit mit DMARC verbessern eine umfassende Checkliste, die Authentifizierung und grundlegende Sender-Reputation verbindet.
Ein korrekter SMTP-Gruß ist unspektakulär, konsistent und überprüfbar. Eine gute Konfiguration folgt typischerweise diesen Regeln:
mail.ihredomain.de oder smtp.ihredomain.de).Wenn Sie DMARC zum ersten Mal einrichten und gleichzeitig die Versandinfrastruktur bereinigen, finden Sie die schrittweise DNS-Arbeit hier: Vollständiger DMARC-Implementierungsleitfaden.
Das passiert häufig bei selbst verwalteten MTAs, Appliances oder Legacy-Systemen. Es signalisiert dem Empfänger im besten Fall eine Fehlkonfiguration, im schlimmsten Fall eine bewusste Verschleierung der Identität.
Lösung: Konfigurieren Sie Ihren MTA so, dass er einen öffentlichen FQDN verwendet. Zum Beispiel:
myhostname und prüfen Sie, ob dieser Wert für SMTP-Grüße verwendet wird.primary_hostname an.Viele Gateways prüfen, ob der HELO-Name auflösbar ist. Selbst wenn keine harte Ablehnung erfolgt, kann das das Vertrauen verringern und die Filterrate erhöhen.
Lösung: Veröffentlichen Sie einen A/AAAA-Record für den im Gruß verwendeten Hostnamen. Halten Sie es einfach. Wenn Sie DNS nicht selbst verwalten, ist das eine schnelle Anfrage an Ihre DNS-Administratoren.
Massenversender stoßen häufig auf Probleme, wenn die sendende IP keinen PTR-Record hat oder der PTR auf etwas Unzusammenhängendes zeigt. Manche Anbieter und Spam-Filter werten einen fehlenden oder abweichenden Reverse-DNS-Eintrag als Zeichen minderwertiger Infrastruktur.
Lösung: Setzen Sie einen PTR-Record für Ihre sendende IP, der auf einen Hostnamen unter Ihrer Kontrolle zeigt (häufig eine Subdomain wie mail.ihredomain.de), und stellen Sie sicher, dass der Hostname wieder auf die IP auflöst.
Wenn Sie einen ESP, ein CRM, ein Ticketsystem oder einen Zahlungsanbieter nutzen, haben Sie möglicherweise keinen Einfluss auf deren SMTP-Gruß. Das ist grundsätzlich kein Problem. Das praktische Ziel besteht darin sicherzustellen, dass Authentifizierung und Ausrichtung korrekt sind und dass der Anbieter eine zuverlässige, stabile Infrastruktur einsetzt.
Lösung: Behandeln Sie die Anbieter-Einbindung als strukturierten Prozess: Validieren Sie zuerst SPF-, DKIM- und DMARC-Ausrichtung, und prüfen Sie dann unterstützende Signale wie Reverse DNS, wenn Sie Zustellprobleme beobachten.
Das ist nicht automatisch falsch. Viele Systeme verwenden für SMTP-Grüße einen anderen Hostnamen als die Return-Path-Domain. Wirkt jedoch alles inkonsistent, können Anbieter das als verdächtig einstufen - besonders in Kombination mit anderen Problemen (hohe Beschwerdequoten, geringe Interaktion oder Authentifizierungsfehler).
Lösung: Priorisieren Sie Korrektheit und Stabilität. Nicht jeder Identifier muss übereinstimmen, aber jeder sollte bewusst und korrekt konfiguriert wirken.
Je nach gewünschtem Detailgrad stehen Ihnen einige praktische Optionen zur Verfügung:
Wenn Sie mitten in DMARC-Arbeiten stecken und wiederholte Authentifizierungsfehler sehen, ist es oft sinnvoll, diese zuerst zu beheben und danach sekundäre Signale wie die HELO-Konsistenz zu bereinigen. Der Fehlerbehebungs-Workflow wird in So beheben Sie DMARC-Probleme: Schritt für Schritt beschrieben.
Google und Yahoo haben die Messlatte für Massenversender angehoben. Während ihre veröffentlichten Anforderungen auf Authentifizierung (SPF, DKIM, DMARC) und Nutzersignale (Beschwerden, Abmelde-Unterstützung) fokussieren, hängt die tatsächliche Zustellbarkeit nach wie vor von grundlegender Infrastruktur-Hygiene ab - einschließlich einer konsistenten, zuverlässigen SMTP-Identität.
Wenn Sie Zustellungsfehler im Zusammenhang mit Compliance-Anforderungen oder unklare Bounce-Meldungen analysieren, ist dieser Leitfaden eine hilfreiche Ergänzung: E-Mail-Compliance für Google und Yahoo: Fehlermeldungen verstehen und beheben.
DMARCeye hilft Organisationen dabei zu verstehen, wie Low-Level-SMTP-Signale wie EHLO und HELO mit realen Authentifizierungs- und Zustellungsergebnissen zusammenhängen. EHLO/HELO wird zwar nicht direkt von DMARC bewertet, aber Probleme auf der SMTP-Verbindungsebene zeigen sich indirekt durch Authentifizierungsfehler, unerwartete Absenderquellen oder auffällige Traffic-Muster.
Durch die Analyse von DMARC-Aggregatberichten und deren Korrelation mit sendenden IPs und Infrastrukturverhalten ermöglicht DMARCeye seinen Nutzern:
Wenn EHLO/HELO-Konfigurationsprobleme in der eigenen Infrastruktur bestehen, treten sie häufig gemeinsam mit anderen Problemen auf - etwa fehlendem Reverse DNS, instabilen Versand-Hosts oder unvollständiger Authentifizierungsausrichtung. DMARCeye liefert die nötige Transparenz, um Korrekturen zu priorisieren und zu überprüfen, ob die vorgenommenen Änderungen zu messbaren Verbesserungen bei Authentifizierungserfolg und Zustellbarkeit führen.
Starten Sie jetzt Ihren kostenlosen Test von DMARCeye und schützen Sie Ihre E-Mail-Domain.