Troubleshoot SMTP authentication from connection to provider handoff.

Confirm the SMTP host, port, and encryption

Use the host shown for the EmailDesk SMTP service. Port 587 expects STARTTLS, while port 465 expects SSL/TLS from the start when those listener ports are configured.

A connection timeout usually points to DNS resolution, a firewall, an ISP or hosting-provider restriction, the wrong port, or an unavailable listener. Certificate-name errors often mean the client is using the wrong host name.

• Do not disable certificate verification to bypass a TLS error.
• Do not send credentials over an unencrypted connection.
• Check outbound firewall rules from the actual application or server, not only from a workstation.

Use the correct SMTP relay credential

EmailDesk SMTP relay credentials are created for authenticated submission and synchronized to the relay authentication service. They are separate from mailbox credentials and cannot be used to open IMAP or POP.

Check the complete username, the current one-time secret, credential status, customer workspace, and any domain or exact-address restriction. Rotate a credential if it may have been exposed, then update the protected application setting.

• Keep the secret in a server-side environment or protected credential store.
• Do not place it in browser code, analytics, screenshots, support tickets, or source control.
• A rotated or disabled credential makes an old password fail even if the username is unchanged.

Check the From identity and domain

The exact From address must be verified in EmailDesk and allowed by the SMTP credential. The active gateway's SPF include must also be present in the domain's single SPF policy.

Use the business or website address in From. For a contact form, place the visitor address in Reply-To when supported; do not impersonate a public mailbox provider in From.

• Confirm the MIME From and envelope sender are appropriate for the authorized domain.
• Recheck SPF after DNS propagation.
• Use the provider-issued DKIM selector and aligned DMARC as part of production readiness.

Separate authentication from submission policy

SMTP AUTH can succeed and the message can still be stopped before provider handoff. EmailDesk then checks sender authorization, recipients, suppressions, quotas, customer status, and gateway readiness.

Read the full SMTP response and EmailDesk Outbound History. An authentication failure, local policy block, rate limit, provider rejection, and accepted handoff require different fixes.

• Authentication failed: recheck username, secret, status, and client authentication mode.
• Sender blocked: verify the exact From identity, credential scope, and sender domain.
• SPF blocked: keep one SPF record and add the selected gateway's required include.
• Suppression blocked: inspect the recorded reason before changing or retrying the message.
• Provider rejected or deferred: preserve the provider response and address the specific upstream evidence.

Run one controlled test and preserve evidence

Send a small plain-text message to a recipient the organization controls. Record the timestamp, source system, From and destination domains, SMTP response, and EmailDesk history row without copying credentials or message contents into analytics.

If the response is accepted or queued, wait for later evidence before concluding final delivery. If the outcome is unknown, check for receipt before resubmitting.

Know when SMTP authentication is not the problem

SMTP AUTH only establishes that a client may submit under a credential. It does not make an unverified sender valid, override DNS, bypass quota, or guarantee provider acceptance.

Even after provider acceptance, recipient systems can defer, bounce, block, quarantine, or place the message in Spam/Junk. Keep the provider response and later events as separate evidence.