The MailHawk plugin is the only way to send mail through the MailHawk service. It is not a service-agnostic mailer like WP Mail SMTP, FluentSMTP, or Post SMTP. There is no MailHawk SMTP host to point a generic mailer at, no API key to paste into another plugin, no alternative client. The plugin and the service ship as a single product, and choosing one commits you to the other.
That single-service architecture is the defining choice. Every other mailer plugin in the category exists to abstract a choice between providers; the MailHawk plugin exists to eliminate that choice.
Vendor and heritage
The plugin is developed by Groundhogg Inc., the company behind the 
Groundhogg CRM plugin for WordPress, and is the work of Groundhogg’s founder Adrian Tobey. MailHawk began as the sending infrastructure for Groundhogg campaigns and expanded to general WordPress transactional and marketing mail. The lineage is visible in the design choices: per-site account binding, in-admin DNS panel, and service-side features (quarantine, blacklist management, bounce handling) that matter more for CRM-driven sending than for the average transactional flow.
The plugin is free on wp.org; the MailHawk service it requires is paid, and the MailHawk service review covers pricing and deliverability assessment.
What installing it gets you
The wp.org listing reports 300+ active installs at version 1.3.5, last updated September 2025. The setup flow is short because the plugin removes the decisions a generic mailer asks you to make:
- Account connection through an in-plugin authorisation flow. There is no SMTP host, port, encryption, or credential field to fill in; the plugin links the WordPress install to a MailHawk account directly.
- DNS records surfaced in the WordPress admin. The plugin generates the SPF and DKIM values for the connected domain and displays them on the settings page, so the operator can copy them into a DNS provider without visiting an external dashboard. The WordPress email DNS guide walks through the records themselves for operators who want the longer version.
- Email logging with 14-day retention. Every send is recorded with recipient, subject, status, and timestamp. Failed sends can be resent from the log.
- Bounce handling via service-side webhooks, surfaced inside the WordPress admin rather than left in an external interface.
- Test email from the settings page to confirm authentication and delivery after configuration.
- Multisite and WaaS support for hosts and agencies binding sub-sites to the same MailHawk account family.
The admin surface area is deliberately small. There are no per-from-address routing rules, no fallback connections, no provider menus, no OAuth credential setup for third-party identity providers. Those features have nowhere to live in a plugin that connects to exactly one service.
The lock-in trade-off
Leaving MailHawk is two changes rather than one. A standard configuration on a competing stack pairs a generic mailer plugin (WP Mail SMTP, FluentSMTP, Post SMTP) with a standalone SMTP service (Postmark, SMTP2GO, or any other relay). Changing service in that configuration means changing credentials inside the existing mailer plugin and updating DNS. The plugin stays. The site keeps its logs, its routing rules, and its admin surface.
With MailHawk, leaving the service means uninstalling the plugin and installing a different one. The historical email log inside the MailHawk plugin disappears with it; routing logic, if any was ever needed, has to be configured fresh in the replacement. There is no in-place fallback.
This is not a hidden cost. It is the direct consequence of the architecture, acceptable to operators who picked the plugin for its setup simplicity and not acceptable to operators who expected the plugin and the relay to be independent components.
The Groundhogg fit
The case where the lock-in stops being a cost is the Groundhogg installation. Groundhogg’s marketing-automation features (quarantine for suspect sends, blacklist management, bounce-driven list hygiene) integrate with the MailHawk plugin’s service-side counterparts because both products were designed against the same infrastructure. A Groundhogg site sending campaigns through a generic mailer to a third-party relay loses some of that integration. A Groundhogg site sending through MailHawk gets it without configuration.
The WaaS (WordPress-as-a-Service) case is similar in shape. A host offering managed WordPress sites can bind every sub-site to one MailHawk account family, keep DNS panels visible inside the customer admin, and avoid handing out SMTP credentials altogether. The plugin’s multisite handling is built around this configuration, with sub-site binding to a shared MailHawk account family.
Assessment
The MailHawk plugin is the right install for three readers:
- Groundhogg CRM users, for whom the plugin and the service together extend the CRM’s campaign infrastructure rather than competing with it.
- WaaS operators, who benefit from binding many WordPress installs to a single MailHawk account family with in-admin DNS surfaces.
- Non-technical operators who would otherwise fall back to PHP
mail()because SMTP configuration is unfamiliar. The credential-free setup makes the MailHawk plugin a low-friction alternative to misconfigured sending; the MailHawk service review covers whether the price is competitive at this volume.
The cases where a generic mailer plugin pointed at a standalone relay is the better default are about the plugin decision, not the relay:
- Operators who want provider independence are better served by FluentSMTP or WP Mail SMTP against a relay of their choice. Changing sending services later means changing credentials, not changing plugins.
- Operators already comfortable configuring SMTP gain nothing from the in-plugin authorisation flow and lose the ability to run multiple connections from one plugin (transactional through one provider, marketing through another, by from-address).
- Operators sending mail from sources outside
wp_mail()(a separate marketing tool, a hosted form vendor, an external CRM) need a routing layer and per-connection rules the MailHawk plugin does not provide.
For the Groundhogg and WaaS configurations the MailHawk plugin is the natural sending path. For everyone else, the MailHawk service review is the right place to weigh the relay itself; the plugin is downstream of that decision.
For the broader setup the plugin slots into, see how to set up WordPress email.
Plugin data verified June 2026 against 
wordpress.org/plugins/mailhawk and 
mailhawk.io. Tested against version 1.3.5. The companion MailHawk service review covers pricing and deliverability assessment for the sending service the plugin connects to.