You Installed an SMTP Plugin and Email Still Goes to Spam. Now What?

The standard advice for WordPress email problems is to install an SMTP plugin. It is good advice and it fixes a real problem — but if you have done it and mail is still landing in spam, every article you find repeats the step you already took.

This one assumes SMTP is working. Messages are being accepted by your provider. They are arriving, in the wrong folder.

That is a different problem with a different cause, and it is not fixed in your plugin settings.

What an SMTP plugin actually fixed

Worth being precise, because it explains why you are stuck.

An SMTP plugin changes how your site hands a message to a mail service. It replaces PHP’s mail() with an authenticated connection to a provider. That fixes mail not being sent at all.

It does not change whether the receiving server trusts the message. That is decided by DNS records published on your domain, and no plugin setting can substitute for them. This is the single most common misconception in this topic: people expect the SMTP plugin to fix DNS. It is a bridge, not a DNS manager.

Find out what the receiver concluded

Stop guessing. Get the receiving server’s verdict.

1. Send a message from your site to a Gmail address.
2. Open it, click the three-dot menu, choose Show original.
3. Read the Authentication-Results header.

This is more useful than any testing tool, because it is what a receiver actually decided rather than what a tool predicts.

If all three pass

spf=pass dkim=pass dmarc=pass

Then authentication is not your problem, and further DNS edits will not help. Skip to the reputation and content section below. A surprising amount of wasted effort in this topic is people rewriting correct SPF records.

If DMARC fails while SPF and DKIM pass

This is the most common case among people who have already done the setup, and it is the alignment problem.

DMARC does not merely ask whether SPF or DKIM passed. It asks whether they passed for the domain in the From address the reader sees.

If your store sends from [email protected] but SPF passed for your provider’s own sending domain, then SPF passed and alignment failed — so DMARC fails, and a strict receiver treats the message as unauthenticated.

The fix is domain authentication at your provider: publishing their DKIM records on your domain so signatures are made in your name. Providers usually present this as optional and many users skip it because the simpler path — verifying a single sender address — is quicker. For DMARC, the simpler path is not enough.

If SPF returns permerror

Your SPF record is broken, most likely by the ten-DNS-lookup limit. The include, a, mx, ptr, exists and redirect mechanisms each count; ip4, ip6 and all do not.

Exceed ten and evaluation returns PermError, which DMARC treats as a failure. Your record looks entirely reasonable and is failing every check. Google Workspace plus a transactional provider plus a marketing platform commonly gets there, since each include can pull in further includes you never see.

Remove providers you no longer use, and replace an include with explicit ip4 ranges where the provider publishes stable ones.

If DKIM shows none

Nothing signed the message. Either DKIM was never enabled at your provider, or the selector published in DNS does not match the one signing. Providers give you the exact record; the failure is usually that it was added to the wrong DNS host.

Which leads to the most boring and most common cause of all.

The record is probably at the wrong DNS host

Before assuming anything sophisticated: confirm the record is where your domain’s DNS is actually served from.

A very common arrangement is a domain registered with one company, DNS served by another, and mail handled by a third. Records added at the registrar do nothing if DNS is served by Cloudflare.

Check your domain’s nameservers. Whoever they point to is where records must live. Everything else is a copy nobody reads.

Two related traps: a record added to the wrong hostname (many DNS panels append the domain automatically, so entering the full name produces something like _dmarc.example.com.example.com), and a record saved with extra quotation marks the panel adds for you.

Checking your DNS actually resolves

Before accepting a checking tool’s verdict, confirm it directly. Tools cache, and a cached answer during a change is genuinely misleading.

dig +short TXT yourdomain.com
dig +short TXT _dmarc.yourdomain.com
dig +short TXT selector._domainkey.yourdomain.com

Reading these yourself resolves three ambiguities a tool cannot:

• Two SPF records. The first command returns more than one line starting v=spf1. This is invalid, both fail, and it is easy to create by adding a provider rather than merging one.
• Nothing at all. An empty result usually means the record is published somewhere your nameservers do not point.
• Stray quoting. Some DNS panels save values with extra quotation marks, producing a record that looks right in the interface and is malformed in DNS.

To find where your DNS is actually served — the question behind most “I added it and nothing happened” reports:

dig +short NS yourdomain.com

Whatever that returns is the only place records count.

What to tell a client, or a boss

This problem is often being explained to somebody who wants a date rather than a diagnosis, so it helps to have the summary ready.

The honest version is roughly: the site is sending correctly, but receiving servers cannot yet verify the mail is genuinely from us. That verification is DNS configuration, which lives with whoever manages our domain rather than in the website. Once corrected it takes up to a day to take effect, and if our domain has been sending unverified mail for a long time, trust rebuilds over a few weeks rather than immediately.

