EHLO i HELO to dwa krótkie polecenia, które pojawiają się na samym początku rozmowy SMTP, ale mogą mieć nieproporcjonalnie duży wpływ na dostarczalność wiadomości, filtrowanie spamu oraz na to, jak dostawcy skrzynek pocztowych interpretują wiarygodność Twojego strumienia e-mail.
Jeśli kiedykolwiek widziałeś w logach wpisy takie jak „HELO domain”, „EHLO string” albo „HELO does not resolve”, to właśnie ten etap nawiązywania połączenia SMTP. Większość zespołów zwraca na niego uwagę dopiero wtedy, gdy coś przestaje działać: wiadomości zaczynają trafiać do spamu, brama e-mailowa odrzuca połączenie albo raporty DMARC ujawniają podejrzany ruch.
Ten przewodnik wyjaśnia, czym jest EHLO/HELO, jak działa, jak wygląda poprawna konfiguracja oraz jak rozwiązywać najczęstsze problemy.
Gdy jeden serwer pocztowy łączy się z innym za pomocą SMTP, na początku się przedstawia. Historycznie służyło do tego polecenie HELO (oryginalne powitanie SMTP). Później SMTP zostało rozszerzone o dodatkowe możliwości (ESMTP), a powitanie zmieniło się na EHLO (Extended HELO).
W skrócie:
Powitanie zawiera nazwę hosta (czasem domenę). Ta wartość bywa określana jako domena HELO lub nazwa EHLO. Nie jest to ta sama domena, którą użytkownik widzi w polu „From” w kliencie poczty. Jest to identyfikator serwer–serwer wykorzystywany podczas zestawiania połączenia i oceny reputacji.
EHLO/HELO pomaga zobrazować kolejność zdarzeń w typowym procesie dostarczania SMTP:
Choć DMARC ocenia wyrównanie (alignment) na podstawie domeny w polu „From”, wielu dostawców skrzynek pocztowych i bram bezpieczeństwa wykorzystuje EHLO/HELO jako istotny sygnał przy:
Bezpośrednio nie. DMARC nie jest „oparty” na EHLO/HELO. DMARC sprawdza wyrównanie pomiędzy domeną widoczną w polu „From” a uwierzytelnieniem SPF lub DKIM. Mimo to EHLO/HELO może wpływać na Twój program e-mailowy na kilka istotnych sposobów.
SPF ocenia, czy nadawca jest uprawniony do wysyłania poczty w imieniu danej domeny. Najczęściej sprawdzana jest domena MAIL FROM (Return-Path), ale w SPF istnieje również pojęcie HELO identity. Część odbiorców bierze pod uwagę, czy nazwa EHLO/HELO jest sensowna i spójna, zwłaszcza gdy inne sygnały wyglądają podejrzanie.
Jeśli w ramach wdrażania DMARC porządkujesz również SPF (np. podczas przechodzenia do egzekwowania polityki), zazwyczaj równolegle porządkujesz sygnały infrastrukturalne. Ten proces opisujemy dokładniej w artykule Jak rozwiązywać i naprawiać problemy z DMARC.
Możesz mieć poprawnie skonfigurowane SPF, DKIM i DMARC, a mimo to obserwować problemy z dostarczaniem, jeśli powitanie SMTP jest wyraźnie źle skonfigurowane, na przykład gdy:
Ma to szczególne znaczenie dla nadawców o dużym wolumenie wysyłki. Jeśli dostarczalność jest dla Ciebie priorytetem, zobacz również Lepsza dostarczalność wiadomości e-mail dzięki DMARC.
Poprawna konfiguracja EHLO/HELO jest nudna, spójna i łatwa do zweryfikowania. Idealnie spełnia następujące zasady:
mail.twojadomena.pl lub smtp.twojadomena.pl).Jeśli wdrażasz DMARC po raz pierwszy i jednocześnie porządkujesz infrastrukturę nadawczą, szczegółowe kroki DNS opisujemy w Kompletnym przewodniku wdrażania DMARC.
Najczęściej spotykane w samodzielnie zarządzanych MTA, urządzeniach lub starszych systemach. Dla odbiorcy jest to sygnał złej konfiguracji lub ukrywania tożsamości.
Rozwiązanie: skonfiguruj MTA tak, aby używał publicznego FQDN.
Wiele bram stosuje kontrolę „HELO must resolve”. Nawet bez twardego odrzucenia obniża to zaufanie.
Rozwiązanie: opublikuj rekord A/AAAA dla używanego hosta.
Brak PTR lub PTR wskazujący na niepowiązaną nazwę jest często traktowany jako sygnał niskiej jakości infrastruktury.
Rozwiązanie: ustaw rekord PTR wskazujący na host, który kontrolujesz.
W przypadku ESP, CRM czy systemów płatności zwykle nie masz kontroli nad EHLO. Kluczowe jest wtedy poprawne SPF, DKIM i DMARC.
Nie zawsze jest to błąd, ale przy ogólnej niespójności może zwiększać podejrzliwość.
Jeśli pracujesz nad DMARC i widzisz powtarzające się błędy uwierzytelnienia, warto najpierw je rozwiązać, a dopiero potem porządkować sygnały pomocnicze. Opisuje to Jak rozwiązywać i naprawiać problemy z DMARC.
Google i Yahoo podniosły wymagania dla nadawców masowych. Oprócz SPF, DKIM i DMARC liczy się również jakość infrastruktury i spójna tożsamość SMTP.
W kontekście problemów zgodności pomocny będzie także Przewodnik po nowych błędach i wymaganiach Google oraz Yahoo.
DMARCeye pomaga zrozumieć, jak niskopoziomowe sygnały SMTP, takie jak EHLO i HELO, przekładają się na rzeczywiste wyniki uwierzytelnienia i dostarczalności.
Analiza raportów zbiorczych DMARC pozwala:
Gdy problemy z EHLO/HELO występują w infrastrukturze własnej, często towarzyszą im inne błędy, takie jak brak reverse DNS czy niestabilne hosty wysyłkowe. DMARCeye zapewnia widoczność potrzebną do ustalania priorytetów i potwierdzania realnych efektów zmian.
Zarejestruj się na bezpłatny okres próbny DMARCeye i zabezpiecz swoją domenę e-mail.