Mailtrap for WordPress: test outbound email without sending it

WordPress email debugging has two distinct questions. Does the SMTP transport actually work? And does wp_mail produce the message the plugin thinks it produces? Swaks answers the first by bypassing WordPress entirely. Mailtrap answers the second by accepting the message WordPress generates and refusing to forward it anywhere.

Mailtrap’s Email Sandbox is a fake SMTP server. WordPress connects, authenticates, hands over the message, and the SMTP transaction completes. Mailtrap stores the result in a web sandbox instead of relaying it. From WordPress’s perspective the send succeeded; from the recipient’s perspective nothing happened. Everything is inspectable: headers, raw source, HTML rendering, plain-text fallback, and any attachments.

For the wider WordPress email setup that Mailtrap is used to validate before flipping to a production relay, see How to set up email on WordPress.

Before you start

This walkthrough assumes:

1. The mailer plugin connects to the mail server over SMTP, not a provider HTTP API. Mailgun, SendGrid, Postmark, Amazon SES and others offer API-based send modes that bypass SMTP entirely; those configurations cannot be redirected through Mailtrap.
2. WordPress admin access and access to the mailer plugin’s settings screen.
3. A free Mailtrap account is sufficient for the walkthrough. The free tier accepts 50 captured emails per month into a single sandbox.

What Mailtrap offers beyond capture

The captured message is the point, but the sandbox surfaces it across several views: rendered HTML, plain-text alternative, raw RFC 5322 source, an HTML-render check against common email-client quirks, and a SpamAssassin-based score breakdown. For WordPress debugging the raw view is where the answers live; the HTML check and spam score are useful sanity checks but they do not predict what Gmail or Outlook will actually do with the message in production. That decision depends on the sending IP’s reputation, SPF/DKIM alignment against the production domain, and recipient-specific history, none of which Mailtrap can simulate.

Pricing

The free tier captures 50 emails per month into one sandbox. Paid tiers add sandboxes, raise monthly capture limits, retain messages longer, and unlock team sharing. Current pricing is on Mailtrap’s pricing page; the structure has shifted enough times that quoting numbers here would date the article within a quarter. The 50-emails-per-month limit becomes a real constraint only when Mailtrap is wired into a CI pipeline or a staging environment that exercises mail flows on every deploy.

Set up Mailtrap as the WordPress mailer’s SMTP server

The configuration is a credentials swap. The mailer plugin already speaks SMTP to a production mail server; pointing it at Mailtrap’s SMTP credentials instead is the entire integration. No Mailtrap-specific WordPress plugin exists, and none is needed.

1. Sign in at mailtrap.io. A default sandbox named “My Sandbox” is created on first sign-in.
2. Open the sandbox and select the Integration tab to reveal the SMTP host, port options, username, and password assigned to this sandbox. The host is sandbox.smtp.mailtrap.io and the sandbox accepts connections on ports 25, 465, 587, and 2525.
3. In the WordPress mailer plugin (WP Mail SMTP, FluentSMTP, Post SMTP, or any other plugin that exposes SMTP fields), set the SMTP host, port, encryption, username, and password to the Mailtrap values. Save.

That is the integration. WordPress will now send all outgoing mail to Mailtrap until the credentials are switched back. This setup belongs on a staging or local environment, not on a production site: every email the site generates while these credentials are active (password resets, contact-form replies, WooCommerce confirmations) gets trapped in Mailtrap and never reaches the intended recipient.

Hosts that block outbound port 25 (most shared hosts do) can use any of the other three; 587 with STARTTLS is the conventional default.

Trigger a test email from WordPress

Anything that causes WordPress to call wp_mail will do. Each path exercises a different portion of the WordPress mail pipeline; the right choice is whichever is closest to the suspected fault.

• A password reset request from the login screen. Exercises the WordPress core notification path.
• A contact form submission. Exercises the form plugin’s mail handling, which is often where the bug lives.
• A WooCommerce order confirmation (place a test order with a coupon-discounted total of zero). Exercises WooCommerce’s transactional email pipeline.
• The mailer plugin’s own “Send a test email” button. The smallest test surface: it exercises only the mailer’s SMTP path, often bypassing the wp_mail filter chain that real sends pass through. Useful for confirming the credentials work, not for reproducing a generation-layer bug.

Mailtrap captures whichever message WordPress produced and presents it in the sandbox.

Read the captured message

The Mailtrap sandbox lists captured messages chronologically. Opening a message shows the rendered view, with tabs for HTML source, plain-text alternative, raw source, spam analysis, and HTML check.

