A WordPress site sending spam is an outbound incident, not just an email-delivery problem. First determine whether messages are being generated by WordPress, by a compromised SMTP/API credential, or directly by the hosting mail service.
Identify the actual sender path
Match timestamps from the mail provider or server queue with WordPress application logs, form submissions and scheduled events. Record sender, recipient pattern, subject family and the account or API key used to submit mail.
Contain the queue without destroying evidence
- Pause the confirmed sending route when abuse is still active.
- Preserve a sample of queue metadata and provider logs.
- Do not delete all queued mail until legitimate transactional messages are separated.
- Check deliverability reputation and provider restrictions after containment.
Where unwanted mail commonly originates
- Compromised contact or registration flows.
- A plugin or theme with injected mail-sending code.
- Scheduled callbacks that keep generating messages.
- Stolen SMTP or transactional-email API credentials.
Find the writer before rotating everything
If mail appears on a schedule, compare malicious WordPress cron jobs. If code runs before normal plugins or keeps returning, inspect MU-plugin persistence. Rotate SMTP/API credentials once the active source is contained so new secrets are not immediately exposed again.
Rebuild a trustworthy outbound path
- Remove the malicious or abused sending source.
- Patch or replace the vulnerable component.
- Rotate mail and privileged credentials.
- Restore only expected transactional flows.
- Monitor queue volume and provider events for recurrence.
Do not simply disable wp_mail forever
That can break password resets, order emails and alerts while leaving a compromised SMTP credential untouched.
Verification after containment
Close the incident when unsolicited mail stops at the provider, expected transactional mail still works, no scheduled or hidden sender recreates the queue, and the account’s reputation or provider status is recovering.
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.