Căutare MX și test SMTP
Verificați serverele de e-mail ale unui domeniu și testați conexiunile SMTP, STARTTLS și open relay.
Instrumente înrudite
- Securitatea e-mailuluiVerificați SPF, DKIM, DMARC, MTA-STS, TLS-RPT și BIMI pentru un domeniu și obțineți înregistrările care le repară.
- Verificare liste negreVerificați dacă o adresă IP sau serverul de e-mail al unui domeniu este listat pe listele negre DNS.
- Căutare DNSCăutați înregistrări DNS după tip, inclusiv căutări inverse (PTR) pentru adrese IP.
- Sănătatea domeniuluiO singură verificare pentru DNS, autentificarea e-mailului, TLS, antete de securitate și redirecționări, cu o notă pe fiecare zonă și un raport complet.
Despre acest instrument
MX și SMTP citește înregistrările MX ale unui domeniu, rezolvă fiecare server de e-mail și apoi se conectează la primele trei dintre ele de pe serverul XGM, ca să vadă ce vede un server de e-mail expeditor: bannerul și extensiile EHLO pe portul 25, handshake-ul STARTTLS și certificatul din spatele lui, DNS-ul invers al adresei și dacă serverul retransmite e-mailuri pentru expeditori din exterior. Porturile 465 și 587 sunt testate la fel, inclusiv ce mecanisme AUTH sunt oferite înainte ca TLS să fie activ. Înregistrările în sine sunt judecate după regulile pe care le aplică expeditorii - ținta unui MX trebuie să fie un nume de gazdă cu o înregistrare de adresă, nu un CNAME (RFC 2181 secțiunea 10.3), iar o singură înregistrare „0 .” este MX-ul nul din RFC 7505. Sesiunea se oprește întotdeauna înainte de DATA și nu se autentifică niciodată, așa că niciun mesaj nu este trimis și nicio cutie poștală nu este sondată. Nu verifică dacă o adresă individuală există, nu citește e-mailuri și nu testează filtrarea la intrare sau scorul de spam.
XGM rezolvă înregistrările MX, apoi se conectează la cel mult trei servere de mail pe portul 25, de pe serverul său: citește bannerul, trimite EHLO, face upgrade cu STARTTLS și verifică certificatul, apoi testează releul cu un expeditor și un destinatar din exterior (domenii de exemplu din RFC 2606). Se oprește înainte de DATA, așa că niciun mesaj nu este trimis vreodată. Pe porturile 465 (TLS implicit) și 587 (STARTTLS) citește bannerul, versiunea TLS și certificatul, extensiile EHLO și mecanismele AUTH înainte și după TLS, și nu încearcă niciodată să se autentifice. Fiecare pas este cronometrat. În aceeași rulare verifică prima adresă IPv4 a fiecărui server de mail (cel mult cinci) față de cele 58 de liste de blocare pentru IP-uri ale instrumentului de blacklist; coloana Liste de blocare face legătura către rezultatul complet, iar o adresă ale cărei interogări au eșuat este afișată ca neverificată, niciodată ca nelistată.
Cum se folosește
- Deschideți instrumentul MX și SMTP.
- Introduceți domeniul public, numele de gazdă sau adresa IP pe care doriți să le verificați.
- Rulați verificarea; XGM interoghează de pe serverul său și listează constatările.
- Copiați rezultatul doar după ce ați verificat că arată corect.
- Folosiți instrumentele XGM înrudite dacă aveți nevoie de o imagine de diagnostic mai largă.
Întrebări frecvente
Ce înseamnă „Portul 25 nu a putut fi testat de pe serverul XGM”?
Apare atunci când niciun server de e-mail nu a răspuns pe portul 25, deși aceleași gazde au răspuns pe 465 sau 587. Mulți furnizori de găzduire blochează portul 25 de ieșire din rețelele lor, așa că tăcerea este cel mai probabil de partea XGM și nu spune nimic despre serverele dumneavoastră. Rezultatele de pe 465 și 587 din aceeași rulare sunt reale; confirmați portul 25 trimițând un mesaj dintr-un cont din exterior.
Testul de open relay chiar trimite un e-mail?
Nu. Emite MAIL FROM și RCPT TO cu adrese din domeniile de exemplu din RFC 2606 - xgm-relay-test@example.org către xgm-relay-test@example.net - apoi trimite RSET și încheie, așa că DATA nu este atinsă niciodată și nu există niciun corp de mesaj. Un server care acceptă acel RCPT TO cu un cod 2xx retransmite pentru un necunoscut, motiv pentru care constatarea este critică.
MX-ul meu indică un CNAME și e-mailurile ajung totuși. De ce este semnalat?
RFC 2181 secțiunea 10.3 cere ca ținta unei înregistrări MX să fie un nume de gazdă canonic, cu propriile înregistrări de adresă, nu un alias. Majoritatea expeditorilor rezolvă oricum aliasul, dar unii resping domeniul de-a dreptul, iar eșecul este intermitent și greu de urmărit. Îndreptați MX-ul către numele la care se rezolvă CNAME-ul, pe care constatarea îl arată.
Ce este un null MX și când ar trebui să public unul?
O singură înregistrare MX cu preferința 0 și ținta „.”, definită în RFC 7505, le spune expeditorilor că domeniul nu acceptă e-mail, așa că aceștia eșuează imediat în loc să țină mesajul în coadă zile întregi. Publicați-o pentru domeniile care găzduiesc doar un site sau sunt parcate. XGM o raportează ca informativă, nu ca defect.
Certificatul este raportat ca nefiind de încredere, dar e-mailurile sunt livrate. Contează?
STARTTLS oportunist (RFC 3207) criptează fără a verifica certificatul, așa că livrarea obișnuită continuă. Expeditorii care chiar verifică - MTA-STS în mod enforce sau DANE - vor refuza să livreze către acel server. Folosiți un certificat de la o CA publică ce acoperă numele de gazdă MX, care este numele verificat de expeditori.
Citiți ghidul complet Căutare MX și test SMTP (în engleză)