Common SMTP Errors and How to Fix Them

When an SMTP send fails, the server returns a reply code and a message. Here are the errors that account for most cold-email sending problems and the fix for each:

The sections below walk through each category with diagnosis steps. For what the numbers themselves mean, see SMTP error codes explained.

A 535 5.7.8 reply means the server rejected your credentials. This is the single most common SMTP error when connecting a sequencer, and it is also the most misdiagnosed, because senders assume the password is wrong when the real problem is usually that the protocol itself is switched off.

Causes and fixes:

1. 1Wrong username. Use the full email address ([email protected]), not just the local part. Gmail and Microsoft both expect the full address as the login, and a bare local part fails silently.
2. 2Expired or missing app password. If the provider still allows basic auth, generate a fresh app password and paste it exactly, with no spaces. App passwords are often displayed with spaces for readability, and pasting those spaces is a frequent cause of failure.
3. 3Basic auth disabled. Microsoft has been retiring basic authentication for Exchange Online. If basic auth is off, you must use OAuth (XOAUTH2). See Microsoft 365 SMTP settings for the OAuth flow.
4. 4Account not licensed for SMTP. Confirm the mailbox has SMTP AUTH enabled at the tenant and per-user level. On Microsoft 365 both layers must allow it; one switched off blocks the send regardless of the other.
5. 5MFA without an app password. If the account has multi-factor auth, a normal password will not work over SMTP; you need an app password or OAuth.

Worked example: you paste your Microsoft 365 mailbox address and password into a sequencer, it works in Outlook on the web, but the connection test returns 535 5.7.8 SmtpClientAuthentication is disabled for the mailbox. The diagnostic text is doing you a favor here: it is telling you the credentials are fine and the protocol is off. An administrator enables Authenticated SMTP on that mailbox, you wait for the change to propagate, and the same credentials now work.

Diagnosis: if the same credentials work in webmail but fail over SMTP, the problem is almost always disabled basic auth or a missing app password, not a typo. Read the diagnostic string after the code; it frequently names the exact cause.

A timeout means your client opened a connection that never completed; a refusal means the port is closed or blocked. Both point to a network or port problem rather than credentials. The distinction matters: a refusal comes back quickly because something actively rejected the connection, while a timeout hangs for many seconds because packets are being silently dropped by a firewall that does not bother to reply.

Causes and fixes:

• Outbound port 25 blocked. Most ISPs and cloud hosts block port 25. Switch to 587 or 465. This is covered in depth in SMTP ports explained.
• Wrong host or port. Double-check the SMTP host and port against the provider docs. A trailing space or a typo in the host name produces a resolution failure that looks like a timeout.
• Firewall rule. A local or cloud firewall may block outbound submission ports. Allow outbound 587 and 465.
• DNS resolution failure. If the host name will not resolve, the connection cannot start. Verify the host resolves with a DNS lookup before blaming the port.
• IPv6 reachability. If the host resolves to an IPv6 address your network cannot route, the connection stalls. Forcing IPv4 sometimes clears a phantom timeout.

Diagnosis: try connecting on 587 and 465 from the same machine. If 587 times out but 465 works, a network rule is selectively blocking one submission port. If both fail but the host resolves fine in DNS, the network blocks all outbound submission and you need a different network or a fallback port like 2525. If the host does not resolve at all, fix the host name first; no port change will help.

TLS errors stop the connection from being secured, which providers treat as fatal for authenticated submission. The most common mistake is a mismatch between the port and the encryption mode.

The rule: implicit TLS pairs with port 465, STARTTLS pairs with port 587. Never disable certificate verification to make an error go away; that exposes credentials. If you self-host, the certificate and TLS config are your responsibility, as detailed in self-hosted email server.

A 550 5.7.1 relay-denied error means the server refused to forward your message because it does not consider you authorized to send to that recipient. This is an authorization problem, not a credential one.

Causes and fixes:

1. 1Not authenticated. You connected without logging in. The server only relays for authenticated users. Provide valid SMTP AUTH credentials.
2. 2Sending from a domain the relay does not own. Some relays only accept mail from domains verified in the account. Verify your sending domain with the provider.
3. 3Recipient outside allowed scope. A relay configured for internal-only delivery will reject external recipients. Use a submission endpoint meant for outbound mail.
4. 4SPF or alignment failure on a strict relay. If the From domain is not authorized, the relay may refuse. Confirm SPF lists the sending host.

Diagnosis: if authenticated mail to your own domain works but external recipients are denied, the relay scope is the issue. The difference between a relay and a full server is explained in SMTP relay vs SMTP server.

A 421 reply with a throttling message means you are sending faster than the provider allows, or you have hit a daily cap. The connection is temporarily deferred, not permanently failed.

Causes and fixes:

• Daily send cap exceeded. Google Workspace and Microsoft 365 enforce per-mailbox daily limits. Stay under them; see email sending limits for Google and Microsoft.
• Burst too fast. Even under the daily cap, sending hundreds of messages in a minute triggers throttling. Add delays between sends.
• New mailbox sending too much. A fresh mailbox has a low reputation and tighter limits. Warm it up gradually with the cold email warmup guide.
• Reputation-based throttling. If your domain or IP reputation has dropped, the receiver may slow you down. Check it in Google Postmaster Tools.

Diagnosis: a 4xx code is temporary, so a well-behaved sender retries with backoff. Persistent 421 across mailboxes signals a reputation problem, not a config one. Volume planning is covered in the cold email sending volume limits guide.

A 550 5.1.1 error means the recipient address does not exist. A high rate of these (a high hard-bounce rate) damages your sender reputation quickly and is a top reason cold campaigns get throttled or blocked.

Causes and fixes:

1. 1Stale or unverified list. Validate addresses before sending. Remove role accounts and obvious typos.
2. 2Catch-all confusion. Some domains accept then bounce later; verification tools that detect catch-alls reduce surprises.
3. 3Scraped data. Lists built from scraping have high invalid rates. Clean aggressively.

Keep your hard-bounce rate low. Benchmarks and targets are in cold email bounce rate benchmarks. A sudden spike in 5xx recipient errors often means a bad import; pause and re-verify before continuing.

Random setting changes waste time and can make things worse. Work an SMTP failure in a fixed order so you isolate the layer that is actually broken.

The value of the ladder is that each rung rules out everything below it. If the TLS handshake completes, the port and DNS are fine, so stop checking them. If authentication succeeds but the message is refused with 550 5.7.1, the problem is authorization or relay scope, not your password. Most people skip straight to step four and change their password repeatedly when the failure is actually at step two or three. A failure at step six is special: the send technically succeeded, the server returned 250, and yet the message landed in spam or vanished. That is not an error you fix with SMTP settings at all, which is the subject of the next section.

Some failures are not configuration bugs; they are reputation signals. If authenticated, correctly configured mail still gets deferred, blocked, or filtered, look beyond SMTP settings.

Investigate in this order:

1. 1Blacklists. Check your domain and IP with check domain blacklisted, and if listed, follow the email blacklist removal guide.
2. 2Authentication alignment. Confirm SPF, DKIM, and DMARC all pass and align.
3. 3Reputation trend. Review domain reputation vs IP reputation and your Postmaster Tools dashboard.
4. 4Content and spam triggers. Review why cold emails go to spam.

This is where managed infrastructure earns its keep. InboxKit runs InfraGuard, which checks blacklists every six hours, watches your DNS, and auto-pauses sending when something breaks, so a silent misconfiguration does not quietly tank a campaign. Automatic SPF, DKIM, and DMARC setup also removes the most common source of authentication errors before they happen.