WordPress sends email through wp_mail(), which is synchronous. Every call – whether triggered by a contact form submission, a WooCommerce order confirmation, or a password reset – blocks the PHP process until the SMTP handshake completes and the message is accepted by the relay. On a fast API-based provider, that takes tens of milliseconds. On a slow SMTP connection or a provider experiencing delays, it can take seconds. During that time, the user stares at a spinning browser.
This piece is the queueing question, which is downstream of having wp_mail() configured to route through an external service in the first place. For that setup, see How to set up email on WordPress.
An email queue breaks that coupling. Instead of sending immediately, the queue stores the message and returns control to the PHP process. The user sees their confirmation page instantly. The stored messages are processed in the background – typically via WP-Cron – at a rate the server and the email provider can handle.
What a queue adds
Async processing. The page request that triggers the email completes without waiting for SMTP delivery. On a form-heavy site, this is the difference between a sub-second response and a multi-second delay.
Rate limiting. SMTP providers enforce sending limits. Gmail allows 500/day (consumer) or 2,000/day (Workspace). SMTP2GO‘s free tier caps at 200/day. A queue drips messages out at a configured rate instead of bursting them all at once, staying within provider limits and reducing the risk of rate-limit rejections.
Retry on failure. If wp_mail() fails – the SMTP server is unreachable, the connection times out, authentication fails – the email is lost. WordPress does not retry. A queue can hold failed messages and reattempt delivery on the next processing cycle.
How WordPress queues work
The implementation is consistent across plugins:
- A queue plugin hooks into
wp_mail()– either via thepre_wp_mailfilter (available since WordPress 5.7) or by replacing the pluggable function entirely. - Instead of sending, it serialises the message (to, from, subject, body, headers, attachments) and stores it – typically in the
wp_optionstable or a custom database table. - A WP-Cron event fires at a configured interval (every minute, every five minutes).
- The cron handler retrieves queued messages and sends them through the configured mailer, one at a time or in small batches.
The WP-Cron caveat is important: WordPress’s built-in cron is pseudo-cron. It only fires when a page is loaded. On a low-traffic site, a queued email may sit for hours until someone visits the site and triggers the cron. For production queue processing, disable WP-Cron’s page-load trigger (define('DISABLE_WP_CRON', true) in wp-config.php) and run it from a real server cron job (*/1 * * * * wget -q -O - https://example.com/wp-cron.php).
Plugin options
Dedicated queue plugins
Mail Queue by WDM is a pure queue: it intercepts wp_mail(), stores messages, and processes them on a schedule. It does not include its own SMTP mailer, so it works with whatever mailer plugin is already configured (WP Mail SMTP, FluentSMTP, Post SMTP, or plain wp_mail()). At ~900 active installs and a recent update cadence, it is the smallest plugin on this page that is still actively maintained.
SMTP Mailing Queue was closed on wordpress.org in October 2024 at the author’s request and is no longer available for download. GD Mail Queue is still listed but its last release was December 2024 and it is tested only up to WordPress 6.7. Both also bundle their own SMTP mailer, which conflicts with a dedicated mailer plugin (two plugins both trying to handle wp_mail()). For a new queue install in 2026, either Mail Queue by WDM (with a separate mailer) or a mailer plugin with built-in async processing (see below) is the safer path.
Mailer plugins with built-in async
Several mailer plugins handle sending asynchronously without a separate queue plugin:
WP Offload SES sends via the Amazon SES API asynchronously and includes its own queue and retry logic.- FluentSMTP processes email sending in the background for API-based connections.
For a list of mailer plugins with background processing, see the background email processing feature page.
When you need a queue
A dedicated queue plugin is worth adding when:
- The site sends email via SMTP (not API) and the SMTP handshake visibly delays page responses – typically on form-submission pages.
- The site sends bulk notifications (membership renewals, course completions, order updates) that can burst past provider rate limits.
- Email reliability matters enough to justify retry logic that
wp_mail()does not provide natively.
When you don’t
Most WordPress sites sending A transactional email is the automated message a WordPress site sends in response to a single user action – a password reset, an order confirmation, a form receipt – addressed to the user who triggered it. Read full reference → through an API-based mailer plugin (WP Mail SMTP with Postmark/SendGrid/SES, FluentSMTP with any API provider) do not need a separate queue. The API call is fast (typically under 100ms), the provider handles delivery queuing on their end, and the mailer plugin may already process sends asynchronously. Adding a queue plugin on top adds complexity without a measurable benefit.
If the site sends fewer than a hundred emails per day through a modern SMTP relay like SMTP2GO or Postmark, the synchronous wp_mail() call is unlikely to cause noticeable delays. The queue becomes valuable at scale, not at baseline.