WordPress MailBaby SMTP Plugin: Setup and Testing

WordPress sends mail through PHP’s mail() function by default, which hands the message to the server’s MTA with whatever envelope sender the web server user happens to have. On a cPanel or DirectAdmin server that relays through MailBaby, that is usually fine once a few details are right. On a plain VPS or where the customer insists on their own credentials, an SMTP plugin that talks to the relay directly is the alternative. This guide covers both, and the testing that proves it works before the customer’s contact form goes live.

Short answer: On a cPanel or DirectAdmin server that already relays through MailBaby, no plugin is needed: enable “Prevent nobody from sending mail” so PHP mail leaves as the account’s authorised domain, and Exim signs and relays it. Elsewhere, configure WP Mail SMTP, FluentSMTP or Post SMTP with host relay.mailbaby.net, port 25, TLS (STARTTLS), username mbXXXXX and a forced From address on an authorised domain, ideally as WPMS_* constants in wp-config.php. Prove it with wp eval 'wp_mail(...)', then check the Exim or plugin log, the received headers and the portal log.

Option one: rely on the server relay

If the site is hosted on a panel server that already routes outbound mail through MailBaby, no plugin is needed. The messages leave through Exim, get DKIM-signed with the domain’s key, and pass through the relay like any other mail. Two things need checking.

The envelope sender must be on an authorised domain. cPanel rewrites PHP mail to the account’s primary domain by default, and the X-Source headers identify the script. Confirm from the Exim log that a WordPress message shows <= wordpress@example.com or similar, not <= nobody@hostname. If it shows the web server user, the account’s PHP sendmail_path is missing the -f argument; on cPanel enable WHM » Tweak Settings » Mail » Prevent “nobody” from sending mail so scripts are forced to send as the account, and let cPanel rewrite the sender:

whmapi1 set_tweaksetting key=nobodyspam value=1

The From: header WordPress sets is wordpress@ the site’s domain. If the site domain differs from the hosting account’s primary domain, install the free WP Mail SMTP plugin in its “Default (PHP)” mailer mode purely to set the From address and name to something on the authorised domain. This is the lowest-maintenance path and what we recommend for shared hosting.

Option two: SMTP plugin direct to the relay

For a site on a server without a relay, or a customer with their own MailBaby account, use an SMTP plugin. WP Mail SMTP, FluentSMTP and Post SMTP all work; MailBaby also publishes its own plugin that sends through the REST API rather than SMTP. The settings for the “Other SMTP” mailer in any of them:

• SMTP Host: relay.mailbaby.net
• Encryption: TLS (STARTTLS), not SSL
• Port: 25
• Authentication: on
• Username: mb12345 (no domain part)
• Password: the relay password

Store the credentials in wp-config.php rather than the database so they survive a database restore and are not visible to editors. WP Mail SMTP reads these constants:

define( 'WPMS_ON', true );
define( 'WPMS_MAILER', 'smtp' );
define( 'WPMS_SMTP_HOST', 'relay.mailbaby.net' );
define( 'WPMS_SMTP_PORT', 25 );
define( 'WPMS_SSL', 'tls' );
define( 'WPMS_SMTP_AUTH', true );
define( 'WPMS_SMTP_USER', 'mb12345' );
define( 'WPMS_SMTP_PASS', 'YOUR_PASSWORD' );
define( 'WPMS_MAIL_FROM', 'noreply@example.com' );
define( 'WPMS_MAIL_FROM_FORCE', true );

The From address must be on a domain authorised for the account, and forcing it stops form plugins from setting the visitor’s address as the sender, which would be rejected by the relay and fail DMARC anyway. Use a Reply-To for the visitor’s address instead; every major form plugin has that option.

Some hosts block outbound port 25 from web servers. If CSF’s SMTP_BLOCK is enabled on the server, PHP running as the account user cannot open port 25 and the plugin reports a connection refused. Either add the user to SMTP_ALLOWUSER in /etc/csf/csf.conf, or switch to option one so Exim makes the connection.

DKIM and the “via” label

Sign at the source where you can. With option one, the panel’s DKIM key is applied by Exim. With option two, the plugin sends directly and nothing signs the message, so MailBaby signs it with its own transport domain and Gmail shows “via mailbaby.net”. That passes DKIM but not DMARC alignment. If the customer’s domain has a p=reject DMARC policy, option one is the only correct choice on a shared server; see the DKIM transport signing guide for the reasoning.

Verify

Test from the command line so the result is not hidden behind a plugin’s success message:

cd /home/USER/public_html
wp eval 'var_dump( wp_mail( "you@example.org", "MailBaby WP test", "Test body" ) );'

bool(true) means WordPress handed the message off; it does not mean it was delivered. Then check the Exim log for option one (grep 'MailBaby WP test' /var/log/exim_mainlog after enabling subject logging, or search by the recipient), or the plugin’s email log for option two. Finally read the received message’s headers for spf=pass and dkim=pass and confirm the entry in the InterServer portal log. Configure a test submission on the actual contact form as well, since form plugins set headers that a bare wp_mail call does not.

The common pitfall is a form plugin’s “From” setting that uses the visitor’s email; the relay rejects it as an unauthorised sender, the plugin logs an error the site owner never sees, and the ticket arrives a week later as “the contact form stopped working”.

WordPress MailBaby SMTP at a glance

Official documentation: WordPress advanced administration handbook, RFC 5321 (SMTP), Linux man pages.

Related guides: MailBaby DKIM transport signing explained: why some mail shows “via mailbaby.net” · MailBaby with Plesk and Webuzo: outbound relay configuration · What is MailBaby? Outbound SMTP relay pricing, limits and how it works.

Frequently asked questions