A customer replies that they never received the invoice. Your staff sees a bounce notice, but the message is full of server codes and vague language like “rejected” or “undeliverable.” The straight answer is that email bounce diagnosis starts with the exact response from the receiving mail server. That response tells you whether the problem is the recipient, your sending setup, or a temporary condition outside either side’s control.
Do not treat every bounce as a spam problem. Some bounces are expected and cannot be fixed by the sender. Others point to a domain issue that can affect every email your business sends. The goal is to separate those cases quickly, then make the right correction instead of repeatedly resending the same message.
What an email bounce actually tells you
A bounce occurs when a receiving mail server cannot accept or deliver an email. The message may return immediately, or it may fail after the sending server retries for a period of time. The bounce notice usually includes a Simple Mail Transfer Protocol (SMTP) status code. SMTP is the standard system mail servers use to transfer email.
The first number in that code is the fastest clue. A code beginning with 4 usually means a temporary failure. A code beginning with 5 usually means a permanent failure, at least until something changes.
That distinction matters. A temporary failure may clear up when a recipient server is busy or unavailable. A permanent failure requires a correction, such as using a valid address, fixing an authentication record, or asking the recipient’s email administrator to review a policy rejection.
Still, “temporary” and “permanent” are not complete diagnoses. A 4xx code can repeat for days because of a recurring server or reputation issue. A 5xx code can be resolved when a typo is corrected or a DNS record is repaired. DNS, or Domain Name System, is the public record system that helps email servers verify where messages come from and where they should go.
Start email bounce diagnosis with the full error
Do not work from a screenshot that says only “delivery failed.” Find the original non-delivery report from your email provider or mail server. Keep the recipient address, sending address, date and time, SMTP status code, and the text supplied by the receiving server.
The text after the code often contains the real answer. For example, “user unknown” points to a recipient address problem. “SPF fail” points to an authentication problem. “Message rejected due to policy” requires more context because the policy could concern authentication, sender reputation, message content, or a restriction at the recipient’s organization.
Then ask one operational question: is this happening to one person, one company, or many unrelated recipients? That pattern narrows the cause faster than the error code alone.
One recipient usually means a recipient-side issue
If messages bounce only to one address, verify the address with the recipient through another channel. Common causes include a misspelling, a former employee’s mailbox, a full mailbox, or an address that never existed.
A 5.1.1 error commonly means the mailbox does not exist. Your exact fix is to correct or remove the address from your contact record. Do not keep retrying it. Repeated attempts will not create a mailbox and can make your sending activity look less controlled.
A business may also reject outside mail for a specific department or require senders to use an approved address. In that case, the recipient must tell you the accepted address or ask their email administrator to allow your sender.
Many recipients point back to your sending environment
If invoices, appointment notices, sales replies, or other ordinary business messages are bouncing across multiple organizations, look at your domain and mail server configuration first. A broad failure pattern is rarely caused by dozens of unrelated recipient typos.
Check whether your sending domain has valid authentication. Sender Policy Framework (SPF) is a DNS record that lists the services allowed to send email for your domain. DomainKeys Identified Mail (DKIM) adds a digital signature that lets the receiving server check that a message was authorized and was not changed in transit. Domain-based Message Authentication, Reporting, and Conformance (DMARC) tells receiving servers how to handle mail that fails alignment checks involving SPF and DKIM.
A missing, outdated, or conflicting SPF record can cause rejection, particularly when staff send through more than one platform. A broken DKIM signature can appear after a mail system change, a domain migration, or an incorrect record update. A DMARC policy can expose these problems because it checks whether the visible From address aligns with authenticated sending.
The exact fix depends on the service that sent the bounced message. Confirm the sending platform, then verify that platform is included in SPF and signing with the correct DKIM configuration. Do not add records based on a guess. An incorrect SPF change can authorize the wrong sender or cause valid services to fail.
Read common bounce patterns in plain language
Some bounce messages are clear. Others need a little interpretation.
A “mailbox unavailable” or “user unknown” response is normally an address cleanup issue. A “domain not found” response can mean the recipient domain is misspelled or no longer exists. If the recipient’s domain has no valid Mail Exchanger (MX) record, the MX record that tells senders where to deliver email, their email administrator must correct it.
An “authentication required” or “SPF/DKIM/DMARC failure” response means the receiving organization could not verify your message as an authorized use of your domain. Check the authentication records and the source of the message. This is especially common when a website form, customer relationship system, copier, or billing tool sends using your business address without being properly configured.
A “connection refused,” “timeout,” or “try again later” response usually signals a temporary routing or capacity issue. Your email system should retry automatically. If the same failure continues, check whether your outbound server can connect to the recipient server and whether your sending internet address has a poor reputation.
A “blocked,” “policy rejection,” or “message rejected” response needs more care. It may be related to authentication, an internet address listed on a blocklist, unusual sending volume, malformed message headers, or content that resembles a threat. The server’s full text is essential here. Do not assume it is a content issue just because the message was rejected.
Check the sending domain before changing the message
When a bounce references policy, trust, or authentication, teams often rewrite the email first. That may be useful later, but it is not the first move. A plain invoice email can still fail if the domain lacks valid technical signals.
Start with the domain records, the sending server identity, and the public reputation of the sending internet address. Also check reverse DNS, which connects a sending internet address back to a domain name. Many receiving servers expect that relationship to be valid and consistent.
For businesses that send operational mail, make sure every source is accounted for. Your main mailbox provider may be configured correctly while a scheduling system or website still sends from an unverified source. The bounce will only affect messages from that one system, which can make the issue look random.
Brand Indicators for Message Identification (BIMI) is not required to stop most bounces, but it depends on a strong authenticated domain and can support recognizable branding in participating inboxes. Mail Transfer Agent Strict Transport Security (MTA-STS) helps specify secure transport expectations between mail servers. TLS Reporting (TLS-RPT) provides reports about Transport Layer Security delivery problems. These records are useful for domain health, but they do not replace SPF, DKIM, and DMARC.
Avoid the fixes that create more confusion
Do not resend a permanently bounced message over and over. Do not change several DNS records at once without documenting what changed. And do not rely on a single successful test sent to your own personal address as proof that every recipient organization will accept your mail.
Instead, keep a short record of the bounce code, affected system, affected recipients, and corrective action. If a problem returns, that record shows whether you have a new issue or an incomplete fix.
A bounce is not always a warning that your domain is unhealthy. But it is always a useful signal. One invalid address needs contact cleanup. A pattern of policy or authentication rejections deserves a domain-level review before routine business communication is affected.
For a clear starting point, run MailArrive’s free email health check and review the Report Card. It grades the domain signals that commonly contribute to delivery failures and explains the exact fix in plain language.