Email bounce messages decoded (550, 554, relaying denied)

Most bounce codes point to one of three things: the recipient's mailbox rejected you (bad address, full mailbox, spam filter), your own domain's DNS is missing an authentication record, or you're trying to send through a server that isn't yours. Check the exact wording in the bounce, match it below, and you'll usually know the fix in under a minute.

Bounces arrive as a "non-delivery report" (NDR) back to the sender, with a numeric code and a text reason. The code tells you the category. The text after it is where the real answer usually lives, so read the whole message, not just the number.

550: mailbox unavailable

550 is the most common permanent-failure code. It almost always means one of these:

• No such user. The address doesn't exist on the receiving server. Check for typos. This is the sender's problem to fix, not yours, unless you're the one receiving and rejecting.
• Mailbox full. The recipient's quota is maxed out. If this is your own account bouncing incoming mail, see increasing email storage quotas for how to raise the limit or free up space.
• Blocked by spam filter or blocklist. Some receiving servers use 550 for "we don't trust this sender" rather than "this address doesn't exist." The bounce text usually says something like "blocked" or references a blocklist name. If your domain is missing SPF or DKIM, this is often why. Check whether your domain's mail authentication is set up correctly; hosted domains on Flashcloud get SPF and DKIM configured automatically, but DMARC is not automatic and some receiving servers are strict about it.

If you're the one getting bounced with a 550, the fix depends on which sub-case it is: confirm the address, wait if it's a full mailbox and ask the recipient to clear space or raise their quota, or check your own domain's authentication records if it looks like a filtering block.

554: transaction failed

554 is a catch-all "something went wrong and we're not accepting this message" code. Common triggers:

• Content flagged as spam. The message tripped a spam filter on the receiving end. This can happen even from a legitimate sender if the subject line, links, or attachments look spammy, or if the sending domain has a poor reputation.
• Sender reputation problem. If you're sending high volumes or your domain/IP has been flagged by a blocklist, receiving servers may reject outright with 554. Missing DKIM signing is a frequent contributor here, since unsigned mail is easier to spoof and gets treated with more suspicion.
• Policy rejection. Some servers use 554 when a message fails a DMARC check on the receiving side, even though the sending domain's own DMARC record isn't required to exist.

There's no single fix for 554 because it's a generic "rejected" code. Read the full bounce text, since most servers append a reason. If a pattern of 554 bounces is showing up across many recipients, that points to a sending reputation issue rather than a one-off problem with a single address.

"Relaying denied" and 5.7.1 errors

"Relaying denied," "relay access denied," or a 5.7.1 code means the mail server refused to send your message on to its destination because it doesn't recognize you as authorized to send through it. This is different from a normal bounce: it happens at send time, not because the recipient's server rejected the message.

Typical causes:

• Wrong SMTP server or port. Your email client is pointed at a server that isn't the one for your account. For Flashcloud-hosted mailboxes, outgoing mail should go through mail.yourdomain.com on port 465 (SSL) or 587 (STARTTLS), using the full email address as the username, not just the local part.
• Authentication not completing. If your client is set to send unauthenticated, or the saved password is stale after a change, the server won't relay for you. Re-enter the password and confirm the client has "SMTP requires authentication" (or equivalent) turned on.
• Sending from a network the server doesn't trust. Some client configurations only allow relaying from specific IP ranges. If you're testing from a script or a new device, confirm it's using authenticated SMTP with the correct port rather than relying on network trust.

Fix order: confirm hostname, port, and encryption type first, then confirm the username is the full email address, then re-save the password. Most "relaying denied" errors are a client misconfiguration rather than a server-side block.

Checking whether it's a filter, not a real reject

Some bounces are soft, not permanent. If a message is deferred rather than rejected outright (a 4xx code instead of 5xx), the receiving server is asking the sender to retry later, often because of a temporary rate limit or greylisting. That's normal and usually resolves itself within minutes to hours without action.

If you're troubleshooting deliverability more broadly, not just a single bounce, it helps to confirm your protocol choice first. If you're on POP3 instead of IMAP, that won't cause bounces, but it can make old messages harder to find when you're trying to compare a bounce against a previous successful send. And if you're worried about losing bounce records or historical mail while diagnosing a pattern, see backing up your email for how to keep local copies.

When to contact support

Contact support if bounces persist after you've confirmed the address is correct, the mailbox isn't full, and your SMTP settings are right. This is especially worth doing if you're seeing 554 bounces across multiple recipients (a possible reputation or blocklist issue we can help diagnose) or if "relaying denied" continues after re-entering your password and re-checking the port. Open a ticket from the portal under Support → New ticket, or use live chat. Support is real people, and they can check server-side logs for the exact rejection reason, which isn't always visible from the bounce text alone.