Website Email Problems

Website Email Goes to Spam

Intermediate Risk: medium

Last reviewed August 7, 2026

Hosting access may not be needed Database access usually not needed

Direct answer

Website mail lands in spam when receiving providers do not trust the sender—usually missing or misaligned SPF/DKIM/DMARC, a From address that does not match the sending domain, or a poor sending IP reputation—not because the contact-form plugin “broke.”

Delivery into spam is different from mail that never leaves the server: the SMTP or PHP handoff often succeeds, then Gmail, Microsoft 365, or Yahoo files the message as junk. Fix authentication DNS first, align the visible From domain with the signing domain, and separate transactional site mail from bulk marketing. This guide focuses on deliverability after send, alongside the “not sending” and SMTP auth guides for transport failures.

Intermediate

Key facts

Verifiable numbers and definitions — each claim links to its source.

Gmail requires all senders to personal Gmail accounts to authenticate with SPF or DKIM. (Gmail sender guidelines)
Senders of more than 5,000 messages per day to Gmail must also publish DMARC for their sending domain. (Gmail sender guidelines)
Google asks senders to keep Postmaster Tools spam rates below 0.3% to protect delivery. (Gmail sender guidelines)

What the error means

Inbox providers score each message using domain authentication, content signals, and IP reputation. SPF publishes which hosts may send for your domain; DKIM attaches a cryptographic signature; DMARC tells receivers what to do when those checks fail and whether the From domain aligns with the authenticated domain. WordPress sites commonly fail these checks when they send via PHP mail() on a shared host IP while the From header claims `@yourdomain.com`, when two SPF TXT records conflict, or when a transactional provider’s `include:` was never added. Marketing blasts, purchased lists, or a previously abused shared IP make filtering worse even after DNS looks correct. Reading the raw message headers (Authentication-Results) shows pass/fail for SPF, DKIM, and DMARC far faster than reinstalling form plugins.

Common symptoms

Form, WooCommerce, or notification mail arrives only in spam/junk—not the primary inbox
Gmail shows a “via” subdomain or warns that it could not verify the sender
Microsoft 365 places mail in quarantine or junk while a personal Gmail inbox receives it (or the reverse)
Mail-log or SMTP plugin reports success, yet recipients still dig through spam
Messages that used to inbox started landing in junk after a DNS or host change
Same content from a mailbox provider (Google Workspace / Microsoft 365 webmail) inboxes, but site-sent copies do not
Bulk newsletter and transactional order mail share one identity and both suffer filtering

Most likely causes

01 Missing, incomplete, or duplicate SPF TXT records for the real sending hosts
02 DKIM not published or not signing with a domain that aligns to the From address
03 No DMARC record, or a policy that does not match how the site actually sends
04 From address spoofs Gmail/Yahoo or a domain the server is not authorized to use
05 Shared hosting IP already listed on public blocklists or abused by neighbors
06 Spammy subject lines, URL shorteners, or malware-adjacent content triggers filters
07 Mixing marketing campaigns with transactional SMTP credentials on the same domain identity

What changed before the problem started

DNS edited when adding Google Workspace, Microsoft 365, or a marketing platform—old SPF overwritten or duplicated
Site moved to a new host or began sending through a new SMTP/API provider
From address changed in WordPress, WooCommerce, or the form plugin
Transactional provider account newly created with zero sending reputation
DMARC moved from p=none to quarantine/reject before all senders were aligned
Newsletter tool started sending as the same root domain as order confirmations

Troubleshooting steps

01
Prove the message was accepted, then read Authentication-Results
Send a test to an inbox you control. If nothing arrives anywhere, fix transport first (SMTP / PHP mail). If it sits in spam, open the raw source/headers and note SPF, DKIM, and DMARC pass/fail lines. That single header block decides whether you edit DNS, From alignment, or content—not the form plugin.
02
Align From with a domain you control and authorize
Set WordPress, forms, and WooCommerce to send From an address on your domain (for example orders@yourdomain.com). Stop sending “from” a personal Gmail address through the web server. Prefer one site-wide SMTP or transactional API so every plugin inherits the same identity.
03
Publish one correct SPF record that includes every real sender
At your DNS host, keep a single SPF TXT for the apex (or sending subdomain). Merge includes for Google, Microsoft, your host, and your transactional provider instead of creating a second SPF record. Competing SPF records cause unreliable authentication and spam placement.
04
Enable DKIM for the provider that actually sends site mail
Add the DKIM CNAME or TXT records your SMTP/API or mailbox provider supplies, wait for DNS to propagate, and resend a test. Confirm headers show dkim=pass with a domain that matches (or is a legitimate parent of) the From domain.
05
Add DMARC in monitor mode before enforcing
Publish a DMARC TXT at `_dmarc` with `p=none` and a rua address you read. Watch reports for unexpected senders. Only move to quarantine or reject after SPF and DKIM pass for every legitimate source—including the WordPress transactional path.
06
Separate transactional mail from marketing and check IP reputation
Keep password resets, leads, and order mail on a transactional provider. Use a dedicated marketing tool (and ideally a subdomain) for newsletters. If the shared host IP is blocklisted, shifting transactional mail to SES, Postmark, Mailgun, or similar isolates reputation from noisy neighbors.

