An SMTP timeout means the website waited too long for a network or server response. It is different from an authentication rejection: WordPress may not have reached the SMTP login stage at all.
Record where the connection stops before changing passwords, encryption and ports at random.
Capture the timeout precisely
Run one controlled SMTP test and note the timestamp, destination hostname, port, encryption mode and time elapsed before failure. Retain the redacted error text.
Messages such as connection timed out, operation timed out or could not connect point to routing, DNS, firewall or an unavailable service. An explicit 535 response means the connection worked and authentication failed instead.
Do not enable verbose mail debugging on a public page; it can reveal credentials and server details.
Confirm the destination resolves
From an authorised server terminal or hosting diagnostic, resolve the SMTP hostname. Check that it returns the provider’s expected address and not an old local server or private address.
If the domain recently migrated, review local DNS resolvers and /etc/hosts only with server-administration approval. A website domain’s MX record is not necessarily the hostname WordPress should use for authenticated SMTP.
Use the mail provider’s documented hostname rather than guessing mail.example.com.
Test the exact outbound port
Check whether the hosting server can open a TCP connection to the selected hostname and port. The test should have a short timeout and must not include a password.
For example, an administrator can use OpenSSL to inspect a provider that documents STARTTLS on port 587:
openssl s_client -starttls smtp -connect smtp.example.net:587 -servername smtp.example.netA successful TLS handshake does not authenticate the mailbox, but it proves more of the network path. Replace the example host only with the provider’s official value.
Review cPanel mail restrictions
Shared hosts may restrict external SMTP, reserve ports for their own relay or apply "SMTP Restrictions" through the server firewall. A reseller or cPanel account may not have permission to change these policies.
Check cPanel email deliverability and mail-routing information, but ask the hosting provider about outbound connections when the remote test never opens. Supply the timestamp, destination and port.
Do not disable the server firewall globally or whitelist every remote address.
Separate local and remote mail routing
If the website sends through a mailbox hosted on the same cPanel server, confirm the domain’s Email Routing setting matches reality. Local, backup and remote exchanger modes affect how the server handles domain mail.
A domain whose mailbox lives in Microsoft 365 or Google Workspace should not accidentally be treated as local. Conversely, an external SMTP provider normally uses its authenticated hostname regardless of local MX.
Change routing only after checking the authoritative mail design, because an incorrect setting can break inbound company email.
Check IPv4, IPv6 and TLS behaviour
A hostname may publish IPv6 even when the server’s IPv6 route is incomplete. Compare connection evidence for the resolved addresses and ask the host to repair routing or follow the provider’s supported configuration.
Verify server time, certificate hostname and CA trust. Do not disable certificate verification to hide a TLS problem.
Use the correct pairing: providers commonly document port 587 with STARTTLS or port 465 with implicit TLS.
Inspect load and PHP time limits
A saturated cPanel account can delay DNS, PHP and outbound connections. Review CPU, memory, process, I/O and entry-process limits around the failed form submission.
If SMTP runs synchronously, the browser may time out while WordPress still attempts delivery. Confirm whether an entry or message was already created before the visitor retries.
Moving supported notifications to a reliable background queue can protect the response, but the underlying connection still needs repair.
Verify the real form end to end
After the hosting or configuration correction, test the provider connection once, then submit the actual form with a unique reference. Confirm entry creation, mail generation, provider acceptance and final mailbox arrival.
Check Reply-To and sender authentication. Review stored entries from the outage window so missed leads are handled.
Request urgent repair when the host blocks the required port, local routing is uncertain or timeouts create duplicate submissions. Share redacted errors and timestamps—never SMTP passwords or customer messages.