Why Is My Website Sending Spam Emails? (Fix It)

Your website hasn't grown a mind of its own — a hacked file on your server is almost certainly the one blasting the spam, and you can usually find and remove it in an afternoon. This is one of the most common signs of a compromised site, and it follows a predictable pattern: an attacker gets a script onto your server, that script quietly uses your server's mail function to send spam in bulk, and eventually your host notices before your own visitors do.

Who this is for: owners who got a "spam complaints" or "abuse" notice from their host, found their domain on a blacklist, or just have a hunch something's wrong. What you'll get: how to confirm the spam is genuinely coming from your server (not just spoofed), where the malicious script usually hides, how to pull it out safely, and how to close the door it came through.

How does a website end up sending spam?

It's almost never "your website decided to email people." It's a small file — often just a few lines of PHP — that an attacker uploaded after finding a weak spot: an outdated plugin, a leaked FTP password, an unpatched CMS version, or a contact form that accepts file uploads without checking what's inside them. This class of bug is well documented by OWASP as unrestricted file upload — once a script can land anywhere inside your web root, it can call PHP's mail() function (or open a raw connection to an SMTP server) and start sending on your server's reputation and IP address.

The script usually isn't sending one email at a time by hand — it's looping through a list, often triggered by repeated visits to its own URL or by a scheduled cron job, which is why the volume can spike into the thousands overnight.

Step 1: Confirm it's really coming from you

