Email Bouncing Back? What the Error Means and How to Fix It

An email bounce means the receiving system did not accept the message for delivery, or delivery could not be completed. The bounce notice—often called a delivery-status notification or undeliverable message—usually contains the best clue. Read its technical code and explanation before trying to resend.

Read the error before retrying

Look for a status code such as 550 5.1.1 and the server's plain-language explanation. As a rule of thumb, a 4xx response is temporary and a 5xx response is a permanent failure for that attempt. The exact enhanced status code and accompanying text matter; do not diagnose the problem from the first digit alone.

Common bounce messages

• 5.1.1 or “user unknown” / “address not found”: the mailbox may not exist, or the address may contain a typo. Confirm the exact address with the recipient.
• 5.2.2 or “mailbox full”: the recipient's mailbox may be over its storage limit. The recipient or their administrator usually needs to resolve it.
• “Message too large” or a size-limit error: the message or attachments exceed the receiving system's limit. Reduce the file size or share it through a secure file-sharing service.
• 5.7.1 or “message rejected” / “blocked”: the receiving server refused the message under a policy, filtering, or reputation rule. Read the full text to determine what it rejected.
• 5.7.26 from Gmail or an authentication-related notice: the message may have failed sender-authentication requirements. This commonly needs attention from the owner of a custom sending domain or the email service provider.
• “Domain not found” or a name-resolution error: the domain after the @ may be misspelled or may not resolve correctly. Verify it before resending.
• 4xx or “try again later”: the server may be busy, temporarily unavailable, or delaying delivery. The sending server may retry automatically.

These examples are guides, not a universal codebook. Providers can use different wording, and the full bounce notice takes precedence over a generic description.

Fixes to try, in order

1. Check the address character by character. Look for a misspelled domain, extra space, missing character, or outdated autocomplete suggestion. If needed, type the address manually.
2. Confirm the address with the recipient. Use another channel if possible. A work address may have changed or the mailbox may have been closed.
3. Reduce the message size if that is the reported cause. Remove large attachments or share a file using a reputable service. Before sending a cloud link, check that the recipient has permission to open it. For sensitive files, grant access only to the intended people.
4. For temporary errors, wait for the retry. Many mail systems retry delivery automatically. If the notice says delivery is still being attempted, avoid sending repeated copies immediately. If the provider reports an outage, check its service-status page.
5. For a full mailbox, contact the recipient. They may need to free space or ask their administrator for help. Repeatedly resending the same message will not free their mailbox.
6. Do not keep retrying an unchanged permanent failure. Correct the address or message, or contact the recipient's administrator or your email provider if the reason is unclear.

If the server blocked your message

A rejection such as 5.7.1 can have several causes. Try to identify which one the notice names before changing your setup.

• Send one simple test only when useful. A short plain-text message without links or attachments can help determine whether the original content or file was involved. If the test is also rejected, check the server response instead of repeatedly sending more tests. If messages are accepted but land in spam, see how to improve email delivery and avoid spam filters.
• Check account security if there are signs of misuse. If contacts report spam from you or you see unfamiliar sent messages, change your password from a trusted device, enable two-step verification, and review recent activity and forwarding rules. Follow this guide if you suspect your email account was hacked.
• Read any remediation link in the bounce. Some providers explain how to request a review or resolve a policy block. Verify that the link belongs to the provider before opening it.
• Ask the recipient's administrator when appropriate. For workplace email, the recipient's organization may be able to explain a policy rejection. Adding you to a safe-senders list may help in some systems, but it will not fix every block.

If you send from your own domain

Check the domain's SPF, DKIM, and DMARC setup, especially if the bounce mentions authentication. Make sure every legitimate service that sends on your behalf is configured according to its provider's instructions. Do not add arbitrary DNS values or create multiple SPF records in an attempt to fix a failure.

DNS-checking tools can help confirm whether records are published, and blocklist tools can show whether an IP or domain is listed. Treat a listing as a clue rather than the full diagnosis: the receiving server's rejection text and your mail host's logs are more directly relevant. Fix the cause before requesting delisting.

If you receive bounces for messages you never sent

This can happen when someone forges your address as the sender of spam, a practice often called spoofing or backscatter. It does not by itself prove that your account was hacked.

• Check your Sent folder and recent account activity for messages you do not recognize.
• If you find signs of unauthorized access, change your password, enable two-step verification, and review forwarding rules and recovery details.
• If there is no evidence of account access, avoid responding to suspicious bounce messages or opening unexpected attachments. If you manage the domain, ask your email administrator about SPF, DKIM, and DMARC configuration to help reduce spoofing.

When to contact support

• The address is correct, but the bounce says the sending server or IP is blocked.
• Messages to one provider consistently fail while messages to others work.
• The notice mentions authentication or DNS and you do not manage those settings.
• The error remains unclear after checking the full notice and the provider's documentation.

Send your email provider or IT administrator the complete bounce notice, including the technical lines, date and time, and recipient domain. Redact passwords, private message content, and other sensitive information that is not needed for diagnosis. If you also cannot send or receive other messages, use this step-by-step guide to Gmail sending and receiving problems to check for a broader account or service issue.

Bottom line

Start with the bounce code and the server's explanation. Correct an invalid address, reduce an oversized message, wait for temporary failures, and investigate authentication or policy details when a server blocks you. For permanent errors, do not keep resending the same message unchanged. The full bounce notice is usually the most useful information to share with support.