You send a quotation, an invoice or a confirmation, and an automated notification arrives instead of a reply. This delivery failure notification, often called a bounce, describes a problem encountered along the email’s route. To decide what to do next, identify the affected recipient, the delivery status and the technical explanation rather than relying on the notification’s subject line.
1. Identify the message and the affected recipient
The notification may come from an address such as MAILER-DAEMON or postmaster. Its subject might announce a delivery failure, but it could also report a delay. Do not assume that every address on the original message was affected: an email sent to several people may reach some recipients and be rejected for others.
Look for the following fields in the report. Their presentation can vary, and some notifications include only a selection:
- Final-Recipient: the recipient address to which the reported problem applies.
- Original-Recipient: the original address, where available; it may differ after forwarding or address rewriting.
- Action: the reported outcome, such as failed or delayed.
- Status: the enhanced status code, such as 5.1.1.
- Diagnostic-Code: the technical response from the server involved.
Compare the affected address with the address actually used when sending. An unfamiliar address could be the destination of a forwarding rule. Also check whether you genuinely sent the message mentioned in the report. An unexpected notification may result from someone forging your sender address, or it may itself be deceptive. Do not automatically open attachments or enter your password through links in the notification.
2. Read SMTP codes alongside the explanation
A report may include both three-digit SMTP codes and enhanced status codes made up of three groups separated by dots. These are different fields, even when they describe the same problem.
Temporary problems: class 4
An SMTP response in the 4xx class, or an enhanced code starting with 4, generally indicates a temporary condition. Possible causes include a temporarily unavailable server, sending rate limits or a temporary policy check. The sending server may keep the message in its queue and retry according to its own policy.
Permanent problems: class 5
A 5xx response, or an enhanced code starting with 5, indicates a failure treated as permanent for that delivery attempt. Immediately sending the same message again without changing anything will usually not help. “Permanent” does not mean the address can never receive email again: it means the cause needs attention before another attempt.
For example, 550 5.1.1 often suggests a problem with the recipient address, while 451 4.7.1 may indicate a temporary policy-related deferral. The precise interpretation depends on the accompanying text and the server’s implementation. A bare “550” does not, on its own, prove that the address does not exist.
3. Recognise common reasons for rejected email
The text beside the code is often more useful than the notification’s subject line. Read it in full before changing your domain settings or application configuration.
- Unknown address: check the spelling, the domain and any address selected by autocomplete. Confirm the address through an established communication channel.
- Mailbox full: the recipient may need to free up storage. Depending on the receiving server, this can be reported as a temporary or permanent failure.
- Message too large: check the total size, including attachments. If your organisation’s policy allows it, use an approved document-sharing method instead.
- Security-related rejection: possible factors include SPF, DKIM and DMARC authentication, sender reputation, attachments or the recipient’s filtering rules.
- Routing or domain problem: there may be DNS issues, unsuitable MX records or an unreachable destination server.
If the report mentions authentication, do not add or remove DNS records at random. All services sending on behalf of the domain need to be considered. Similarly, an email error mentioning “relay denied” may require a check of sending authorisation rather than a change to the recipient address.
4. Decide whether to wait or retry
The key distinction is between a delay notification and a final delivery failure report. If the action is delayed and the report says further attempts will follow, avoid immediately resending the message yourself. Otherwise, the recipient may receive duplicates once the problem clears.
- Check the status and any stated timeframe. The report may explain when another attempt is expected or when automatic retries will stop.
- Correct a clear cause. If the address is wrong or an attachment is too large, prepare a corrected message before trying again.
- Wait for external problems to be resolved. For a full mailbox or unavailable server, seek confirmation through another channel if necessary.
- Send one controlled test after the fix. Check the outcome before returning to normal sending.
A temporary problem can become a final failure when the retry period expires. Conversely, a permanent rejection may be resolved by correcting the configuration before sending again. For urgent messages, notify the recipient through a known alternative channel. Do not try to bypass filtering by repeatedly changing sender addresses or message content.
5. What to send your provider for investigation
A useful support request contains technical evidence, not the entire business conversation. Start by gathering:
- the sending date and time, including the time zone;
- the sender address and affected recipient, shared through a private channel;
- the SMTP code, enhanced status code and exact error text;
- the servers named in the report and any message or queue identifier;
- the application or service used, and whether the problem affects one recipient or several domains;
- relevant recent changes, such as DNS updates, a service migration or a newly configured application.
Copy the technical section of the report, removing the original message body, attachments and unrelated personal information. Do not share passwords, authentication codes or API keys. Keep the original notification: your provider may later request the complete headers through an appropriate channel. Headers can contain addresses and other information that should not be published.
If you use GazduireOnline.ro services, you can consult the frequently asked questions and submit the relevant details through the contact page. Identify the service involved precisely: your website, application and email may use different infrastructure even when they share a domain name.
6. In practice: check before you resend
When a delivery failure notification arrives, follow the same sequence: identify the affected address, establish whether delivery is delayed or has failed, then read the code alongside its explanation. Retry after the cause has been resolved or after confirming that automatic attempts have ended. If the problem remains unclear, give your provider the technical information needed to investigate rather than unnecessary correspondence content. This provides a relevant starting point without repeated sending or avoidable disclosure.
