Skip to main content
Everything on this page lives under WP Postman → General. Pick a delivery method from the tile grid at the top, and the panel below it swaps to show only the fields that method needs. This guide covers all eight, field by field, plus the DKIM signing accordion that applies across most of them.
Not sure which method to pick? Use WP Postman, the default. It requires the least setup, doesn’t depend on an SMTP port your host might restrict, and is the only method that reports back a real Delivered status in your logs instead of just Sent or Failed.

WP Postman (the native relay)

This is what’s selected by default whenever a WP_POSTMAN_API_KEY constant is present in wp-config.php. If that constant is missing, the plugin falls back to PHP Mail on activation so your site still attempts to send something, but nothing will actually be delivered reliably until you add the key.
The API key is deliberately kept out of the database and out of the settings form. Storing send credentials as a wp-config.php constant instead of a WordPress option means the key survives a database import or a site clone without landing somewhere it shouldn’t, and it can’t be read back out through the REST API or an exported options table.

PHP Mail

No fields. Selecting this tells WordPress to fall back to its original behavior and hand mail directly to the server’s local mail() binary.
Treat this as a diagnostic fallback, not a real delivery option. It carries no SPF, DKIM, or DMARC authentication of any kind, and most consumer inbox providers either bulk-file or silently drop mail sent this way. Its only legitimate use is confirming that WordPress itself is calling wp_mail() correctly while you troubleshoot something unrelated to delivery.

SMTP.com

Routes mail through a dedicated SMTP.com relay connection on port 2525, useful if your organization already runs mail through SMTP.com for other properties.

Brevo

Connects over SMTP to smtp-relay.brevo.com. Brevo was formerly known as Sendinblue, and some older documentation and dashboard screens may still use that name.

Mailgun

Connects over SMTP, with the host chosen automatically based on your account’s region.

SendGrid

Connects over SMTP to smtp.sendgrid.net. SendGrid’s SMTP username is always the literal string apikey, which WP Postman sets automatically, so there’s no username field here.

Gmail

Connects over SMTP to smtp.gmail.com. The field names reference OAuth, but the actual authentication is standard SMTP AUTH using a Google App Password, not a full OAuth consent flow. Don’t go looking for a “Sign in with Google” button, there isn’t one.
Google enforces a rolling daily send cap on personal and Workspace accounts, commonly cited around 500 messages per 24 hours for personal Gmail and higher but still capped limits for Workspace. That ceiling makes this method unsuitable for any site sending real transactional volume, order confirmations, password resets, form notifications, all counted together. Reserve it for staging sites, internal tools, or genuinely low-traffic personal projects.

Other SMTP

The generic connector. Use this for any provider without a dedicated panel above, including Amazon SES, Postmark, or a private mail server.

Manual DKIM signing

This accordion sits below the delivery method panels and applies regardless of which method you’ve selected, with one exception: it has no effect on PHP Mail, since that path bypasses PHPMailer’s signing capability entirely. Everything else, including the native WP Postman relay, gets signed if you fill this in and enable it. This is a separate mechanism from the Auto DKIM check described in the WP Postman relay section above. That one verifies a record WP Stratos manages for you automatically. This one signs outgoing mail with a key you generate and control yourself, useful if you need DKIM under your own domain’s DNS rather than WP Stratos’s.
Publish the matching public key as a DNS TXT record before enabling this. Signing mail with a key that has no published counterpart doesn’t just fail to help, it can actively hurt: some spam filters flag a DKIM signature that doesn’t validate more harshly than a message with no DKIM signature at all.

Testing a change

Every field change is saved with the Save Changes button at the bottom of the General tab. After saving, confirm it actually works before moving on:
1

Open the Test Email tab

Go to Settings → WP Postman → Test Email.
2

Send to an inbox you can check immediately

Fill in a recipient you have access to right now, not an address you’ll check later. The subject and message fields come pre-filled, you can send them as-is.
3

Read the result banner

A success or failure notice appears at the top of the page immediately. Failures for the native relay method point you to the Debug Log tab for the full API response. Failures for SMTP-based methods show the SMTP error directly in the banner.
4

Check the Mail Log entry

Open Mail Log and confirm the attempt shows the status and delivery method you expected. This is also where you’ll catch a message that reports Sent but never actually arrives, worth a look even on a successful test.
Do this after every field change, not just after switching delivery methods entirely. A single wrong character in an API key produces a save that looks completely normal until the next real send fails.
Last modified on August 23, 2026