Why your WordPress contact form emails end up in spam (and how to fix it)

Your contact form works. You tested it. The thank-you page appeared. But the email never showed up in your inbox. Or worse: it did for a while, and then it stopped.

This is one of the most common WordPress problems. WPForms alone has over 6 million active installs, Contact Form 7 has over 5 million. Millions of sites rely on form submissions arriving in someone's inbox. When they don't, leads vanish, support requests go unanswered, and nobody notices until a customer calls to ask why they never heard back.

The usual advice is "install an SMTP plugin." That's a step in the right direction, but it's not the full picture. The real problem is deeper: it's how WordPress sends email by default, and why Gmail, Outlook and Yahoo increasingly refuse to trust it.

In short: WordPress sends email through PHP's built-in mail() function, which provides no authentication, no encryption, and no reputation. In 2026, that's enough for most spam filters to flag or discard your messages. The fix involves three things: a proper From address, a transactional email service, and DNS records that prove your domain authorized the message.

Table of contents

• How WordPress sends email (and why it's a problem)
• Five reasons your contact form emails land in spam
• The Contact Form 7 trap
• Why "install an SMTP plugin" isn't the full fix
• The actual fix, step by step
• How to test your setup
• When this approach doesn't apply
• Key takeaways

How WordPress sends email (and why it's a problem)

Every email WordPress sends goes through one function: wp_mail(). Contact form submissions, password resets, WooCommerce order confirmations, plugin notifications. All of them.

Under the hood, wp_mail() is a wrapper around PHPMailer, the open-source mail library bundled in WordPress core. By default, PHPMailer sends through PHP's native mail() function, which passes the message to whatever mail transfer agent (MTA) is installed on the server. Usually Sendmail or Postfix.

That sounds fine until you consider what's missing:

• No authentication. The message arrives at Gmail's servers from a random IP address with no proof that your domain authorized it.
• No encryption. The connection between your server and the receiving mail server has no TLS by default.
• No DKIM signature. There's no cryptographic proof the message wasn't modified in transit.
• No delivery tracking. If the message is silently dropped, WordPress has no idea. wp_mail() returns true as long as PHPMailer handed it off to the local MTA; what happens after that is invisible.

The default From address makes things worse. WordPress sets it to wordpress@yourdomain.com with the sender name "WordPress." Most domains have no actual mailbox at that address. Spam filters notice.

According to WP Mail SMTP's data from over 3 million installations, sites using the default PHP mail() function see an average deliverability rate of about 64%. That means roughly one in three emails never reaches the inbox.

Five reasons your contact form emails land in spam

1. The From address doesn't match your domain's authentication

Email has two separate "From" concepts, defined in two different RFCs:

• The envelope sender (RFC 5321 MAIL FROM): used during the server-to-server SMTP transaction. This is what SPF checks. Recipients never see it.
• The header From (RFC 5322 From): the visible sender address in your inbox. This is what DMARC checks for alignment.

When WordPress sends via PHP mail(), the envelope sender is set by the server's MTA, often to something like apache@server42.hostingprovider.com. The visible From header says wordpress@yourdomain.com. SPF checks the envelope domain (the hosting provider's), not yours. Your domain's SPF record is completely irrelevant to the actual authentication check.

DMARC sees no alignment between the authenticated domain and the visible From domain. Fail.

2. You're on a shared IP with bad neighbors

On shared hosting, your site shares an IP address with dozens or hundreds of other sites. If any of those sites sends spam (or has been compromised and is sending spam without the owner knowing), the entire IP's reputation drops. Gmail and Outlook maintain real-time reputation databases for sending IPs. One bad tenant affects every legitimate sender on the same server.

You can check whether your server's IP is blacklisted using MXToolbox's blacklist checker. If it shows up on multiple lists, your emails are going to have a hard time regardless of what you do at the WordPress level.

3. There's no DKIM signature

DKIM adds a cryptographic signature to each outgoing email. The receiving server verifies it against a public key in your DNS. It proves the message wasn't tampered with and that an authorized server sent it.

PHP mail() adds no DKIM signature. Zero. The message arrives unsigned, which is a signal to spam filters that the sender hasn't bothered to authenticate. In 2024-2026, with Google, Yahoo and Microsoft all requiring DKIM for high-volume senders, unsigned mail stands out more than ever.

4. Reverse DNS doesn't match

When a mail server receives a connection, it does a reverse DNS lookup on the connecting IP. On shared hosting, the PTR record typically points to something like server42.hostingprovider.com. Your email claims to come from yourdomain.com. That mismatch is another spam signal.

You don't control the PTR record on shared hosting; your hosting provider does. And they set it to their own hostname because the IP serves many domains.

5. The email content itself triggers filters

Contact form emails have a few structural quirks that trip spam filters:

• Generic subjects like "Contact Form Submission" or "New message from your website"
• HTML formatting from the form plugin without a plain-text alternative
• Content that mirrors exactly what a visitor typed, which could contain trigger words

These content-level factors are usually minor compared to the authentication problems above, but they add up. SpamAssassin assigns points for each issue; cross the threshold (default: 5.0) and the message gets flagged.

The Contact Form 7 trap

Contact Form 7 deserves its own section because its default configuration actively causes deliverability problems.

Out of the box, Contact Form 7 sets the From field to [your-name] <[your-email]>. That uses the form submitter's name and email address as the sender. So when a visitor fills out your form with their visitor@gmail.com address, Contact Form 7 sends an email from visitor@gmail.com, sent through your WordPress server.

Think about what Gmail sees: an email claiming to come from a Gmail address, sent from a shared hosting IP that isn't Google's, with no DKIM signature from Google. From Gmail's perspective, this is textbook spoofing. The message goes straight to spam, or gets rejected entirely.

Contact Form 7's own documentation recommends using an email address on your own domain as the From address, with the visitor's email in the Reply-To header. But the default template doesn't follow this advice, and most site owners never change it.

The fix is simple. In your Contact Form 7 mail settings, change the From field to:

Your Site Name <contact@yourdomain.com>

And add the visitor's email as Reply-To:

Reply-To: [your-email]

That way, replies still go to the visitor, but the authentication chain stays within your domain.

Why "install an SMTP plugin" isn't the full fix

The standard advice for WordPress email problems is to install WP Mail SMTP (4+ million active installs) or a similar plugin. These plugins intercept the phpmailer_init hook and reconfigure PHPMailer to send through an external SMTP server instead of PHP mail().

That's genuinely better. You get an authenticated connection, TLS encryption, and a sending IP that isn't your shared hosting server. But it's not the full solution for three reasons:

SPF still needs to align. If you configure WP Mail SMTP to send through an external service, but the From address on the email is contact@yourdomain.com, then DMARC will check whether the sending service's domain aligns with yourdomain.com. Unless you've added the service to your domain's SPF record, SPF alignment fails.

DKIM needs to be your domain's. Many SMTP services sign with their own DKIM key by default (e.g., d=sendgrid.net). The DKIM signature's domain doesn't match the visible From domain. DMARC fails on DKIM alignment too. You need to set up DKIM signing for your domain with the service, which means adding DNS records.

Free tiers share IP pools. Services like Brevo's free tier (300 emails/day) and Mailgun's free tier (100 emails/day) use shared IP pools. If other free-tier users abuse the service, the pool's reputation suffers. It's a better pool than your shared hosting server, but it's still shared.

The most common misconfiguration: installing WP Mail SMTP, connecting it to a service, and not configuring DKIM or SPF in DNS. The email now routes through a different server, but it's still unauthenticated from the domain's perspective.

The actual fix, step by step

Step 1: fix the From address

The quickest win. Change the default WordPress From address to something on your own domain. You can do this in WP Mail SMTP's settings under "Force From Email," or with two lines of code:

add_filter( 'wp_mail_from', function() {
    return 'contact@yourdomain.com';
});
add_filter( 'wp_mail_from_name', function() {
    return 'Your Site Name';
});

Also update any contact form plugin settings. In Contact Form 7, WPForms, or Gravity Forms: set the From address to your domain and the visitor's email as Reply-To. Never use the visitor's address as the From address.

Step 2: choose a transactional email service

A transactional email service handles the actual sending. They maintain IP reputation, provide DKIM signing, handle bounces, and give you delivery logs.

For most WordPress sites, these are the practical options:

For a typical business WordPress site with a contact form, Brevo's free tier handles 9,000 emails per month at no cost. Postmark is worth the $15/month if deliverability is business-critical (it consistently scores 93-98% inbox placement in independent tests).

Step 3: configure DNS authentication

This is the step most guides skip, and it's the one that matters most.

After connecting your transactional email service, you need to verify your domain by adding DNS records. The service's dashboard will give you the exact records. Typically:

DKIM: one or more CNAME records that publish the service's DKIM public key under your domain. This allows the service to sign outgoing email with a key that verifies against your DNS.

SPF: add the service's include: directive to your domain's existing SPF record. For example, if you use Brevo:

v=spf1 include:sendinblue.com include:_spf.google.com ~all

DMARC: if you don't have one yet, add a monitoring record:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Start with p=none to collect reports without affecting delivery. Once you've confirmed everything aligns, move to p=quarantine and eventually p=reject. If you want guidance on that progression, our SPF, DKIM and DMARC setup guide walks through the full process.

Step 4: enable "Force From Email" in your SMTP plugin

In WP Mail SMTP (or whichever SMTP plugin you use), enable the "Force From Email" option. This prevents other plugins from overriding the authenticated From address. Without it, a contact form plugin could reset the From to the visitor's email, breaking authentication even when everything else is configured correctly.

How to test your setup

Don't guess. Test.

1. mail-tester.com: gives you a unique email address. Send a test from your contact form, then check the score. A 10/10 means full authentication. Anything below 7 needs attention.

2. Gmail header check: send a test email to a Gmail address. Open it, click the three-dot menu, select "Show original." Look for the Authentication-Results header. You want to see spf=pass, dkim=pass, and dmarc=pass.

3. MXToolbox blacklist check: enter your sending server's IP to see if it's on any blacklists. If you're using a transactional email service, this checks the service's IP, which should be clean.

4. Google Postmaster Tools: for higher-volume senders, Google's Postmaster Tools shows your domain reputation, delivery errors, and spam rate over time. Google flags domains that exceed a 0.10% spam complaint rate and blocks delivery at 0.30%.

After fixing your setup, send test messages to Gmail, Outlook and Yahoo. Check all three: they each have different filtering behavior.

When this approach doesn't apply

This guide covers the most common scenario: a WordPress site with a contact form whose emails land in spam or disappear. But there are situations where the problem is different:

• Emails aren't sent at all: that's a server-level issue, not a spam filtering issue. PHP mail() might be disabled by your host, or your SMTP credentials could be wrong. Our knowledge base article on WordPress email not sending covers that scenario.
• You're sending marketing email through WordPress: newsletters and bulk marketing email need dedicated infrastructure, list hygiene, and unsubscribe handling. A contact form SMTP setup isn't designed for that.
• Your domain is already blacklisted: if your domain (not just the IP) has a poor reputation from previous abuse, fixing authentication won't instantly restore deliverability. It takes weeks for reputation to recover.

Key takeaways

• WordPress sends email through PHP mail() by default, with no authentication, no encryption, and no delivery confirmation. About 36% of those emails never reach the inbox.
• The biggest culprit isn't your form plugin. It's the lack of SPF, DKIM, and DMARC alignment between your domain and the server sending the email.
• Contact Form 7's default configuration uses the visitor's email as the From address, which is technically spoofing and gets flagged by Gmail, Outlook, and Yahoo.
• An SMTP plugin is necessary but not sufficient. Without DNS records (SPF + DKIM) and DMARC alignment for your domain, you've just moved the unauthenticated sending to a different server.
• The complete fix: own-domain From address + transactional email service + DNS authentication records. That moves deliverability from ~64% to over 96%.

If you'd rather not manage email infrastructure yourself, professional email hosting takes this off your plate, with authentication, monitoring, and deliverability handled for you.