EHLO i HELO: co oznaczają w SMTP i jak wpływają na DMARC

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.

Czym są HELO i EHLO?

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:

• HELO to starsze, podstawowe powitanie SMTP.
• EHLO to nowoczesne powitanie informujące serwer odbiorczy, że nadawca obsługuje rozszerzenia ESMTP, i pozwalające negocjować funkcje takie jak STARTTLS, AUTH, SIZE i inne.

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.

Gdzie EHLO/HELO pasuje w ścieżce dostarczania e-maila

EHLO/HELO pomaga zobrazować kolejność zdarzeń w typowym procesie dostarczania SMTP:

1. Serwer nadawczy łączy się z serwerem odbiorczym.
2. Serwer nadawczy wysyła EHLO (lub HELO, jeśli nie obsługuje ESMTP).
3. Serwer odbiorczy odpowiada listą obsługiwanych rozszerzeń SMTP.
4. Nadawca przesyła nagłówki i treść wiadomości.
5. Odbiorca ocenia uwierzytelnienie (SPF, DKIM, DMARC) oraz inne sygnały.

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:

• ocenie legalności połączenia i podstawowej higieny infrastruktury,
• budowaniu reputacji adresów IP (stabilne EHLO sprzyja spójności),
• wykrywaniu źle skonfigurowanej lub podejrzanej infrastruktury.

Czy EHLO/HELO ma związek ze SPF i DMARC?

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 może sprawdzać tożsamość HELO

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.

Nieprawidłowe EHLO/HELO może pogorszyć dostarczalność nawet przy poprawnym 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:

• nazwa HELO to localhost lub nazwa wewnętrzna,
• nazwa HELO to adres IP lub losowy ciąg znaków,
• nazwa HELO nie rozwiązuje się w DNS,
• nazwa HELO nie pasuje do oczekiwanego wzorca reverse DNS.

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.

Jak wygląda „dobra” konfiguracja EHLO/HELO

Poprawna konfiguracja EHLO/HELO jest nudna, spójna i łatwa do zweryfikowania. Idealnie spełnia następujące zasady:

• Używa w pełni kwalifikowanej nazwy domenowej (FQDN) jako EHLO/HELO (np. mail.twojadomena.pl lub smtp.twojadomena.pl).
• Rozwiązuje się w DNS (istnieje rekord A lub AAAA).
• Jest zgodna z reverse DNS (adres IP ma rekord PTR wskazujący na hostname, który rozwiązuje się z powrotem na ten IP).
• Pozostaje stabilna w całej infrastrukturze wysyłkowej.

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ęstsze problemy z EHLO/HELO i sposoby ich rozwiązania

1) HELO to „localhost” lub nazwa wewnętrzna

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.

2) Domena HELO nie rozwiązuje się w DNS

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.

3) Niezgodność reverse DNS (PTR)

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.

4) Współdzielona infrastruktura i dostawcy zewnętrzni

W przypadku ESP, CRM czy systemów płatności zwykle nie masz kontroli nad EHLO. Kluczowe jest wtedy poprawne SPF, DKIM i DMARC.

5) Brak związku między HELO a MAIL FROM

Nie zawsze jest to błąd, ale przy ogólnej niespójności może zwiększać podejrzliwość.

Jak sprawdzić EHLO/HELO w praktyce

• analiza logów MTA,
• przegląd nagłówków testowych wiadomości,
• połączenie telnet lub openssl z serwerem SMTP.

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.

EHLO/HELO a wymagania dla nadawców masowych

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.

EHLO/HELO a DMARCeye

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:

• identyfikować serwery wysyłające pocztę w imieniu Twojej domeny,
• wcześnie wykrywać błędnie skonfigurowane lub nieoczekiwane źródła,
• łączyć błędy SPF, DKIM i alignmentu z konkretną infrastrukturą,
• śledzić poprawę po wprowadzonych zmianach.

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.