Prove the message was accepted, then read Authentication-Results

Send a test to an inbox you control. If nothing arrives anywhere, fix transport first (SMTP / PHP mail). If it sits in spam, open the raw source/headers and note SPF, DKIM, and DMARC pass/fail lines. That single header block decides whether you edit DNS, From alignment, or content—not the form plugin.

Align From with a domain you control and authorize

Set WordPress, forms, and WooCommerce to send From an address on your domain (for example orders@yourdomain.com). Stop sending “from” a personal Gmail address through the web server. Prefer one site-wide SMTP or transactional API so every plugin inherits the same identity.

Publish one correct SPF record that includes every real sender

At your DNS host, keep a single SPF TXT for the apex (or sending subdomain). Merge includes for Google, Microsoft, your host, and your transactional provider instead of creating a second SPF record. Competing SPF records cause unreliable authentication and spam placement.

Enable DKIM for the provider that actually sends site mail

Add the DKIM CNAME or TXT records your SMTP/API or mailbox provider supplies, wait for DNS to propagate, and resend a test. Confirm headers show dkim=pass with a domain that matches (or is a legitimate parent of) the From domain.

Add DMARC in monitor mode before enforcing

Publish a DMARC TXT at `_dmarc` with `p=none` and a rua address you read. Watch reports for unexpected senders. Only move to quarantine or reject after SPF and DKIM pass for every legitimate source—including the WordPress transactional path.

Separate transactional mail from marketing and check IP reputation

Keep password resets, leads, and order mail on a transactional provider. Use a dedicated marketing tool (and ideally a subdomain) for newsletters. If the shared host IP is blocklisted, shifting transactional mail to SES, Postmark, Mailgun, or similar isolates reputation from noisy neighbors.

When to stop troubleshooting

Escalate when authentication passes in headers but major providers still junk every message, the domain or IP is listed on blocklists you cannot clear, or DMARC reports show senders you do not recognize (possible spoofing or compromise). Hand off current SPF/DKIM/DMARC text, a sample message with headers, and which inbox providers fail.

Information to collect before requesting help

01 Which message types land in spam (forms, orders, password resets, all)
02 Raw message headers or Authentication-Results snippet from a spam-folder copy
03 From address and SMTP/API provider in use
04 Full current SPF TXT and whether DKIM/DMARC exist
05 Hosting company and DNS host
06 Recent DNS, host, or From-address changes
07 Whether mailbox-sent mail from the same domain inboxes normally

How a professional repairs the problem

We separate “never sent” from “sent but filtered,” then repair SPF/DKIM/DMARC alignment for the WordPress sending path, wire a domain-aligned transactional sender, and retest against Gmail and Microsoft inboxes with header proof. Marketing traffic is split off when it is poisoning transactional reputation.

Frequently asked questions

If mail is in spam, is WordPress broken? +

Usually not. The site handed the message off successfully; the receiver mistrusts the sender identity or IP. Fix authentication and alignment before rebuilding forms.

Do I need SPF, DKIM, and DMARC? +

For reliable inboxing, plan on all three. SPF and DKIM authenticate; DMARC sets policy and requires alignment with the From domain. Major providers increasingly expect this trio for domain senders.

Can two SPF records cause spam placement? +

Yes. Receivers need a single SPF policy. Two TXT SPF records are invalid in practice—merge every sender into one string.

Will a new SMTP plugin alone fix spam folder delivery? +

Only if it also brings proper domain authentication. Pointing SMTP at a provider without publishing their SPF/DKIM records often reproduces the same junk placement.

Why does mail inbox for me but spam for customers? +

You may have trained your own inbox, or providers score differently. Always test at least two recipient ecosystems (for example Gmail and Microsoft 365).

Is this the same as “WordPress emails not sending”? +

No. “Not sending” means transport or auth failed before delivery. “Goes to spam” means delivery occurred and filtering decided junk. Use both guides when symptoms mix.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

You will receive a clear explanation of the likely cause.
We will tell you if the issue falls outside our repair scope.
No additional work will be performed without approval.
A backup should be created whenever access and website condition allow it.

Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.