Fixing SMTP "550 5.7.1" Errors and Gmail "Message Queued" Delays

If you are reading this, you sent an email and got bounced with a line like 550 5.7.1 in the rejection, or you are watching messages sit in Gmail with a "message queued" status that never clears. Both point to the same root issue: the receiving mail server decided your message violated a policy and either rejected it outright or throttled it.

The 550 5.7.1 code is a permanent rejection for a policy or authorization reason. The 550 is the SMTP reply code (mailbox unavailable or action refused), and the 5.7.1 is the enhanced status code meaning "delivery not authorized, message refused." A "message queued" state in Gmail is the softer cousin: Gmail accepted the message but is holding or slow-walking it, usually because of rate limits or reputation checks.

This guide breaks down every common variant of 550 5.7.1, explains the Gmail queue behavior, and walks through fixes you can apply today plus prevention that keeps it from coming back.

The bare code rarely travels alone. The text after it tells you which policy you tripped. Here are the variants you will actually see in bounce messages.

The first job is to read the full bounce, not just the number. A "relaying denied" problem is fixed in your sending configuration. An "unauthenticated email" problem is fixed in DNS. They share a code but have nothing else in common.

The classic 550 5.7.1 Relaying denied happens when you point a script or app at a mail server and ask it to deliver to an external domain without authenticating first. Per RFC 5321, a server is only obligated to accept mail for domains it hosts. To send anywhere else, you must prove you are an authorized user.

Fix it:

1. 1Confirm you are connecting to the correct submission endpoint. For Microsoft 365 that is smtp.office365.com on port 587 with STARTTLS; see our Microsoft 365 SMTP settings guide for the full table.
2. 2Enable SMTP AUTH on the mailbox and supply valid credentials (often an app password if MFA is on).
3. 3Make sure your client is using AUTH LOGIN or AUTH PLAIN over the encrypted channel, not trying to send before the handshake completes.
4. 4If you are using a relay connector or a fixed IP, confirm that IP is in the allowed list on the sending platform.

If you are unsure which port or encryption mode to use, our SMTP ports explained breakdown covers 25, 465, 587, and 2525 and when each applies.

The variant that bites cold email senders hardest is 550-5.7.1 ... This message does not have authentication information or fails to pass authentication checks. This is Gmail (and increasingly Yahoo and Microsoft) refusing mail that cannot prove who sent it.

Since the Google and Yahoo sender requirements took effect, every sending domain needs:

• A valid SPF record that authorizes your sending IP. See SPF record setup for cold email.
• A passing DKIM signature. See DKIM setup for cold email.
• A DMARC policy published in DNS, even at p=none to start. See DMARC setup for cold email.

Fix it:

1. 1Pull the failing message header and read the Authentication-Results line. It will show spf=, dkim=, and dmarc= results.
2. 2Whichever shows fail or none is your target. A softfail on SPF still gets rejected by strict gateways.
3. 3Confirm your DNS publishes all three records and that the From domain aligns with the signing domain (DMARC alignment).
4. 4Wait for DNS propagation, then send a test to a Gmail address and recheck the header.

Getting all three to pass together is the single highest-leverage fix for 550 5.7.1 on cold email. Our overview of SPF, DKIM, and DMARC explained ties the three together if you want the full picture.

A queued message is different from a bounce. Gmail accepted the SMTP transaction, returned a 250 success, then held the message internally. You will see it stuck in "Sending" or labeled queued in the API. The message has not failed, but it is not moving either.

The usual causes:

Google publishes its sending caps and throttling behavior; a single Workspace mailbox is held to a daily external recipient cap, and pushing past it triggers queueing and then hard 550 limit errors. Spreading volume across mailboxes and warming each one is the durable answer, not retrying the same overloaded mailbox.

Some 550 5.7.1 messages include a URL pointing at a blocklist, for example a Spamhaus lookup page. This means the recipient server checked your sending IP or domain against a list and found it, so it refused the message regardless of authentication.

Fix it:

1. 1Check whether your domain or IP is listed. Our check if a domain is blacklisted walkthrough shows where to look.
2. 2If listed, follow the email blacklist removal guide to request delisting and fix the underlying cause.
3. 3Stop sending from the flagged source until you understand why it was listed. Continuing to send digs the hole deeper.
4. 4Audit your list hygiene. High bounce rates and spam-trap hits are the fastest routes onto a blocklist.

Reputation blocks are the hardest variant to fix quickly because delisting takes time and the underlying behavior has to change. Prevention beats cure here by a wide margin.

When a 550 5.7.1 or stubborn Gmail queue lands, work the list in order. Each step rules out a cause before you spend time on the next.

1. 1Read the full bounce text. Identify which variant you have. Do not guess from the number alone.
2. 2Check authentication first. Pull the header, read Authentication-Results, and fix any SPF, DKIM, or DMARC failure. This resolves the largest share of cold email cases.
3. 3Confirm you are authenticating to send. Relay-denied and auth-required errors mean your client is not logging in correctly.
4. 4Check sending limits. If the mailbox is over its daily cap, no fix to DNS will help. Reduce volume and spread across mailboxes.
5. 5Check blocklists. If a URL appears, verify listing and start delisting.
6. 6Verify reputation and warmup. New domains and IPs get throttled until they earn trust.
7. 7Send a controlled test. One message to a known Gmail inbox, then read the header again to confirm the fix.

If you reach the end and messages still bounce, the problem is almost always reputation, which no single configuration change repairs overnight.

Most 550 5.7.1 incidents are preventable with the same foundation that drives good cold email deliverability overall.

• Authenticate before you send a single email. SPF, DKIM, and DMARC published and aligned, verified against a real Gmail test.
• Warm every new mailbox. Reputation is earned by consistent, engaged sending over weeks, not bought.
• Respect sending limits. Keep per-mailbox daily volume comfortably under the provider cap and grow gradually.
• Monitor for blocklist hits continuously, not just after a problem appears.
• Keep your lists clean so bounce and complaint rates stay low.

This is the operational burden that makes cold email infrastructure tedious to run by hand. InboxKit provisions real Google Workspace, Microsoft 365, and Azure mailboxes with SPF, DKIM, DMARC, and MX configured automatically through Cloudflare in under sixty seconds, then runs InfraGuard to check blacklists every six hours and auto-pause sending if reputation slips. The point is not the product, it is that the prevention checklist above is exactly what stops 550 5.7.1 from recurring, whether you automate it or do it by hand.