Website sending spam emails: why and how to stop it

The email from the host usually arrives without an introduction. It says that several thousand messages were sent from your account in a short time, that the server was reported as a source of unwanted mail, and that the account has been temporarily suspended. The site is already offline at that point, and you have no idea what they are talking about, because you did not send a single message.

In short: when a site sends spam without your knowledge, a script or hole is on the server. Stop the sending first, find and remove the entry, close the vulnerability, then ask for reactivation.

When website spam emails go out without the owner's knowledge, it almost always means one thing: someone else is using your server. In this article we explain how that happens, why hosts react so sharply, where the sending script usually hides, and in what order to fix the problem so the account does not get closed again in a week.

Why your server is interesting to anyone at all

Website spam emails are rarely about your content. Attackers want a clean sending reputation.

This is the question we hear first most often. The site gets twenty visitors a day, sells a local service, holds no confidential data. Why would anyone attack it?

The answer is that the attacker does not care about your content. They care about what your server can do for them, which is sending mail from an address with a clean history.

Spam sent from known, already reported servers lands in junk immediately. Spam sent from a domain that has had no complaints for years passes filters much better. Your good reputation is a product the attacker uses and spends until it is spent. When it is spent, they move on, and you are left with a domain whose reputation is ruined.

The same applies to other forms of server abuse. The same breach can serve to host a fake page for stealing data, to send traffic into attacks on third-party sites, or to mine cryptocurrency. A situation where a website sending spam is only the most common and most visible form of abuse, because the host notices it quickly.

Why the host suspends instead of warning first

Hosts shut accounts fast because website spam emails from one client can blacklist the whole shared IP.

When your host shuts down the account without prior warning, it is easy to read that as an overreaction. From their perspective it is not.

Shared hosting servers share the same IP address or the same address range for a large number of sites. If one account on that server ends up with a website sending spam in bulk, the entire range can end up on blacklists used by major email providers. That means every other client on the same server suddenly cannot deliver legitimate mail.

Getting an IP address off such a list is a long process that sometimes takes weeks. So the host does not have the luxury of waiting and asking. Suspension is the fastest way to stop the source, which is why it almost always comes before conversation.

The practical consequence for you is that talking to the host goes much more smoothly if you approach with accurate information. If your first reply says you identified the source, removed it, and closed the entry, the account usually comes back quickly. If you only say you understand nothing, the exchange drags on.

How the malicious script usually gets planted

Website spam emails almost never start with a targeted attack on you alone.

It is almost never a targeted attack on you specifically. Automated scripts check sites one after another looking for known weaknesses. The entry point is almost always one of the following.

• An outdated plugin with a known vulnerability. The most common cause by a wide margin. When a vulnerability is published, attackers start using it within days, while many sites stay unpatched for months.
• A contact form without protection. A poorly written or poorly configured contact form can be abused to send mail to arbitrary addresses with arbitrary content. This often happens on sites where the form was written by hand, without a proven plugin.
• A weak admin password. Brute-force attacks on the login page still succeed far more often than they should, especially when the username is "admin".
• A theme or plugin from an unofficial source. Pirated versions of premium products regularly come with code someone deliberately inserted before sharing them.
• A compromised hosting or FTP password. Most often through a password that leaked on another service and was reused.
• Another site on the same account. If you keep several sites in one hosting package, infection from one often spreads to the others, because they share the same disk space.

Where the mail-sending script hides

To stop website spam emails you must find the script that sends them.

When a website sending spam is the problem, you need to find the source itself. A few places repeat from case to case.

A PHP file in the uploads folder

The folder wp-content/uploads is meant for images, documents, and media files. A file with the .php extension should never be there. If you find one, it is almost certainly not yours. The name usually looks as if it belongs to the system, for example something with the words cache, tmp, or class in it, so that a superficial look lets it pass.

A file among plugins that does not belong there

Attackers often drop a file into a legitimate plugin folder, because dozens of files already exist there and one more does not stand out. That is why comparing installed plugins with their official versions gives much better results than a manual review.

The MU-plugins folder

The folder wp-content/mu-plugins is loaded by WordPress automatically, before all other plugins. Its contents do not appear in the standard plugins list the same way ordinary plugins do, and many site owners do not even know it exists. That is why it is a favorite place for code that needs to run unnoticed and survive the removal of other things.

A scheduled task in WordPress

WordPress has its own system of scheduled tasks. An attacker can schedule a task that calls a malicious function at regular intervals. The effect is that a website sending spam does so in bursts, with pauses, which makes detection harder and can briefly fool the host. It also means the problem returns even after deleting the file, if the scheduled task itself remains.

Code injected into the theme

Most often in a file that loads on every page. The code rarely looks readable. Usually it is one long string of letters and numbers that only decodes at execution time, stretching across the entire screen without a single recognizable word. That is a common final form when a website sending spam does so through the theme.

How to confirm the problem really exists

Before cleanup, confirm that website spam emails really left your server.

Before you change anything, it is worth having proof and a rough picture of the scope.

First ask the host for mail-sending logs. Most hosting companies have them and provide them on request. From them you see the exact send times, the number of messages sent, and very often the path to the script that sent them. That data saves you hours of searching, and it is the first thing you should request.

