GD Mail Queue by 
Milan Petrovic (Dev4Press) is a queue-based mail interceptor for WordPress: outbound messages are captured before PHPMailer’s send() runs, stored in a custom database table, and drained on a cron schedule. The architecture is sound. The maintenance picture is not.
Version 4.4 shipped on 2024-12-03 and nothing has shipped since. The wp.org listing shows the standard “hasn’t been tested with the latest 3 major releases of WordPress” banner. Active installs sit at 700-plus, and the 5.0 rating represents 11 reviews. The plugin requires WordPress 5.9 and PHP 7.4, ships under GPLv3-or-later, and is tested up to WordPress 6.7.5. A reader installing the plugin in 2026 is installing software whose last touch was eighteen months ago. The vendor’s recent release activity has concentrated on coreSecurity, KnowledgePress, and coreActivity; GD Mail Queue is still listed but it is no longer the front of the shop.
How it intercepts outbound mail
The wp.org description states that the plugin does not replace wp_mail(). Strictly true and slightly misleading.
A detection pass registers on the wp_mail filter at priority 1, in core/objects/core.detect.php. The handler examines the message headers, tags the current email type (Contact Form 7 is detected via X-WPCF7-Content-Type; BuddyPress and bbPress have their own markers), and returns the arguments untouched. The detection step does not divert the message; it only routes it so the queue knows which template, headers, and retry behaviour to apply later.
The actual handoff happens at phpmailer_init. core/objects/core.mailer.php hooks the action at priority 100000000, late enough to win against any other listener. The handler swaps WordPress’s PHPMailer instance for gdmaq_fake_phpmailer from core/objects/core.fake.php: a stub whose send() returns true unconditionally while its magic __get, __set, and __call methods reject every interaction. WordPress’s own wp_mail() sees a successful send, returns true, and fires wp_mail_succeeded. Nothing reached the wire. The real outbound work, with a real PHPMailer object, happens later in the cron processor.
The mechanism is clean and the failure mode is narrow. Any sender that calls wp_mail() through the standard pluggable function and lets WordPress build PHPMailer is queued. Two patterns are not: a plugin that constructs its own PHPMailer (or Symfony Mailer, or a vendor SDK) before sending, and a plugin that calls PHP’s mail() directly. The readme is explicit on the first point and silent on the second; in practice both bypass the queue, as does any other plugin that has replaced wp_mail() from a higher-priority slot.
How the queue drains
The queue processor lives in core/objects/core.queue.php. Its init() registers a custom WordPress cron schedule named gdmaq_queue, with an interval of 60 * $cron seconds (default 5 minutes). The processing hook is gdmaq_run_queue, which calls gdmaq_core_queue::run() to drain up to a configurable batch (default 100 messages) per tick, with a configurable sleep between sends to spread the load on the upstream SMTP service.
Cron processing is WordPress cron, not system cron. On a low-traffic site, the queue stalls until a request arrives to fire wp-cron.php. The standard mitigation applies: disable WordPress cron in wp-config.php and call wp-cron.php from a system cron job at the desired interval. The implication is the same as for any wp-cron-based job: do not assume the documented interval until the trigger has been verified.
A separate daily hook, gdmaq_run_maintenance, runs in gdmaq_core_plugin::maintenance() and purges successfully sent and failed queue entries on the retention windows configured in the admin panel. The default purge age is 30 days. Operators who want to retain a complete audit trail should change the defaults explicitly; the out-of-the-box behaviour is tuned for keeping the queue tables compact, not for keeping evidence.
The htmlfy wrapper
The htmlfy module is the plugin’s distinctive feature in the free tier. Outbound mail that arrives at the queue as plain text is wrapped in a chosen HTML template before sending, with sanitisation of suspicious tags and inline styling. The plugin ships several built-in templates (a plain wrapper, a brand-styled wrapper, and a couple of layout variants) and a custom-template slot for operators who want their own markup. For a site whose form plugin still emits text/plain messages and whose recipients filter or render-degrade plain text, the wrapper produces noticeably better-looking notifications without touching the sender plugin’s code. For a site whose plugins already produce HTML (most modern WooCommerce or LMS workflows do), the module is dormant and the cost is the extra processing step.
The wrapper is opt-in. The trade-off is honest: a consistent house style for the cost of a sanitisation step that has not been revisited since 2024. The cost is low on a low-traffic forum and accrues over time. Compliance-sensitive operators should treat the htmlfy module as a frozen dependency, subscribe to the wp.org plugin change feed, and revisit the choice the next time WordPress core or PHPMailer ship a sanitisation-relevant change.
Logging
The logging panel is the second feature where the plugin still earns its shelf space. Sent, queued, and failed mail is recorded in dedicated tables (rather than the options or postmeta surface most logger plugins reach for), an admin grid offers filters by status, type, recipient, and date range, a preview popup renders the message body, and a retry action requeues failed messages. The depth of the panel is greater than what FluentSMTP or Post SMTP ship in their free tiers, and it does not require the log-only sidecar that Check & Log Email provides for plugins that do not include their own.
The cost is the retention story. The daily maintenance cron purges successfully sent and failed entries with a default age of 30 days, and the cleanup runs on every category by default. Operators who want long-horizon audit logs need to raise the retention window per category on install; an unattended install will start losing records after a month, regardless of whether the operator looked at them.
Free and Pro
The free build ships PHPMailer as the only sending engine, which means SMTP via the standard WordPress PHPMailer path or whatever local MTA the host provides. The Pro tier from Dev4Press adds REST API engines for SendGrid, Amazon SES, Mailgun, Mailjet, Sendinblue (Brevo), and Gmail, each as a gdmaq_core_engine subclass. Each engine ships with its own connection editor in the admin UI and is selectable per email type, so a site can queue WooCommerce orders to one engine and bbPress notifications to another. The Pro tier sits on the same paused codebase as the free build; the upgrade buys engines, not activity.
Compatibility
Contact Form 7, BuddyPress, and bbPress are explicitly supported by the detection pass and by named hooks elsewhere in the plugin. CF7 in particular benefits from the queue: a checkout form that submits during a traffic burst no longer blocks the user on a slow SMTP handshake. Gravity Forms, WPForms, Fluent Forms, and WooCommerce all route through standard wp_mail() and are captured by the same mechanism, though without the type-tagging the named integrations get.
The plugin is single-site oriented. The readme does not commit to network-wide queue behaviour on multisite, and the queue tables use the per-blog prefix rather than a network-shared one. Operators running multisite should treat the plugin as per-subsite, confirm the network admin does not surface a global queue panel, and decide on each subsite whether the queue is worth activating.
Where it sits against alternatives
The category is no longer the empty shelf it was when this plugin was first written. The mainstream SMTP plugins all ship queueing now:
- FluentSMTP includes a retry queue in its free tier and is the actively-maintained reference in the category.
- WP Mail SMTP Pro ships a delayed-send queue and the broader Awesome Motive support apparatus.
- Post SMTP ships a queue with a resend-from-log workflow and the most aggressive logging UI of the three.
The narrower siblings are also reviewed in the catalogue: Mail Queue and SMTP Mailing Queue cover the same niche with different trade-offs. For the conceptual framing of why a queue is useful in the first place, the reference is Understanding email queues in WordPress.
GD Mail Queue’s remaining edges over this field are the htmlfy wrapper, the depth of the logging panel, and the bbPress and BuddyPress integration hooks. None of those are decisive on their own. Together, on a forum-style site with a long tail of plain-text notifications and a need for richer audit logs than the mainstream plugins ship, they make a defensible case.
Assessment
The category has moved past this plugin. Active development on FluentSMTP, Post SMTP, and WP Mail SMTP Pro has closed the queueing gap GD Mail Queue was built to fill, and eighteen months without a release is a real cost. For an operator picking a queueing plugin without other constraints, the right default is FluentSMTP.
The narrower profile where GD Mail Queue still earns the install is a bbPress or BuddyPress site that specifically wants the htmlfy plain-to-HTML wrapping and the deep admin-side log, run by an operator who will monitor the wp.org changelog for compatibility breaks and who will not be surprised when the next major WordPress release requires a patch the vendor may not ship in a hurry. For that operator, the architecture is still sound, the feature set is still distinctive, and the trade is real but informed.
For the broader setup the plugin slots into, see how to set up WordPress email.
Plugin data verified June 2026 against 
wordpress.org/plugins/gd-mail-queue and the plugin source on the WordPress plugin SVN.