# Message-ID: Definition and How It Works

Source: https://wraps.dev/glossary/message-id

InfrastructureSES MessageIdemail Message-ID header

Message-ID is the RFC 5322 header uniquely identifying an individual email message; SES's own MessageId, returned from a successful send, is the handle used to correlate that send with its later delivery, bounce, and complaint events.

## Two related but distinct identifiers

The RFC 5322 \`Message-ID\` header is generated by the sending mail system and embedded in the message itself, in the form \`<unique-string@domain>\` — it's what lets mail clients thread replies and lets any system inspecting the raw message identify it uniquely. SES's own \`MessageId\`, returned in the response to a successful \`SendEmail\` or \`SendBulkEmail\` call, is a related but separate identifier — SES's own handle for tracking that specific send through its systems, not necessarily byte-identical to the RFC 5322 header value.

## It's the join key across the entire event stream

Every event SES publishes about a send — delivery, bounce, complaint, open, click — carries the same \`MessageId\` in its payload, specifically under \`mail.messageId\`, so an application consuming that event stream through SNS or EventBridge can correlate every downstream event back to the exact send that triggered it, even when events for different sends and different recipients arrive interleaved.

## It's the natural key for idempotency and deduplication

A background worker or queue consumer processing a send request has to guard against sending the same message twice — a retry after a network timeout, a redelivered queue message, or a race between workers. Since SESv2's \`SendEmail\` has no idempotency-token parameter of its own, tracking your own request against the returned \`MessageId\` (or a dedupe key you generate before the call) is the mechanism that actually prevents a duplicate send from a retried request.

## It's also how a single message gets traced end to end

Being able to answer "what happened to this specific email" — was it delivered, did it bounce, did the recipient open it — depends entirely on retaining the \`MessageId\` from send time and being able to look it up later, whether that's through your own application's event log, a query against SES's event stream, or a support conversation where a customer can only describe roughly when they expected to receive something.

## Why it matters

Without capturing MessageId at send time, an application has no way to answer basic operational questions about a specific email after the fact — whether it was delivered, whether it bounced, or whether it's the reason a retry is about to send a duplicate — which is why persisting it is one of the first things any serious send pipeline does, before any subsequent step that could fail.

## Common questions

### Is the SES MessageId the same as the RFC 5322 Message-ID header?

They're related but not guaranteed to be identical — the RFC 5322 header is embedded in the message itself for mail-client threading, while SES's MessageId is its own handle for tracking the send through its systems and event stream. Treat them as related, not interchangeable.

### Does SES prevent me from accidentally sending the same email twice?

Not on its own — SESv2's SendEmail has no built-in idempotency token. Preventing a duplicate send on retry is the caller's responsibility, typically by tracking the request against the MessageId or a dedupe key generated before the call.

### Why should I save the MessageId immediately after a send succeeds?

It's the only handle that lets you correlate that specific send with its later delivery, bounce, or complaint events, and the only way to trace a single message end to end when a customer asks what happened to it. Losing it means losing that traceability permanently.