Then check the mail queue, if your hosting panel shows it. If you see thousands of messages waiting for delivery to addresses you have never seen, confirmation is there.

Also check the full list of users in the WordPress admin, not just the first few. A new admin account created at a time when none of you logged in is a clear signal. Pay attention to the registration date of every account.

Finally check whether your domain has ended up on any mail blacklist. Free services exist for that check, and the result tells you how far the damage has already gone beyond your server.

A sequence that makes sense

Make a copy before anything else

A full copy of files and database, even if infected. That is your only protection if something goes wrong during cleanup, and the only data source if you later need to reconstruct what happened.

Stop the process where the website sending spam continues before you start cleaning

If the account is suspended, sending is already stopped. If it is not, it makes sense to temporarily disable outbound mail or put the site in maintenance mode while you look for the source. That stops further damage to the domain reputation, which is often more lasting than the infection itself.

Find and remove the source

While a website sending spam is active, removing only one file is rarely enough. Remove the malicious script, but also everything left as a backup: extra admin accounts, scheduled tasks, files in unusual places. This part is easiest to underestimate, and it decides whether the problem comes back.

Close the entry

Update core, theme, and all plugins. Remove what you do not use, because an inactive plugin with a vulnerability is still vulnerable. Change every password: WordPress admin, database, hosting panel, FTP. If the attacker had access, they probably extracted those credentials while they were inside.

Tell the host what you found

A concrete reply describing the cause and the steps taken speeds up account reactivation more than any pleading. If you have the logs they themselves gave you, refer to them.

Repair the domain reputation

This is the step many people skip. If the domain ended up on blacklists, it is worth submitting a removal request to each list it appears on, after cleanup. Also check that SPF, DKIM, and DMARC records are set correctly, because they make spoofing your address harder in the future and help legitimate mail pass again.

How far the damage goes beyond a suspended account

When the account is reactivated, it is easy to think the matter is finished. It is not, and it is worth knowing what remains behind.

Domain reputation lasts longer than the infection

Major email providers keep their own reputation scores for every domain. That score is built over months and drops in a few hours of bulk sending. The result is that your legitimate mail (offers to clients, shop notifications, order confirmations) starts landing in junk even though the site has long been clean. Recovery is gradual and requires sending a normal, expected volume of mail for a while.

Client trust

If spam sent from your address went to people in your address book, and that is not rare, they received a message that looks as if it came from you. That is remembered longer than a technical problem. A short, honest notice to clients, explaining what happened and what you did, usually goes much better than silence and hope that nobody noticed.

Data that may have left

If the attacker had enough access to plant a sending script, they also had access to the database. That means addresses, names, sometimes order data for your users. It is worth soberly assessing what was in that database. If personal user data is involved, the duty to notify can be a legal matter, not only a question of courtesy.

Time you did not plan to spend

This is the most banal and in practice often the most expensive part. A day or two lost on exchanges with the host, searching for files, and explaining to clients usually costs more than a year of monitoring that would have caught the problem in time.

What not to do

Do not change hosts in the first moment. Moving while a website sending spam is active only transfers the problem, and in the meantime you lose the logs that were your most useful trail.

Do not restore an old backup blindly. If you do not know when the infection started, you are probably restoring an already infected site and also losing content from the meantime. First a timeline, then a decision about the backup.

Do not install five security plugins at once. None of them will remove code that is already there, and more plugins doing the same job means a slower site and possible conflicts.

Do not delete files before you have looked at what is in them. The contents of a malicious file often tell you when it was planted and through which hole, and that is information without which you fix the symptom and wait for it to repeat.

Do not leave the site in maintenance mode for weeks while you think about what to do. Longer absence from the network also pulls down search positions, so a marketing problem stacks on top of the technical one.

How to prevent a repeat

A site that once had a website sending spam situation is more likely to be attacked again, partly because it is already on lists used by automated scripts.

Regular updates close most entry points, because most attacks target vulnerabilities that were patched long ago. Strong, unique passwords with two-factor login remove the second most common entry. Blocking PHP execution in the uploads folder at the server level disables an entire class of these scripts, even if a file somehow gets planted.

Most important is that monitoring is regular and automatic. A spam campaign often runs in bursts, with pauses, and easily goes unnoticed between two manual checks. A system that daily compares the state of files and database with the previous one notices a new script before the host notices a thousand sent messages.

A first step that costs nothing

If you suspect website sending spam, a free quick scan reviews the publicly available content of your site and looks for known malware patterns and suspicious elements. No account, no installation, usually under a minute.

It is worth being clear about what that check cannot do. It only looks at what is publicly available over the internet. A mail-sending script sitting in a file on the server waiting for a call is not publicly visible, so a remote check will not find it. A clean result is a good sign, but with this kind of problem a reliable answer only comes from reviewing the files and database on the site itself.

If the account is already suspended or you have confirmation from the host that the site is sending mail you did not send, contact us right away. Send the site address and the email you received from the host. Urgent cases go ahead of regular requests, because every day of suspension means lost visitors and further damage to the domain reputation.