When you see outgoing email rejected by SMTP server, the problem may sit between your mail app, the relay service, and the sender identity. A rejection does not always mean the recipient blocked the message. Your own provider may refuse it before delivery begins.
SMTP, or Simple Mail Transfer Protocol, submits outgoing messages. An SMTP relay accepts mail from an approved user or application, then sends it onward. This guide checks relay authorization, sender identity, mailbox permissions, rate limits, and configuration mismatches.
First, identify where the SMTP server rejects outgoing email
Start with the exact error text. Do not rely on a short notification such as “message not sent.” Open the mail client’s detailed status, the application log, or the bounce message. Record the timestamp, sender address, recipient domain, SMTP hostname, port, and numeric response code.
If outgoing email rejected by SMTP server appears across multiple devices, begin with the account or relay rather than one mail client.
The response code narrows the search. A 4xx response usually indicates a temporary condition, such as throttling or a service problem. A 5xx response usually indicates a permanent rejection, such as invalid credentials, an unauthorized sender, or a policy violation. The wording matters more than the number alone.
- Connection failure: The client cannot reach the configured SMTP service.
- Authentication failure: The relay does not accept the supplied credentials or method.
- Authorization failure: Login succeeds, but the account cannot relay or use the selected sender.
- Policy rejection: The provider blocks the message because of identity, volume, content, or account rules.
Compare one failed message with a known-good message, if one exists. Also note whether every user fails or only one mailbox. That distinction separates a service-wide problem from an account-specific setting.
Check relay authorization before changing DNS
A relay normally requires proof that the sender may submit mail. That proof may use a username and password, an application password, an IP allowlist, or a certificate. The provider’s requirements depend on the service and account type.
Confirm the configured SMTP hostname first. A mailbox provider may use a different server for submission than for incoming mail. An IMAP hostname can retrieve messages but cannot accept outgoing mail. Do not assume one domain name provides both services.
Next, verify the port and encryption mode as a matched set. Common submission designs use authenticated SMTP with encryption, but the exact port and TLS behavior vary. The right port with the wrong encryption mode can produce confusing errors.
- Check the provider’s documented SMTP submission hostname.
- Confirm the required port and encryption setting.
- Verify that SMTP authentication is enabled.
- Use the full mailbox address when the provider requires it.
- Confirm that the account may submit through that service.
Do not repeatedly guess passwords. Multiple failed attempts may trigger a temporary security lock or extend a block. When credentials recently changed, update the mail client, phone, scanner, website, and other applications that use the same account.
For a deeper comparison of credentials, authentication methods, ports, and account controls, see this guide to SMTP authentication failures in an email client.
Verify sender identity and address alignment
Authentication answers “who is submitting this message?” Sender authorization answers “which address may that account use?” Those answers do not always match. A user may log in as alex@example.com while the application tries to send as invoices@example.com.
Many relays reject that mismatch. Others accept the message but rewrite the sender or place it under a review policy. Check every sender field, including the visible From address, envelope sender, Reply-To address, and application-specific sender setting.
The envelope sender carries delivery notices and bounces. It may not appear as the visible From address. A website or scanner can therefore appear to use the correct address while submitting a different envelope identity.
Common identity mismatches
- A mailbox authenticates, but the From address belongs to another mailbox.
- An alias exists for receiving mail but lacks permission to send.
- An application uses an old domain after a business name or domain change.
- A hosted service submits with a local address that the relay does not recognize.
- The Reply-To address is confused with the authenticated sender.
Try the authenticated mailbox as the visible sender. A successful test shows that the relay path probably works, while the delegated sender identity needs review. Restore the intended sender only after confirming explicit Send As or Send on Behalf permission.
Review mailbox permissions and delegation
Permission problems often look like authentication problems because both can generate SMTP rejection messages. A valid login proves that the account exists. It does not prove that the account may send for a shared mailbox, alias, group, or department address.
Ask the mail administrator to verify the relevant permission in the provider’s administration console. Look for names such as “Send As,” “Send on Behalf,” delegated sending, or application access. Exact labels differ between platforms.
Check whether the sender is a real mailbox, alias, distribution address, or automated identity. These objects may have different sending rules. A distribution group might accept incoming messages but reject authenticated outbound submissions.
Permission changes may take time to reach all services. Retry after the administrator confirms the change. Avoid repeated permission edits without recording the original state. A clear before-and-after record helps if the change creates a second problem.
Automated systems deserve separate attention. A printer, website, accounting package, or FreePBX installation may use a mailbox that was never intended for interactive sending. For voicemail workflows, review the guide to reliable FreePBX voicemail-to-email settings.
Look for rate limits and account policy blocks
A relay can reject valid credentials when an account exceeds a sending limit. Limits may apply to message count, recipient count, connection frequency, attachment size, or concurrent submissions. Providers may return a temporary 4xx response, a permanent policy response, or a less descriptive error.
Establish the scope before changing the application. Ask whether normal one-recipient messages work. Then send a small message from the same account and device. Small tests that work while batches fail point toward volume, recipient count, or attachment size.
- Record the number of messages sent before the failure.
- Check whether several devices use the same mailbox.
- Review scheduled jobs that may send repeated notifications.
- Look for sudden activity that the account owner did not authorize.
- Check the provider’s account alerts and administrative logs.
Do not bypass a limit by creating several unmonitored accounts. That can hide an application defect or an account compromise. Pause nonessential automated sending, secure the account, and identify the source of the volume.
When the message reached the recipient’s mail system but later failed, that is a different investigation. Use this SMTP bounce guide for recipient-server rejections to separate those cases.
Find configuration mismatches across devices and applications
One successful device does not prove that every sender works correctly. Businesses often have several SMTP clients: desktop mail, mobile devices, scanners, websites, CRM systems, and server-side scripts. One stale setting can create a recurring failure.
Create a short inventory. For each sender, record the SMTP hostname, port, encryption mode, login identity, visible sender, envelope sender, and sending purpose. Never place passwords in a shared document. Store credentials in the approved password manager or application secret store.
Compare the failing sender with a working sender. Pay particular attention to:
- Old SMTP hostnames left after a provider migration.
- Port numbers that use a different TLS mode.
- Saved passwords that no longer match the mailbox.
- Sender addresses copied from an old domain.
- Applications that require an app password or modern authentication.
- Server clocks that are badly incorrect and disrupt encrypted sessions.
For server-side applications, inspect the application’s own log and the mail relay log when available. A web form may report only “mail failed,” while the relay records the real reason. Include timestamps and message identifiers when asking a provider for help.
Use a controlled test sequence for outgoing email rejected by SMTP server
Change one variable at a time. Begin with a single plain-text message from the affected account to an address you control. Use the authenticated account as the From address and avoid attachments. This reduces unrelated variables.
- Send from the same account through the normal client.
- Compare results from a second approved client.
- Try the intended delegated sender after permission review.
- Send a normal message, then a small attachment if needed.
- Repeat after documenting the exact response and timestamp.
When both clients fail, focus on the account, relay, policy, or provider service. A failure in only one client points toward its configuration. Interactive mail that works while a website fails points toward the website’s SMTP library, secret storage, sender fields, or outbound network access.
If the same symptom appears across approved clients, treat outgoing email rejected by SMTP server as a relay or account investigation rather than a single-device repair.
Authentication records still matter for delivery. Google’s Email Sender Guidelines explain current expectations around authenticated sending and sender practices. Meeting those guidelines will not fix a local permission error, but it helps prevent later delivery problems.
When to escalate the SMTP rejection
Escalate when the response remains unclear, the account may be compromised, or several business systems depend on the relay. Provide the provider with the exact SMTP code, full response text, timestamp with time zone, authenticated username, sender address, recipient domain, and message ID. Remove passwords and private message content.
Ask a mail administrator to confirm relay authorization, sender delegation, rate-limit status, account security events, and service health. Avoid deleting queues or repeatedly changing DNS unless evidence points there. DNS records can affect later delivery, but they usually do not explain a relay rejecting an authenticated submission immediately.
Tech Rescue Ops LLC can help trace the submission path across mail clients, applications, hosted mail, Linux servers, and network controls. Professional remote assistance is appropriate when the issue affects multiple senders, involves delegated permissions, or requires safe review of server and provider logs.