WordPress Emails Going to Spam: 6 Steps to Fix It

Your contact form says "message sent," but the email lands in spam, or never shows up at all. WordPress emails going to spam is one of the most common problems on small business sites, and it is almost always an identity problem, not a form problem.

The fix at a glance: stop sending with the default PHP mail, send through a real mail service, use a From address on your own domain, publish SPF, DKIM and DMARC records, then test with a real inbox. Here is the order to work in.

1. Know the cause of WordPress emails going to spam

By default, wp_mail() hands your message to PHP's mail() function. It does not log in to anything, and it does not prove who you are. The WordPress developer reference also warns that a true result does not mean the message arrived. It only means the request was processed without errors.

If you set no From address, WordPress uses wordpress@ plus your site's domain. Mailbox providers see a message from a server that has no proof it may send for that domain. That looks like spam.

The rules are also stricter now. Google's email sender guidelines say all senders should set up SPF or DKIM. Senders who send more than 5,000 messages a day to Gmail need SPF, DKIM and DMARC. Most small sites send far less, but the same setup is the safest way to reach the inbox.

2. Send through a real mail service, not PHP mail

The biggest single fix is to change how WordPress sends. An SMTP plugin makes wp_mail() log in to a proper mail service, so the message is signed and trusted.

WP Mail SMTP is a free option with a setup wizard. Its free version supports many mailers, including Gmail and Google Workspace SMTP, Brevo, Mailgun, Postmark, SendGrid and a generic "Other SMTP" option. API-based mailers also work when your host blocks SMTP ports.

Pick the service that fits the client. If the business already pays for a mailbox, use that. If the site sends a lot of form or shop emails, use a sending service built for it.

If a message never arrives at all, log the error. WordPress fires the wp_mail_failed action when sending fails, and it passes you the error message:

add_action( 'wp_mail_failed', function ( $error ) {
    error_log( 'Mail failed: ' . $error->get_error_message() );
} );

3. Use a From address on your own domain

Set the From address to a real mailbox on your domain, such as info@yourdomain.com. Do not leave the default wordpress@ address, and do not use a free-mail address you do not control.

The same goes for contact forms. Do not put the visitor's email in the From field. Put your own address in From, and put the visitor's address in Reply-To. wp_mail() supports both headers. Google's guidelines also ask for a single address in the From header.

Developers can also set the address in code with the wp_mail_from and wp_mail_from_name filters.

4. Add an SPF record

SPF is a DNS TXT record that lists the services allowed to send mail for your domain. It always starts with v=spf1.

Your mail service shows you the exact value. It usually looks like this:

v=spf1 include:your-mail-service.example ~all

Three rules help here. Each domain has its own SPF record. Add every sending service as an include: part of that one record, up to 10 include: tags. And end with ~all, which is what Google recommends.

DNS changes can take time. Google says SPF can take up to 48 hours to start working, so test the next day if the first test fails.

5. Turn on DKIM and add a DMARC record

DKIM adds a digital signature to each message. Your mail service gives you a DKIM record to add to your DNS. Google recommends 2,048-bit keys when your provider supports them.

DMARC sits on top of SPF and DKIM. It checks that the domain they verify matches the domain in your From address, and it tells receivers what to do when a message fails. According to dmarc.org, the policies are none (monitor only), quarantine (treat as suspicious, often the spam folder) and reject. Start with none:

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

The rua tag sets where summary reports go. Once the reports show only your real senders, you can move to a stricter policy.

If your DNS is on Cloudflare, the steps are the same for every record: open the DNS Records page, select Add record, choose the type (TXT for SPF, DKIM and DMARC), fill in the fields and select Save. TXT and MX records are always DNS-only. Cloudflare also recommends DNS-only for records used for email routing, so do not proxy a mail host. The proxy status guide explains it. For the wider picture, see WordPress security basics with Cloudflare.

6. Test like a real visitor

Do not trust the "message sent" screen. Send a real test from the form to a Gmail address you control, then open the message, select More next to Reply, and choose Show original. The header view lists SPF, DKIM and DMARC results. You want to see a pass for all three.

Then check the basics:

• The message arrived in the inbox, not spam.
• The From name and address look right.
• Pressing Reply goes to the visitor, not to your own address.
• A second test to a different provider also arrives.

If one check fails, fix that one thing and test again. Changing five settings at once makes it hard to know what worked.

When to get help

Get help if the records look right but mail still fails, if your host blocks outgoing mail, or if the domain has several senders (the website, a newsletter and a help desk) that fight over one SPF record. Email setup touches DNS, hosting and the site, so one wrong record can break all three.

If you would like someone to set this up and keep it healthy, see my WordPress maintenance service or send me a message.