Back to Blog

Shipping Confirmation Email Templates for Tracking, Delays, and Split Shipments

9 min read
Shipping Confirmation Email Templates for Tracking, Delays, and Split Shipments

A shipping template system should map to fulfillment events, not merely decorate a single “your order is on the way” email. The same order can move through multiple shipments and exceptions.

State-to-template map

StateSubjectPrimary action
ShippedYour order has shippedTrack shipment
Label createdYour shipment is being preparedWait for carrier acceptance
DelayedAn update about your shipmentReview latest estimate
Split shipmentPart of your order has shippedTrack each package
Out for deliveryYour package is out for deliveryPrepare to receive
DeliveredYour package was deliveredReview delivery details
ReturnedYour package is returning to senderContact support or confirm refund

Do not call a label-created event shipped if the carrier has not accepted the package.

Base shipped template

Subject: Your order {{order_number}} has shipped

Hello {{customer_name}},

{{item_summary}} shipped with {{carrier_name}}. Estimated delivery: {{delivery_estimate}}.

[Track shipment]

If tracking does not update by {{stalled_date}}, contact {{support_email}}.

Delay variant

Subject: An update about order {{order_number}}

Your shipment is delayed. The latest carrier update is {{current_status}}. We now expect delivery {{updated_estimate}} or will send another update by {{next_update_date}}.

[View tracking]

Do not replace the estimate with a guaranteed date unless the carrier gives one.

Split-shipment variant

Subject: Part of your order has shipped

The following items are on the way:

{{shipped_items}}

Track them here: {{shipped_tracking_url}}

The remaining items are expected {{remaining_estimate}}. We will send another message when they ship.

Returned-shipment variant

Subject: Your shipment is returning to us

The carrier could not complete delivery and is returning shipment {{shipment_id}}. We will {{actual_next_step}}. Contact {{support_email}} if the delivery address needs review.

Data and suppression

Render from shipment records with immutable item membership. Use shipment ID, status, and event version for idempotency. Suppress or replace messages when:

  • the order is canceled;
  • the shipment is delivered or returned;
  • an address correction owns the workflow;
  • a replacement shipment is created;
  • a customer has an active support case for the same exception.

QA checklist

  • Each item appears in only the shipment where it was fulfilled.
  • Carrier status is not stale or out of order.
  • Tracking links are correct and safe.
  • Delivery estimates are qualified.
  • Duplicate webhooks do not duplicate messages.
  • The email remains understandable without decorative content.

Use the shipping confirmation examples for shorter copy and the split shipment template for one state in detail.

Data contract and event ordering

Treat each shipment as an immutable record with item IDs, carrier, tracking, destination, and status timestamps. Carrier webhooks can arrive late or out of order, so the workflow should ignore an older event after a newer terminal state unless the carrier sends an explicit correction.

Before rendering, check:

  • the order is not canceled;
  • the shipment belongs to the recipient;
  • tracking is valid for the stated carrier;
  • item membership has not changed;
  • the estimate is not older than the last carrier update.

Support handoff

Every exception variant should tell support what the customer will see in the portal and what evidence is available. A good template reduces WISMO tickets; a vague template merely moves the question from the inbox to the help desk.

Define the source-of-truth boundary

Fulfillment owns whether a package is handed to a carrier; the carrier owns scans after handoff; the order system owns what was purchased; support owns manual exceptions. Put that ownership in the template contract so a copy edit cannot accidentally turn an estimate into a promise.

Use a versioned status mapping and test it against real provider payloads. “Label created,” “accepted,” “in transit,” “attempted,” “delivered,” and “returned” should not collapse into one state just because they share a tracking number. When a provider adds a new status, route it to review rather than guessing the nearest customer-facing phrase.

Rendering and accessibility

Put the operational action near the top, show item names in text, and keep tracking links next to the shipment they describe. Use alt text for product images, a visible plain-text URL or support path in the text part, and a mobile layout that does not require horizontal scrolling. Avoid placing the only delivery estimate inside an image.

Test long item names, multiple packages, right-to-left addresses, dark mode, blocked images, a missing estimate, carrier tracking downtime, and a replacement shipment. Track delivery-related contacts, invalid tracking links, duplicate sends, and the rate at which customers reach the correct self-service path.