Skip to main content

Documentation Index

Fetch the complete documentation index at: https://support.jetemail.com/llms.txt

Use this file to discover all available pages before exploring further.

​
Scheduled Sends (SMTP)

Add an X-Scheduled-At MIME header to a message you submit over SMTP and JetEmail will hold the message until the requested time, then process it through the same validation and delivery pipeline as an immediate send. Without the header, the message is sent immediately, exactly as before.

​
When to use it

Scheduled sends over SMTP are useful when:
  • You already submit mail through SMTP and don’t want to add an HTTP integration just to schedule.
  • A mail server, plugin, or library can inject custom MIME headers on outgoing messages.
  • You want time-zone aware reminders, drips, or delayed announcements.

​
Header reference

HeaderRequiredNotes
X-Scheduled-AtNoFuture send time. Unix seconds (UTC) or ISO 8601 / RFC 3339 with offset.
Limits
  • The time must be in the future.
  • The time must be no more than 30 days out.
  • A request that violates either rule is rejected at submit time.
Whole seconds only. Sub-second precision is not supported.

​
Accepted formats

X-Scheduled-At: 2026-05-15T10:00:00Z
X-Scheduled-At: 2026-05-15T10:00:00-04:00
X-Scheduled-At: 1762435200

​
Example SMTP transaction

MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
DATA
From: [email protected]
To: [email protected]
Subject: Reminder
X-Scheduled-At: 2026-05-15T10:00:00Z
Message-ID: <[email protected]>

This will arrive at the scheduled time.
.
The server returns a normal 250 response on accept. The message is durably stored and dispatched at the scheduled time.

​
Validation runs twice

A scheduled message is checked at submit time and again at send time. Submit-time checks (domain ownership, recipient limits, suppression, virus and spam scanning) surface failures synchronously in the SMTP reply rather than 30 days later. At the scheduled time, the same checks run again to catch state changes that happened in the meantime. If any of these are true at send time, the message is not delivered:
  • The sending domain is no longer verified.
  • The recipient has been added to a suppression list.
  • The account is disabled or has been downgraded below what the original payload requires.
These produce a recorded failure rather than a delivery.

​
Combining with idempotency

X-Scheduled-At works with the X-Idempotency-Key header. Pairing the two is recommended for retried scheduling submissions so a network blip during DATA does not produce a duplicate scheduled message.