Before you go file-hunting, check whether the mail is truly leaving your server, or whether someone is just putting your domain in the "From:" field without touching your site at all (that's email spoofing, a related but different problem you can check with our email spoofing checker).

1. Open a spam sample and view the full headers. In Gmail: the three-dot menu → "Show original." Look at the chain of Received: from lines — read them bottom to top. If one of the early lines shows your actual hosting IP or hostname (not just your domain name), the mail was generated on your server.
2. Check for a host abuse notice. Most hosts auto-flag or suspend accounts once outbound spam volume trips a threshold — look for subject lines like "Exim mail queue is very large" or "abuse complaint" in your hosting account inbox.
3. Check the live mail queue. SSH in and run mailq (Postfix servers) or use WHM/cPanel's Email → Mail Queue Manager if your host uses cPanel. A queue in the thousands, all going to unfamiliar addresses, confirms active sending.
4. Check the mail logs for the source. Look at /var/log/mail.log or /var/log/exim_mainlog (cPanel), or use cPanel's Email → Track Delivery. You're looking for one account or script generating an unusually high, repetitive volume compared to your normal traffic.
5. Check your web server's access logs for repeated POST requests to an unfamiliar .php file — especially one sitting inside /wp-content/uploads/ or another folder that should only ever hold images and documents.

Step 2: Find and remove the mailer script

Mailer scripts hide in a few predictable places:

• Upload folders (wp-content/uploads/, /images/, /media/) — these should never contain executable PHP.
• Theme files, especially functions.php, where a few extra lines blend in with legitimate code.
• A "plugin" folder you don't remember installing.
• A file with a name designed to look boring (class-cache.php, wp-tmp.php) sitting next to legitimate files.

A few read-only commands that help you narrow it down fast:

grep -rl "mail(" --include=*.php wp-content/uploads
grep -rlE "base64_decode|gzinflate|eval\(" --include=*.php public_html

Heavy use of base64_decode, gzinflate, and eval() chained together to hide what a script actually does is the classic signature of a web shell — malicious code an attacker uses to control your server remotely — as described in CISA's guidance on detecting and preventing web shell malware. None of those functions are automatically evil on their own, but finding them obfuscating a file you don't recognize is a strong signal.

Other ways to narrow the search:

• Compare against clean copies. If you run WordPress, wp core verify-checksums (via WP-CLI) flags any core file that's been altered. Redownload fresh copies of your theme and plugins from their official source and diff them against what's on the server.
• Sort by recent changes: find public_html -type f -name "*.php" -mtime -30 surfaces anything touched in the last month — a freshly modified file inside an otherwise untouched plugin folder stands out.
• Check for scheduled tasks: crontab -l on the server, and any "cron" entries inside your CMS's own scheduler — some mailers fire on a timer instead of a web request.
• Check for accounts you didn't create: an extra WordPress admin user, or an extra FTP/cPanel user, often accompanies the script as a backup way back in.

Once you find it, move the file out of the web root (rather than deleting it immediately) so you can review it later if needed, then keep searching — attackers who get in once frequently leave more than one way back in.

Step 3: Close the door it came through

Removing the script fixes the symptom. These steps fix the cause:

• Update everything — CMS core, every theme, every plugin. Outdated software with a known, unpatched vulnerability is the single most common entry point.
• Reset every password: hosting/cPanel, CMS admin, database, FTP/SFTP. Assume whichever one was weakest is how they got in.
• Delete plugins and themes you don't actively use. Fewer installed files means fewer places to hide.
• Block PHP execution inside upload folders. On Apache 2.4, add this to a .htaccess file inside the uploads directory:

<FilesMatch "\.php$">
Require all denied
</FilesMatch>

• Turn on your host's malware scanner or file-integrity monitor if one is offered — it'll catch a repeat attempt faster than you can manually.

Step 4: Get off the blacklists

Once the script is gone and the hole is patched:

1. Check your server IP and domain at Spamhaus's lookup tool to see if either is listed.
2. Use each blacklist's own removal request form — don't request delisting until you've actually confirmed the mailer is gone, or you'll get relisted within hours.
3. Set up SPF, DKIM, and DMARC DNS records for your domain. These won't stop a script that's genuinely sending through your real mail path, but they help mailbox providers trust your legitimate mail going forward and stop the closely related problem of someone spoofing your domain from outside — see Google's bulk sender guidelines for the exact values major providers now expect.

Where to look for evidence

If digging through server logs isn't something you want to do yourself, our free website security check can tell you, at no cost, whether your site is showing the obvious red flags of a compromise — and our guide on whether your site is hackable in the first place covers the entry points worth locking down before this happens again.

Key takeaways

• Spam "from your website" is almost always a hidden script on your server, not spoofing — confirm it by reading the actual email headers.
• Check your mail queue and server logs to find which account or file is generating the volume before you start deleting things.
• Mailer scripts hide in upload folders, theme files, and disguised "plugin" directories — obfuscated code (base64_decode, eval) is a strong tell.
• Removing the file isn't the whole fix — update everything, reset every password, and block PHP execution in upload folders so it can't come back.
• Request blacklist delisting only after you've confirmed the script is actually gone.

If you've done the above and still aren't sure the site is clean — or you'd rather have a person confirm it instead of guessing — a real security engineer manually reviewing your site is the honest next step. That's exactly what Bug Circuit's $49 Circuit audit does: a full manual review with a written report of anything found, including exactly where the entry point was and how to close it.

FAQ

Why is my website sending spam emails?

In almost every case, an attacker uploaded a small script to your server — through an outdated plugin, a weak password, or an unrestricted upload form — and that script is using your server's mail function to send spam in bulk, usually without touching your site's visible pages at all.

Is my website hacked if it's sending spam?

Yes. A site can't send outbound spam on its own; it requires a malicious file or account that shouldn't be there. Treat it as an active compromise and remediate it the same way you would any other hack.

How do I know if my website is sending spam?

Check the full email headers of a spam sample claiming to be from you, look for an abuse notice from your host, and check your server's mail queue and logs for an unusually high volume of outbound mail — all of these will confirm whether the mail truly originated on your server.

Will my host suspend my site for sending spam?

Most hosts will suspend or throttle an account once outbound spam trips their abuse threshold, since it damages their shared IP reputation for other customers too. Removing the malicious script and responding to their abuse ticket promptly is usually enough to get reinstated.

Can my website send spam without me knowing?

Yes — that's the normal case. The script typically runs silently in the background or on a timer, so the first sign is often a host notice, a blacklist listing, or a customer telling you they got a strange email "from" your domain.