The short answer

Save the complete non-delivery report, not just a screenshot of the first line. Note the sending route, recipient domain and time. The error class, enhanced status code and diagnostic text together help distinguish a temporary deferral, invalid destination, policy rejection or sender restriction.

A bounce is useful evidence

A non-delivery report often includes the system that rejected the message and its diagnostic explanation. Keep that original report. Cropping it to “delivery failed” can remove the part that makes the problem understandable.

Record the sending platform and the time with its time zone. If a message ID is provided, keep it for your authorised support team. Share recipient details only through a private channel with people who need them.

Read the class and the diagnostic together

Enhanced status codes commonly distinguish success, temporary failure and permanent failure classes. The full code and the accompanying text narrow the meaning. A code without its explanation is an incomplete starting point.

Do not apply a fix just because another website mentions a similar number. Different receiving systems can provide different policy details, and the route of the failed message matters.

The examples below are categories to investigate, not diagnoses of your account.

Report suggests Useful next check
Invalid or unknown recipient Confirm the address through an appropriate existing relationship; suppress confirmed invalid contacts
Temporary deferral or unavailable service Inspect the full response and the sender’s retry handling rather than manually blasting repeats
Authentication or policy rejection Give IT the complete report and original route so they can evaluate the relevant domain and policy
Sending account restriction Investigate the sending account and unexpected activity before restoring or increasing sending

Don’t confuse rejection with spam placement

A message can be rejected before it reaches a mailbox, or accepted and then placed in junk. Those are different outcomes. A placement test may help investigate an accepted message, but it cannot replace the evidence in a genuine rejection report.

If your only observation is “nobody replied”, use the delivery-metrics guide before labelling it a bounce problem.

Identify who can act

You can collect the report, note the affected platform and check whether the issue concerns one recipient or many. An administrator or platform support team usually needs to inspect server-side policy, sending restrictions or account configuration.

If you use Microsoft 365, ask an authorised mail administrator to correlate the report with message trace. If a recruitment CRM sent it, include the specific product, campaign or connection.

Don’t request a broad security exception or disable protection to make one error disappear. Ask what condition triggered the response and how a proposed change will be verified.

Keep retries deliberate

Repeatedly sending to a permanently invalid address does not improve it. For a temporary problem, understand how your sending service already retries. Manual resends can create duplicate messages or unnecessary volume.

Before resuming a paused campaign, check the queue and recipient data. Keep the investigation separate from the pressure to deliver the next mailshot immediately.

A concise handoff

Bring the exact report, sender, destination domain, route, time, scope and recent changes. State what is known and what is assumed. Our IT handoff builder organises that information without submitting a support ticket or uploading it to us.

Sources & scope

This is a documentation-led guide, not a claim of hands-on testing in your account. Sources checked 19 October 2026. Product settings and provider policies can change.

How we write and check guides →

Give IT something useful to work with.

Turn the symptoms and checks into a clear, private handoff.

Build an IT handoff