For WordPress debugging the Raw tab is where the answers live. It exposes the full RFC 5322 message including headers, where the most common WordPress email questions get answered:

• Message-ID: should contain the sending domain. If it contains the WordPress host’s domain (wordpress@<host>) instead of the production domain, replies, threading, and DKIM alignment all misbehave downstream. This is the single most diagnostic header for a WordPress site sending through a mailer plugin.
• From: and Sender: reveal whether the plugin’s “from address” setting actually applied, or whether wp_mail‘s default leaked through. A mismatch between From and Sender is the usual cause of “the email is showing up as ‘on behalf of’” complaints in Outlook.
• Reply-To: confirms that contact-form replies will return to the form submitter and not to the site owner. The classic Contact Form 7 misconfiguration shows up here.
• Return-Path: (set by the receiving server on a real send, but observable in the SMTP envelope here) is what bounces are returned to.
• Content-Type: confirms whether the message went out as HTML, plain text, or multipart/alternative with both. Missing Content-Type headers default to plain text and are a common reason HTML emails arrive looking like source code.

Newsletter plugins (MailPoet, Newsletter, and similar) add List-Unsubscribe; the raw view confirms it is set and points at a working URL or mailto: address. WooCommerce core does not add the header by default, but stores running marketing extensions or modern transactional SMTP providers often inject it to satisfy Gmail and Yahoo’s bulk-sender requirements.

What a successful Mailtrap test proves (and what it doesn’t)

A message arriving in Mailtrap proves three things:

1. SMTP credentials and transport work. WordPress connected to Mailtrap’s SMTP server, authenticated, completed the EHLO/MAIL FROM/RCPT TO/DATA dialogue, and received a 250 OK queue response. The same credentials swap will work against any other SMTP server reachable from the WordPress host.
2. The sending pipeline is intact end to end. WordPress core or the triggering plugin called wp_mail, the mailer plugin filtered the message into the SMTP transport, and the message left the WordPress process intact.
3. The message content is inspectable and matches expectations. Headers, body, and attachments can be checked against what the plugin is meant to produce.

A successful Mailtrap test does not prove deliverability. Mailtrap accepts everything; a real mailbox provider applies spam filtering, SPF/DKIM/DMARC alignment checks, sending-IP reputation scoring, and recipient-specific reputation, none of which Mailtrap simulates. A message that looks clean in Mailtrap can still land in Gmail spam, or be rejected outright at Microsoft. Mailtrap isolates the WordPress side of the pipeline. Delivery problems downstream require separate investigation, typically Swaks for SMTP-server confirmation, mail-tester for content scoring, and Google Postmaster Tools for delivery reputation.

When the email never arrives in Mailtrap

If WordPress reports a successful send but the message does not appear in the Mailtrap sandbox, the failure is between WordPress and Mailtrap’s SMTP server. The checks in this order will isolate it:

1. SMTP credentials. Each Mailtrap sandbox has a unique username and password. The most common cause of silent failure is credentials from one sandbox pasted into a mailer pointed at a different sandbox, or stale credentials left over from a rotation in the Mailtrap dashboard.
2. Outbound connectivity. The WordPress server must allow outbound connections on whichever Mailtrap port the mailer is using. Port 25 is blocked by most shared hosts and many cloud providers by default. Ports 587 and 2525 are usually open; if all four Mailtrap ports are blocked, the host’s firewall is the problem and the hosting provider is the only path to unblock it.
3. Mailer plugin error log. Every major WordPress mailer (WP Mail SMTP, FluentSMTP, Post SMTP) logs the SMTP transaction on failure. Authentication rejections, TLS handshake failures, and DNS resolution errors all surface there with the upstream server’s response line attached.
4. Free-tier quota. The free Mailtrap plan caps capture at 50 messages per month. Once the quota is exhausted, Mailtrap continues to accept the SMTP transaction but does not store the message. Check the sandbox usage counter in the Mailtrap dashboard.
5. Mailer routing rules. WP Mail SMTP, FluentSMTP, and Post SMTP all support per-sender or per-recipient routing. If a routing rule sends only some addresses through the Mailtrap-credentialled connection and others through a different connection, the symptom is “some test emails appear, others don’t.” Review the active routing rules before assuming Mailtrap is at fault.

Mailtrap’s own troubleshooting article covers additional edge cases including TLS misconfiguration and rate-limit behaviour on paid plans.