Support Should See the Transactional Email Log, Not Ask Engineering

Answer first: Support should be able to answer “did the password reset go out?” from a stored email id and a sent record—not from a Slack ping to engineering. In ArawaMail, Send Email returns an id; Retrieve Email returns headers, body, created_at, and last_event (documented example: sent). That proves provider acceptance of the send request. It does not prove the recipient’s server accepted the message, and it does not prove inbox placement.

The ticket that should never reach engineering first

The customer writes: “I never got my password reset.” The bad path is familiar. Support asks engineering. Engineering greps application logs. Someone opens a cloud console. Thirty minutes later the team still cannot say whether the product accepted the send, whether the email API accepted it, or whether Gmail put it in spam.

That is not a staffing problem. It is a visibility problem. Transactional mail is part of the product. If support cannot inspect a send the way they inspect an order, you are still treating transactional mail as a side project.

Five different meanings of “sent”

Operators collapse five events into one word. Separate them or the ticket will never close cleanly.

Stage	What it actually means	What it does not prove
Application accepted	Your app queued or called the email API and stored an id (or failed before that).	The provider received the request.
Provider accepted	The email API returned success. In ArawaMail this is a Send Email id plus Retrieve Email last_event: sent (or a visible Sent copy).	The recipient MTA accepted the message.
Recipient server accepted	Remote SMTP 250 / equivalent. Some ESPs expose this as a delivery event.	The message is in the inbox.
Bounce or complaint	The remote side rejected later, or the user marked spam.	Nothing about messages that never reached that stage.
Inbox placement	The message is visible in Inbox (not Promotions, Spam, or filtered).	Cannot be inferred from an API 200 or last_event alone.

A recipient-server SMTP 250 is server acceptance only. Gmail can still filter. That is why inbox-placement testing and spam-folder diagnosis are different jobs from “check if email was sent.”

What ArawaMail documents today (and what it does not)

This section is constrained to public product docs and the live pricing page—not hoped-for ESP features.

• Send Email returns an id.
• Retrieve Email (GET /emails/{id}) returns from, to, cc, bcc, reply_to, subject, html, text, created_at, and last_event. The documented example for last_event is sent. A missing sent-folder record returns 404.
• There is no documented public list/search API for sent mail by recipient or subject. Application code must persist the id next to the user, ticket, or order.
• HTTP API messages are written to the Sent folder. Mailbox users can open Sent and Search. Administrators can open mail from Email accounts.
• Outgoing webhooks fire on incoming mailbox mail only. They are not bounce, complaint, delivery, or SMTP-response streams. See transactional email webhooks for inbound callback patterns—not delivery telemetry.
• There are no documented bounce, complaint, delivery, delay, open, click, or inbox-placement events. Do not build a support dashboard that pretends those rows exist.

Public pricing documents transactional record retention of 45 days (Free), 60 days (Pro), and 90 days (Business). Inbox and Sent copies stay until deleted, subject to mailbox storage. Mailbox Spam is deleted after 30 days and is excluded from normal search and incoming webhooks—that is inbound spam retention, not transactional activity retention.

How we analyzed this

We mapped support questions onto documented ArawaMail fields, then compared the same questions to how Amazon SES and Postmark expose activity. SES can publish send, delivery, bounce, complaint, delay, reject, open, and click through configuration-set destinations (SNS, CloudWatch, Firehose)—flexible and engineering-heavy. Postmark Message Activity exposes per-message events and remote-server responses, with a default retention window that operators should re-check on live Postmark docs before quoting. ArawaMail’s documented ceiling for this article is: persist the id, retrieve the record, read last_event, and use the mailbox Sent folder when the send originated there. See also ArawaMail vs Amazon SES.

The good support workflow

1. Look up the application-stored email id on the user, ticket, or order. If the message was sent from that mailbox rather than only via API, search Sent.
2. Call Retrieve Email or open the Sent copy. Confirm recipients, subject, created_at, and last_event.
3. Stop at documented fields. Do not invent a bounce row because the customer “didn’t see it.”
4. Escalate when the app never stored an id, Retrieve Email returns 404 inside the pricing retention window, or the provider accepted the send and the message still is not in the customer inbox.

Store the id at send time in the same transaction as the password-reset token or receipt. Without that id there is no support log, only archaeology. Next.js send patterns are covered in Send email from Next.js.

What support should see—and what they should never see

A useful transactional email dashboard for support is narrow:

• Email id, created_at, from, to, subject, last_event.
• Link to the ticket or user record.
• Retention hint from the current plan (45 / 60 / 90 days on pricing).

It should not expose API keys, unrestricted HTML bodies of other customers, or raw cloud credentials. MCP can search a consented mailbox; that is not a substitute for a send log unless the message was sent from that mailbox.

When engineering is actually required

• No id was persisted—application bug, not an ESP mystery.
• Retrieve Email 404s inside the published retention window—record missing or never written.
• last_event is sent and the customer’s provider still has no message—placement, filtering, or a remote-side delay. That is deliverability work, not “check CloudWatch.”

FAQ

How do I check if a transactional email was sent?

Persist the Send Email id, then Retrieve Email. last_event of sent means ArawaMail accepted the request and wrote a sent record. Ask the customer to check spam only after that record exists.

Does last_event mean the email is in the inbox?

No. last_event documents provider-side status. Inbox placement is a separate question.

Can support search by recipient without an id?

Not through a documented public list API. Search the mailbox Sent folder if the send used that mailbox, or require the application to store the id.

How long are transactional records kept?

Per public pricing: 45 days Free, 60 days Pro, 90 days Business. Mailbox inbox and sent copies are kept until deleted, within storage limits.

Do ArawaMail webhooks tell support about bounces?

Documented outgoing webhooks cover incoming mailbox mail. They are not a bounce or delivery stream.