Thunderbird Send Later Outbox and Scheduled Drafts Are Different States

A message has left the compose window, but it has not appeared in Sent. Before deciding it is scheduled for tomorrow, identify where it went and which sending control you used. A queued message and a scheduled draft are different states, even when the interface uses the reassuring word “later.”

This guide focuses on the Send Later extension for Thunderbird and its documented distinction between scheduling a message and placing it in Outbox. It is not a claim that every Thunderbird version or every scheduling product has identical controls. Note your application and extension versions before following a tutorial.

Start with the action rather than the expectation

Suppose you finish a club update in the evening and intend it to leave the next morning. You dismiss the compose window after choosing an option that mentions later delivery. The next day, the message is still waiting, or it appears to have left at a different time from the one you expected.

The first useful question is not whether the mailbox needs reinstalling. It is whether a scheduled time was actually assigned. Write down the button you remember choosing, any date or time you entered, and the folder where the message is now visible. Avoid sending another copy while the first message’s state is uncertain.

What the extension documentation distinguishes

The maintainer’s Send Later documentation distinguishes the “Put in Outbox” action from scheduling. That action queues the message rather than assigning a future delivery time. The guide also describes scheduled messages being held in Drafts before moving to Outbox for transmission. Queue delivery can affect other waiting messages, so a command that sends unsent mail should not be treated as a harmless preview.

These details help interpret the screen; they do not establish what happened in your particular case. A message’s subject, recipient and timestamp should be compared carefully, especially if you have already created more than one version.

Make a small message-state worksheet

1. Identity: record a non-sensitive subject label, such as “club update test,” and the account used to compose it.
2. Action: record the control selected. Say “I do not remember” if necessary rather than filling the gap with a guess.
3. Time: note whether a specific date and time were confirmed, or whether you only expected a delay.
4. Location: record whether the item is visible in Drafts, Outbox or Sent. Include which account or Local Folders section you checked.
5. Outcome: distinguish waiting, a visible transmission error and an item recorded as sent. Do not use a recipient’s silence as the only evidence of delivery failure.

For the club-update example, a useful note might read: “I selected the queue option, did not confirm a clock time and now see one matching item in Outbox.” That is a more precise starting point than “the scheduler lost my email.” It also helps prevent a helper from investigating the wrong feature.

Review the whole queue before a delivery command

A queue can contain older messages that you no longer intend to send. Before using a command that delivers waiting mail, review the entries and their recipients. If the list contains an unexpected business proposal, an outdated attachment or a duplicate draft, stop and resolve those items first.

Do not use a real confidential message to experiment with unfamiliar controls. If you choose to perform a test, use harmless text and an address you control, after checking that no unrelated messages are waiting for delivery. Record one action and one result rather than trying several changes at once.

Separate scheduling from a connection failure

If a message is queued and a transmission error appears, capture the exact non-sensitive wording. If you cannot tell whether a scheduled time was assigned, focus on the scheduling record first. Those are different questions, and changing server ports without identifying the failing stage can make the investigation harder.

The independent EmailSupport Thunderbird guide provides a broader starting point for separating account access from application behavior. Provider-controlled sign-in and account-recovery decisions still belong with the original provider. Keep passwords, recovery codes and private message contents out of an initial support request.

A clear next step comes from identifying the current state: drafted, scheduled, queued or transmitted. Confirm that state before resending or rebuilding anything. EmailSupport is operated by Scott Jeppesen and provides independent third-party guidance; it is not affiliated with or endorsed by Thunderbird, the extension’s maintainers or any email provider.