Why this happens
An email can show as delivered and later appear as a soft_bounce or hard_bounce when the recipient server accepts the message first, but a later delivery step fails.
This is called a delayed bounce.
Mailgun example
Mailgun defines a delayed bounce as an email that was initially marked as delivered and later received a permanent failure from the mailbox provider. In raw Mailgun logs, look for is-delayed-bounce=true. For more information, see Mailgun's metric definitions.
A delivered event is not a guarantee that the message reached the recipient's final inbox. It confirms that a recipient server accepted the message at that point in the delivery process.
Important: A delayed bounce does not usually mean that the original delivery event was incorrect. It means that a later delivery step failed.
How an email can be delivered before it bounces
The delivery path can include more than one mail server:
You send an email to the recipient's mailbox, for example
recipient@example.com.The recipient's mail server accepts the email and reports a successful delivery.
The recipient's mailbox forwards the email to another address or domain, for example,
recipient@another-domain.com.The forwarding server sends the message to the next mail server.
The next mail server checks the message's authentication and rejects it. The forwarding server fails the authentication or alignment check for the original sending domain.
The rejection reaches Mailgun, which records a delayed bounce.
The email can therefore appear as delivered first and bounced later. The delay can range from a few minutes to much longer, depending on when the forwarding or downstream server processes the message.
You may also see an open event before the bounce. An open confirms that an open-tracking event was recorded. It does not confirm that every later delivery step, including forwarding, succeeded.
The most common cause: forwarding and authentication checks
The most common cause of a delayed bounce is an automatic forwarding rule on the recipient's mailbox.
Forwarding can change how the message appears to the next receiving server. The forwarding server may not be authorized to send mail for your original sending domain. As a result, the forwarded message can fail SPF, DKIM, or DMARC checks even when your original email authentication is configured correctly.
This pattern is usually sporadic because only some recipients have forwarding rules. It is not limited to Microsoft, Gmail, Yahoo, or any single provider. Any mailbox provider or forwarding destination can produce a delayed bounce.
A small number of delayed authentication bounces, while most messages deliver successfully, usually points to recipient-specific forwarding rather than a sender-wide authentication outage. A large increase across many recipients and providers requires a broader review of your sending configuration.
How to confirm a delayed bounce
Check the event details for an affected email and compare the events in time order.
Look for:
A
deliveredevent followed later by asoft_bounceorhard_bounceevent.In case of Mailgun as ESP, look for the flag
is-delayed-bounce=true.A permanent failure classification in the Mailgun or other ESP's event details.
An error message that mentions authentication, alignment, SPF, DKIM, DMARC, or access being denied.
The recipient domain, recipient provider, message ID, sending time, and sending IP.
The event sequence is the strongest clue. If the bounce occurs immediately and there is no delayed-bounce flag, investigate it as a different delivery problem.
What to do next
Ask affected recipients to review forwarding
Ask the affected recipient to check whether their mailbox:
Automatically forwards messages to another address.
Forwards messages to an external domain.
Stops keeping a copy in the original mailbox.
Uses a forwarding service to modify or resend the message.
The recipient's email administrator may need to review the forwarding server logs and its support for forwarding authentication mechanisms.
Retry a message when the issue is sporadic
A one-time retry can help confirm whether the forwarding rule changed or the recipient now receives the message directly. A successful retry does not prove that the problem is resolved permanently.
If the same address repeatedly produces delayed authentication bounces, exclude it from future campaigns or ask the recipient for an address that does not use automatic forwarding. This helps prevent repeated failures from affecting your sending performance.
Contact support with the event details
Contact support when you need help confirming the classification or the cause. Include:
The affected recipient address
The message ID
The date and time the message was sent
The sending domain and sending IP
The complete bounce message
The event sequence showing the original delivery and later bounce
These details help distinguish a delayed bounce from a sender-authentication issue, an invalid recipient address, or another delivery failure.
FAQ
Can I prevent delayed bounces completely?
No. You cannot control forwarding rules or authentication checks performed by servers after the original recipient server accepts the message. Valid SPF, DKIM, and DMARC configurations can reduce authentication problems, but they cannot prevent every forwarding-related bounce.
Does a delivered event mean the email reached the inbox?
No. A delivered event means that a recipient server accepted the message. The message can still be forwarded, filtered, or rejected during a later delivery step.
Does an open event mean the email was delivered successfully?
No. An open event confirms that an open-tracking event was recorded. It does not confirm that a forwarded copy reached its final destination.
Is this always a Microsoft issue?
No. Delayed bounces can come from any recipient provider. Microsoft may appear frequently in examples because many recipients use Microsoft mailboxes, but the same forwarding pattern can occur with other providers.
Does a delayed authentication bounce mean my SPF, DKIM, or DMARC setup is wrong?
Not necessarily. Verify your authentication first. If most messages deliver successfully and only a small subset of recipients produce delayed authentication bounces, forwarding at the recipient side is a likely cause.
Summary
A delivered event, followed later by a bounce, usually means that the original recipient's server accepted the email, but a later delivery step failed. Automatic forwarding and downstream SPF, DKIM, or DMARC checks are common causes.
Confirm the event sequence and delayed-bounce flag, verify your sender authentication, ask affected recipients to review forwarding rules, and exclude addresses that repeatedly fail.