SMTP Test Results for

SMTP tester methodology

This check opens a connection to the submitted SMTP host and port, records the banner where available, and checks the selected transport mode. Credential fields are only useful when the backend explicitly performs SMTP AUTH; otherwise treat the result as a connectivity and STARTTLS signal, not a mailbox login audit.

What is checked

  • TCP connectivity confirms whether the SMTP port is reachable from this server.
  • The banner can identify the receiving service family, but many providers intentionally hide version details.
  • STARTTLS checks indicate whether encrypted transport appears available on ports such as 587 or 25.

Network and policy caveats

  • Port 25 is commonly blocked by ISPs, cloud providers, and hosting networks to reduce spam.
  • SMTP servers may delay, tarp it, rate limit, or reject connections based on source IP reputation.
  • A provider can allow connection from one network while blocking another because of abuse history or policy.

Authentication limits

  • Do not paste production mailbox passwords unless you have verified how the backend handles SMTP AUTH for this installation.
  • A successful connection does not prove that sending mail, relay permission, or mailbox authentication will work.
  • For deliverability issues, review MX records, SPF, DKIM, DMARC, rDNS, HELO/EHLO, and blacklist status together.

The remote SMTP server may block this server path, require an allowlist, rate limit unknown sources, or reject connections based on source IP reputation. Port 25 filtering by providers is also common.

No. STARTTLS availability only indicates that encrypted transport appears available. Certificate validity, protocol policy, authentication, relay rules, and message delivery still need separate checks.

Only if the backend implementation explicitly performs SMTP AUTH. Otherwise credentials should not be treated as verified, and the result should be interpreted as connectivity, banner, and transport behavior.