Receiving and sending follow different paths
Separate failure to submit, delay after acceptance and remote rejection before changing SMTP settings.
An entitled mailbox may receive while SMTP submission fails, or while accepted outbound mail stalls or is rejected later. Start with the actual provider’s SMTP endpoint, TLS mode and reply; do not assume Novasean ports or relay entitlement from a generic panel example.
Choose a harmless new test message to an address you control. Record the sender, client, time and exact error. Never paste passwords or full message bodies into a ticket.
Compare webmail with the mail client
Try the same account from provider-supported webmail, if available, and from the configured desktop or mobile client. If webmail sends but the client cannot submit, check the client’s outgoing server name, authentication identity, supported TLS mode and server certificate against the provider’s published values. Mozilla’s troubleshooting separates outgoing-server configuration from message composition problems. A password prompt or TLS warning is a local submission clue; do not disable encryption or certificate validation to get past it.
If webmail submits and the desktop client times out before submission, compare the documented SMTP endpoint and TLS mode in that client; changing MX cannot fix this observation.
If both routes fail immediately, note the SMTP reply code and whether the provider accepted the message. A connection timeout or refusal is different from an authentication error, and either differs from a message that appears in Sent. Sent-folder presence alone may be a client copy rather than proof of downstream delivery.
If SMTP replies 535, check the outgoing login and account state
If your mail client receives 535 5.7.8 Authentication credentials invalid or 535 Incorrect authentication data in reply to SMTP AUTH, the submission server rejected that login. That attempt was not accepted for delivery. The reply alone does not prove a mistyped password: a server-side authentication fault or, on some DirectAdmin configurations, a reached sending limit can also produce a generic 535. This is a different stage from a message that entered a queue or bounced at the recipient, so changing MX, SPF or the recipient address does not resolve this reply.
Compare the outgoing server name, full mailbox username where required, authentication setting and TLS mode with the settings supplied for your actual mail service. DirectAdmin’s client examples use the full email address as the SMTP username and require an outgoing password, but your provider may use a different hostname or configuration. A client can store a separate outgoing credential, so working IMAP reception does not prove its SMTP login is current. Check the saved outgoing credential without exposing it in a ticket, and try one controlled send after a verified correction. Do not turn off authentication, TLS or certificate checks to make the error disappear.
If the documented settings and authorised mailbox credential still receive 535, stop repeated guesses and ask the mail operator to check authentication logs, account-protection state and any sending limit. The sending-limit guide helps when the operator confirms a limit; do not infer a limit from 535 alone. Supply the redacted mailbox identity, endpoint, time and exact reply, never the password. Change a mailbox password only through an authorised route; the password-change guide explains the effects on connected clients. If webmail also fails, tell support that result; webmail and SMTP may use related credentials but are not the same submission test.
Find where sending stopped
If submission failed before acceptance, correct only the verified account or connection setting and retest. If the provider accepted the message but no recipient got it, ask the mail operator to check the queue and delivery log using message ID and timestamp. A deferred queue item, upstream relay rejection, rate control or destination error needs operator evidence; account users should not attempt privileged queue commands. If the exact notice says a DirectAdmin daily send limit was reached, use the sending-limit guide to distinguish a mailbox from a hosting-account counter and check for unexpected traffic. If a bounce arrived, read its actual remote code and route the issue by that code, including authentication or recipient-policy failures.
Compare more than one controlled recipient only when needed; a failure at one recipient domain may be its policy, while failure everywhere points earlier in the route. Do not keep resending identical messages into a stuck queue.
Retest and preserve the recovery path
After the identified fix, send one new message from the original client to the original controlled recipient, confirm provider acceptance and actual receipt, then inspect the message’s authentication results. Repeat from webmail only if that comparison was relevant. If the fix breaks previously working submission, restore the saved settings and ask support for the supported route.
Provide the exact error, endpoint name, time, client version and redacted message ID to support. Never send credentials. If the service is managed, server queue or relay changes belong to its operator; if it is self-managed, the authorised administrator follows their own runbook.
Common questions
Does a message in Sent prove delivery? No. Check recipient arrival or a delivery trace.
Should I change MX? MX handles incoming routing and is not the usual fix for client submission.
Can I try another SMTP port? Use only a port and TLS mode documented for your actual provider.
If webmail and the client both fail, should I copy client settings again? First capture the exact provider reply and ask the mail operator whether it accepted the submission.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.