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.
Field support is derived from source, not from live sends. See Verification for how adapters are tested.
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.
- Only x- prefixed custom headers are supported.
- Accepts at most 5 custom headers per message.
- Accepts at most 1,000 combined to, cc, and bcc recipients.
- Normal send accepts one to recipient, up to 50 cc and 50 bcc, and one reply-to.
- Recipient and reply-to addresses must be plain addresses without display names.
- Sends html only; a text-only message is escaped into html and text is dropped when html is present.
- Up to 10 attachments from an allowlist of content types; no inline attachments and no attachments with sendAt.
- Accepts at most 50 combined to, cc, and bcc recipients.
- Accepts at most 5 tags with values of 100 characters or fewer.
- Tag names are discarded; tag values are sent as plain strings.
- Accepts at most 10 metadata fields with keys of 50 characters or fewer and values of 100 characters or fewer; values are sent as strings.
- Subjects must be 256 characters or fewer.
- Idempotency keys longer than 36 characters are hashed to a UUID-shaped SHA-256 digest.
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.