Use forwarding delivery evidence to investigate a specific message after confirming the alias, verified destination and deployed mail route. The API can show events reported by the runtime. It cannot reconstruct missing events or guarantee that a recipient placed a message in the inbox.
| Method | Resource | Scope | Idempotency-Key |
|---|---|---|---|
GET |
/v2/forwarding/domains/{domainId}/mail-deliveries |
forwarding:logs |
Not required by this route |
GET |
/v2/forwarding/mail-deliveries/{traceId} |
forwarding:logs |
Not required by this route |
01 Trace a controlled message
- Record the sender, source alias, expected destination and sending time with its timezone. Keep the message ID when available.
- Read the forwarding domain's delivery collection using a credential with
forwarding:logs. Page through the returned evidence; do not assume the first page covers the test time. - Select the matching trace and read it directly. Match the source, destination and timing before interpreting the result.
- Compare recorded acceptance, routing, rejection or delivery information with the sender's bounce and the recipient's message headers.
- Check the recipient's spam folder, quarantine and mailbox rules when the runtime records successful handoff but the user cannot find the message.
02 Interpret gaps and failures
An accepted message may still be queued or rejected later. A complete end-to-end bounce and delivery pipeline is not established by this release's trace interface alone. Describe exactly what the evidence shows, such as accepted by the forwarding runtime or reported delivered to the next server.
If no trace exists, first verify that public MX records point at the configured mail runtime and that the message actually reached it. Then check whether runtime event ingestion is operating. An empty collection does not independently prove that the sender never sent the message.
Common questions
Can I use the trace ID to resend the email?
These endpoints read evidence. They do not provide a general message replay operation. Investigate the original result and ask the sender to resend only after the route is ready and duplicate delivery has been considered.
Why is the trace incomplete?
The runtime may not have reported every stage, or later processing may occur at the destination provider. Compare its evidence with the actual bounce and message headers.
What should I send to support?
Provide the forwarding-domain ID, trace ID, UTC time, affected alias and a redacted error or bounce. Avoid attaching the full private message unless it is necessary and approved. Never include destination verification codes or API keys.