Why do my WordPress contact form emails go to spam?

Because they are sent by the web server through PHP `mail()`, which your domain does not authorise. The message arrives unsigned and unauthenticated from an IP that is not in your SPF record, usually with a `wordpress@` From address that does not exist.

Do I need an SMTP plugin for WordPress?

You need an authenticated transport; a plugin is just the usual way to configure one. The alternative is a properly configured MTA on the server that relays through an authenticated service — the same outcome, done by the server admin instead.

Can I just add my web server to my SPF record?

Only if you know the exact IP it sends from and it is not shared. On shared hosting you would be authorising every other site on that server to send as your domain, and it still leaves you with no DKIM signature. Fix the sending path instead.

Does WordPress support DKIM?

Not in core. The DKIM signature comes from whatever service you route the mail through, which is another reason the fix is the transport rather than a record. Once that service signs with your domain, publish its DKIM record and DMARC aligns.

What should the WordPress From address be?

A real mailbox on the same domain as your site, monitored by someone. That is what makes the domain in the From header match the domain your transport is authenticated for, which is what DMARC alignment means.

WordPress emails going to spam

WordPress is not a mail provider. The usual cause is an unauthenticated sender, not a wrong record.

What you are seeing

Contact form, password reset and WooCommerce order emails land in spam — or never arrive
From: WordPress <wordpress@example.com>
spf=none dkim=none dmarc=none header.from=example.com

What it means

WordPress does not send email. `wp_mail()` formats the message and hands it to PHPMailer, which by default calls PHP's `mail()` — and that needs a sendmail-compatible MTA on the web server. WordPress's own documentation is explicit that it provides no MTA and that "its the server administrator's responsibility to configure the MTA and the related mailing environment properly".

Whatever that local MTA is, your domain almost certainly does not authorise it. The web server is not in your SPF record, nothing signs the message with DKIM, and so the message arrives with `spf=none` or `spf=fail` and `dkim=none`. If you publish DMARC, that is your own mail failing your own policy.

The default sender makes it worse. PHPMailer sets `wordpress@` plus the site hostname, which is usually a mailbox that does not exist. It has no sending reputation, bounces go nowhere, and a From address nobody can reply to is itself a spam signal.

So this is not a record you are missing. You cannot write an SPF record that fixes it unless you know and trust the exact IP the web server sends from — and on shared hosting you do not, because that IP is shared with every other site on the box.

Why it happens

PHP `mail()` with no authenticated sender: The default path. The message leaves from the web server, over a local MTA you did not configure, with nothing attesting that it is allowed to send as your domain. Many hosts also silently rate-limit or drop this traffic.
The web server is not in your SPF record: Your SPF record lists your mailbox provider — Google Workspace, Microsoft 365 — not your hosting account. The site's mail therefore fails SPF while your ordinary mail passes, which is why "my email works but WordPress emails don't" is so common.
Nothing signs the message with DKIM: Core WordPress has no DKIM signing. Without an aligned signature, DMARC can only pass through aligned SPF, and that is the thing the previous cause has already broken.
The From address is `wordpress@yourdomain`: A non-existent mailbox with no reputation, on a domain whose real mail comes from somewhere else. Change it to a real mailbox you monitor on the same domain.
An SMTP plugin is configured, but on someone else’s domain: Routing WordPress through a personal Gmail or a generic hosting SMTP account makes SPF and DKIM pass — for *that* provider’s domain. DMARC compares against your visible From domain, so it still fails. The transport has to be authenticated for your own domain.
A contact form plugin puts the visitor in the From header: Several form plugins default to `From: <the submitter's address>` so replies work. That makes your server send as gmail.com or outlook.com, failing those domains' DMARC policies outright. Put the visitor's address in Reply-To and send From your own domain.

How to fix it

1Check what your domain actually publishes. Run the check above. Whatever ends up sending your site mail will need SPF, DKIM and DMARC to be right for your domain, so start by seeing where they stand and whether your senders align.
2Stop sending through PHP `mail()`. Configure an SMTP or API transport instead — your mailbox provider's SMTP, or a dedicated sending service. Any of the mail plugins in the WordPress directory will do this; what matters is the transport, not which plugin wraps it.
3Authenticate that transport for your own domain. Then do the provider side: publish the SPF, DKIM and DMARC records that service asks for, so the mail is signed with `d=yourdomain.com`. This is the step that turns `dkim=none` into an aligned pass.
4Set the From address to a real mailbox on your domain. Replace `wordpress@` with something that exists and is monitored, via the plugin’s From setting or the `wp_mail_from` and `wp_mail_from_name` filters. Keep the visitor’s address in `Reply-To`.
5Consider a subdomain for the site’s mail. If the site sends volume — order confirmations, newsletters — give it its own sending subdomain. That keeps its reputation and its SPF lookup budget separate from the mail your people send by hand.
6Re-check, then send one real message. Re-run the check once DNS has propagated, then use the MailVakt inbox test: trigger a real site email to a one-time address and read the headers we actually received, including the From and the DKIM result.

Questions

Why do my WordPress contact form emails go to spam?: Because they are sent by the web server through PHP `mail()`, which your domain does not authorise. The message arrives unsigned and unauthenticated from an IP that is not in your SPF record, usually with a `wordpress@` From address that does not exist.
Do I need an SMTP plugin for WordPress?: You need an authenticated transport; a plugin is just the usual way to configure one. The alternative is a properly configured MTA on the server that relays through an authenticated service — the same outcome, done by the server admin instead.
Can I just add my web server to my SPF record?: Only if you know the exact IP it sends from and it is not shared. On shared hosting you would be authorising every other site on that server to send as your domain, and it still leaves you with no DKIM signature. Fix the sending path instead.
Does WordPress support DKIM?: Not in core. The DKIM signature comes from whatever service you route the mail through, which is another reason the fix is the transport rather than a record. Once that service signs with your domain, publish its DKIM record and DMARC aligns.
What should the WordPress From address be?: A real mailbox on the same domain as your site, monitored by someone. That is what makes the domain in the From header match the domain your transport is authenticated for, which is what DMARC alignment means.

Fix this from ChatGPT or Claude

MailVakt is an MCP server, so your assistant can run this check itself, read the findings and walk you through the DNS edit. Ask it:

“My WordPress site sends from example.com and the mail goes to spam. Check the domain and tell me what the sending path is missing.”

Claude: Settings → Connectors → Add custom connector, then paste https://mcp.mailvakt.com/mcp.
Cursor and other MCP clients: add the same address as an MCP server. Setup details.

Checks are free and need no account. Sign in only to collect DMARC reports for a domain.