Two expectations worth setting explicitly, because both cause a second round of panic otherwise:

• It will not be instant. Authentication applies to the next message; reputation recovery does not.
• It is not a plugin problem, and changing plugins will not fix it. The most common reaction to this situation is to try a different SMTP plugin, which changes nothing because the missing piece is in DNS.

If authentication passes and mail is still filtered

Now the causes are reputation and content.

• You are sending from a free-mail domain. A From address at Gmail or Yahoo will fail DMARC no matter what you configure, because those domains publish policies telling receivers to reject mail sent on their behalf by third parties. Order emails must come from your own domain.
• Shared IP reputation. On a shared sending pool, other senders’ behaviour affects you. Providers manage this, but a cheap provider manages it less well.
• The address previously bounced or complained. Check your provider’s suppression list. A test address that once bounced can be suppressed permanently, so your tests fail while customers receive mail normally. This one wastes a lot of time because it looks like a general failure.
• Content signals. Transactional mail rarely trips these, but a message that is one big image, or full of link shorteners, or sent from a brand-new domain with no history, will be treated cautiously.
• No sending history. A domain that has never sent mail and suddenly sends hundreds looks like a compromised account. Volume ramps.

How long a fix takes to show up

A realistic expectation, because impatience here causes people to undo correct changes.

DNS changes take effect as caches expire. Most resolvers respect your record’s TTL, so a one-hour TTL means roughly an hour, but some caches are slower. Waiting a full day before concluding a change did not work is reasonable; re-editing the record after twenty minutes is not.

Authentication fixes apply immediately to messages sent after propagation. The next message either passes or does not, and the header tells you which.

Reputation recovers slowly. If your domain has been sending unauthenticated mail for months, fixing authentication does not restore trust overnight. Expect weeks of consistent, authenticated sending. This is the part people find hardest to accept, and it is why the order of operations matters — fix authentication first so the clock starts.

When only one provider filters you

A common and confusing pattern: mail reaches Gmail perfectly and lands in junk at Microsoft, or vice versa. This does not mean your setup is half-broken.

Providers weight signals differently. Microsoft is notably more aggressive with unfamiliar senders and weights IP reputation more heavily; Gmail leans harder on domain reputation and engagement. So a new domain on a good shared IP may sail into Gmail and be quarantined by Outlook.

Two things actually help here, and neither is a DNS change:

• Consistency. Send from the same domain and the same infrastructure over time. Rotating providers to chase a fix resets whatever reputation you were building.
• Engagement. Transactional mail is opened, which is a strong positive signal. Mixing bulk marketing into the same domain and IP dilutes it, which is a good argument for sending marketing from a subdomain.

If a specific corporate recipient blocks you, the fastest route is to ask them to allowlist your domain. Their administrator can do it in minutes, and no amount of work on your side will override a local rule.

What actually moves the needle, in order

Once authentication passes, the remaining levers are limited and worth ranking honestly, because most advice at this stage is folklore.

1. Send from your own domain, always. The single biggest factor, and non-negotiable.
2. Keep bounce rates low. Repeatedly sending to dead addresses is one of the strongest negative signals there is.
3. Separate marketing from transactional. A subdomain for bulk mail protects the reputation of your receipts and password resets.
4. Send consistently. Volume spikes from a domain with no history look like a compromised account.
5. Include a plain-text part. Cheap, and a mail-shaped message with both parts is marginally more trusted than an HTML-only one.
6. Avoid link shorteners. They are heavily abused and carry a real penalty.

Notably absent: spam-word lists. Avoiding the word “free” has negligible effect on transactional mail, and time spent rewording a receipt is time not spent on the six items above.

Why it comes back

The frustrating part of deliverability is that fixing it is not permanent. Records get edited during an unrelated migration. Providers rotate DKIM keys. A plugin update changes a From address. Someone adds a second SPF record instead of merging into the first, and both stop working.

None of this announces itself. Mail keeps sending, and quietly stops being trusted.

This is the case for checking on a schedule rather than after a complaint. NimblyMail audits six pillars — SPF, DKIM, DMARC, PTR, connectivity and queue health — weekly, reads the expected SPF include and DKIM selector from the provider you actually configured so it can name the specific missing record, and can be re-run on demand. It will not improve a reputation problem, but it means the DNS half of this article stops being something you have to remember to re-check.

In order

1. Read Authentication-Results from a real Gmail delivery.
2. All three pass? Stop editing DNS — it is reputation or content.
3. DMARC failing alone? Fix alignment with domain authentication.
4. SPF permerror? You are over ten lookups.
5. DKIM none? Check the record is at the DNS host your nameservers point to.
6. Sending from your own domain, never a free-mail address.
7. Check the provider’s suppression list before believing a test failure.
8. Put the whole thing on a recurring check.