Finding the Mailer Script Sending Spam From Your Server

By Glenn Lyvers · Updated September 20, 2026 · 4 min read

Your host has sent you a warning, or throttled your outgoing mail, or suspended the account outright. Somewhere in your site is a script quietly pushing out thousands of messages an hour, and nobody has told you which file it is. Finding it is a more tractable problem than it sounds, because mail leaves traces in several places and the intersection of those traces usually points straight at the culprit.

Why your server is worth hijacking

Spam needs somewhere to send from, and mail sent through a legitimate hosting account carries far more credibility than mail from a known bad source. Your domain has a history, your server has a reputation with the big mailbox providers, and your outgoing mail is not automatically suspicious. That is the entire value of your account to a spammer.

It also costs them nothing. A single uploaded PHP file with a mail function and a list of addresses will run as fast as your server allows, and the consequences — blacklisting, suspension, a damaged sending reputation — all land on you rather than on them.

Start with the mail logs

Your mail logs are the most direct evidence available and most control panels expose them. What you want is the script path recorded against outgoing messages: many server configurations log the working directory or the script that called the mail function, and that single field frequently ends the investigation on the spot.

If your control panel has a mail queue viewer, look at the queued messages themselves. The headers often include an X-PHP-Script style line naming the file and the calling address. Even without that, the sender addresses, subjects and volume patterns tell you when the sending started, which is the timestamp you will use next.

Match against file timestamps

Once you know roughly when the sending began, list files by modification time and look at everything changed in the surrounding window. On a site that has not been updated in weeks, a handful of files touched on the day the spam started is a very short list to review.

Pay particular attention to PHP anywhere it does not belong — the uploads directory above all, which my guide on PHP files in uploads covers, plus plugin folders whose names look plausible but whose contents do not match anything you installed. Cross-reference with your access logs: a POST request to an unfamiliar path, repeated at intervals matching the send volume, is your mailer being driven.

Searching the code

Search the whole site for mail-sending functions — PHP's own mail function, and the classes bundled with common mailer libraries. Most hits will be legitimate, since your contact form and WordPress itself send mail, so the job is to account for each one rather than to find the only match.

The suspicious ones look different: mail calls in a file with no other purpose, headers assembled from request parameters, recipient lists read from a file or a remote URL, and the usual obfuscation of encoded strings and runtime-assembled function names. My guide on obfuscated code covers unwrapping those safely so you can confirm before deleting.

It is not just the one file

A mailer got onto your server somehow, and whatever put it there is the actual problem. Expect a web shell or backdoor nearby, and check for administrator accounts you did not create. Also check your legitimate mail configuration: stolen SMTP credentials stored in a mail plugin are a completely separate way to send spam in your name, and deleting a script does nothing about them. My guide on stolen SMTP credentials covers that case.

Do the full pass — core, plugins and theme replaced from clean sources, database checked, credentials rotated, entry point closed — rather than stopping the moment the sending stops.

Repairing your mail reputation

Stopping the spam does not automatically restore your ability to send. Your domain or server IP may be on one or more blocklists, and mailbox providers may keep treating your mail as suspicious for a while. Delisting requests generally succeed once the sending has genuinely stopped, and my guide on email deliverability after a hack covers the order to do them in.

This is also the right moment to get your authentication records in order, since correct SPF, DKIM and DMARC both speed up recovery and limit the damage next time — that is covered in rebuilding SPF, DKIM and DMARC. If the account is suspended and you need it resolved quickly, hosting suspensions covers what hosts want to see, and my malware removal service handles the whole sequence.

Common questions

How do I find which file is sending the mail?

Start with your mail logs and queued message headers, which on most hosting setups record the calling script path. Combine that with file modification times around when the sending started, and with access log entries showing repeated POST requests to an unfamiliar path. The intersection of those three usually identifies the file quickly.

Can I stop the spam without finding the script?

You can slow it down by disabling outgoing mail or taking the site offline, and that is a reasonable emergency measure while you investigate. It is not a fix, though — the script is still there, and so is whatever installed it. Hosts generally want evidence of an actual cleanup before restoring a suspended account.

Why is my domain blacklisted even after I cleaned it?

Blocklists react to observed behaviour and do not automatically notice that you fixed the problem. Most require a delisting request, and most will grant one provided the sending has genuinely stopped. Requesting delisting while spam is still going out simply burns your credibility with that list.

Could this be coming from a stolen SMTP password instead?

Yes, and it is worth ruling out. If your site stores SMTP credentials in a mail plugin and those were read, spam can be sent through your provider without any malicious script on your server at all. The tell is mail that appears in your provider's sent records rather than in your server's mail queue.

Will my host restore the account once I have cleaned it?

Usually, yes. What they want is evidence: what the file was, where it was, how it got there, and what you changed so it does not happen again. A specific, factual account gets accounts restored far faster than a general assurance that you have run a scanner and everything seems fine now.