What matters first: A WordPress site can generate spam through wp_mail, a vulnerable form, a malicious PHP mailer, a compromised SMTP account or a script outside WordPress.
What this symptom actually tells you
Mail volume, message headers, queue records and file timestamps identify the sending path. Changing the From address does not remove a malicious sender.
Capture evidence before changing anything
- Pause or rate-limit outbound mail while preserving queue and provider logs.
- Collect sample headers, envelope sender, authentication results and timestamps.
- Search web and mail logs for the originating script, account or API key.
- Inspect forms, users, cron, uploads and recently changed PHP files.
Most common causes
- Compromised site code: A backdoor or mailer script sends directly.
- Abused public form: Bots exploit an open relay-like form or recipient field.
- Stolen SMTP/API credential: Mail originates from the provider without touching WordPress.
- Shared hosting compromise: Another site under the same account generates the queue.
Safe diagnostic and repair sequence
- Revoke or rotate mail credentials and invalidate exposed keys.
- Remove malicious scripts and patch the vulnerable form or component.
- Add recipient allow-lists, nonce, rate limits and bot controls where appropriate.
- Restore sending gradually while monitoring bounces, suppressions and provider events.
How to choose between the likely causes
Do not treat Compromised site code and Abused public form as interchangeable. A backdoor or mailer script sends directly. By contrast, bots exploit an open relay-like form or recipient field. Use two checks to separate them: Pause or rate-limit outbound mail while preserving queue and provider logs; and collect sample headers, envelope sender, authentication results and timestamps. Those observations usually show whether the next safe move is to revoke or rotate mail credentials and invalidate exposed keys or to preserve the current state and widen the investigation.
On a compromised site, containment and cleanup are separate decisions. Preserve the suspicious artefact and access logs before removing persistence, then rotate credentials only after the active path has been closed. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.
What not to do
Do not delete the mail queue before preserving samples. Headers and submission metadata are often the fastest route to the source.
How to verify the repair
- Outbound volume returns to the expected baseline.
- Only legitimate applications can authenticate and send.
- No spam script, abused form path or compromised credential remains.
A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.
WP REPAIR INCIDENT STANDARD
Safe intervention sequence
Mail volume, message headers, queue records and file timestamps identify the sending path. Changing the From address does not remove a malicious sender.
- Pause or rate-limit outbound mail while preserving queue and provider logs.
- Collect sample headers, envelope sender, authentication results and timestamps.
- Search web and mail logs for the originating script, account or API key.
- Inspect forms, users, cron, uploads and recently changed PHP files.
What must be verified
- Outbound volume returns to the expected baseline.
- Only legitimate applications can authenticate and send.
- No spam script, abused form path or compromised credential remains.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Will changing the site's From address stop the spam emails?+
No. Changing the From address does not remove a malicious sender or close the path it uses to send mail; it only changes a header on messages that are still being generated by the same compromised source.
Is it safe to delete the mail queue right away to stop the flood?+
Not before preserving samples first. Message headers and queue metadata are often the fastest way to trace the sending path back to its source, so deleting the queue before capturing that evidence can make the root cause much harder to identify.
Could the spam be originating without WordPress even being directly involved?+
Yes. A stolen SMTP account or API credential can be used to send mail through the provider directly, with no request ever touching WordPress code, which is why the sending path shouldn't be assumed to run through wp_mail by default.
How would I tell a compromised form apart from actual malicious code on the server?+
An abused public form typically shows bots exploiting an open relay-like field or recipient parameter, while compromised site code involves a backdoor or mailer script sending mail directly regardless of form submissions. Comparing message headers, envelope sender, and authentication results against web and mail logs identifies which pattern matches the traffic.