Field support
Source-derived support for normalized message fields across all built-in adapters.
Use this page to eliminate incompatible routes before sending. A primary adapter and every fallback must support every normalized field your message uses; Email SDK validates the complete route before the first request, so an incompatible backup fails early instead of dropping data.
Field support answers whether an adapter can represent a message field. Use Delivery capabilities when retries, idempotency, scheduled delivery, repeated headers, or personalized fanout matter.
Normalized message fields
- Accepts one tag and flattens one name:value tag for the provider payload.
- Native personalized delivery caps one request at 1,000 recipients.
- Tag names are discarded; tag values are sent as categories.
- Accepts at most 50 combined to, cc, and bcc recipients.
- Recipient display names are not supported; plain strings and {email} objects are valid.
- Accepts one reply-to address.
- Accepts one reply-to address.
- Native personalized delivery caps one request at 1,000 recipients.
- Tag names are discarded; tag values are sent as o:tag values.
- Accepts one reply-to address.
- Tag names are discarded; tag values are sent as tags.
- Accepts one reply-to address.
- Scheduling sends provider UTC strings in yyyy-mm-dd HH:MM:ss grammar.
- Scheduling sends provider UTC strings in YYYY-MM-DDTHH:mm:ss±HH:mm grammar.
- Normal send accepts one to recipient.
- Normal send accepts one to recipient.
- Accepts at most 50 to recipients.
- Accepts one reply-to address.
- Requires a from display name.
- Accepts at most 50 to, 50 cc, 50 bcc, and 50 reply-to addresses.
- Accepts one tag.
- Accepts at most 50 combined to, cc, and bcc recipients.
- Recipient display names are not supported; plain strings and {email} objects are valid.
- Accepts one reply-to address.
- Accepts one tag.
- Rejects inline attachments.
- Accepts at most 10 custom headers.
- Normal send accepts one to recipient.
- Accepts one reply-to address.
- Accepts one tag.
- Accepts one reply-to address.
- Rejects replyTo when headers already include Reply-To.
- Validates ASCII envelope addresses and header names before opening a connection.
The comparison is source-derived from SUPPORTED_MESSAGE_FIELDS and adapter validation rules. Unsupported values are rejected by both validate and send before a provider call.
Route selection
Pick the narrowest route that preserves the message you are actually sending. If a fallback cannot support one of the fields, remove that fallback for this send or normalize the message before it enters the route.
For provider-specific option fields, payload notes, and credentials, open the linked adapter setup page from the comparison above.
Headers
headers is a lossless array in v1, so repeated names stay visible to adapters that support repeated headers.
const headers = [
{ name: "X-Trace", value: "first" },
{ name: "X-Trace", value: "second" },
] as const;Repeated names require every candidate adapter to advertise repeated-header support in Delivery capabilities. Otherwise validation fails before the primary sends.
Attachments
Each attachment has exactly one source: content or path. A string content value is raw by default; set contentEncoding: "base64" only when the string is already encoded.
const attachments = [
{
filename: "receipt.txt",
content: "Order 123",
contentType: "text/plain",
},
] as const;See the message reference for the exact v1 message and attachment types.