Hacked Website Sending Spam Email? Find and Stop the Source

Identify what is actually sending the messages

A delivery warning is a starting point, not a complete diagnosis. Collect the provider's abuse notice, representative message headers, message identifiers, times and the affected sender addresses. Do not open suspicious attachments or follow links in alleged warning emails. Reach the provider through a known account portal to confirm that the notice is genuine.

Distinguish three possibilities: an application on the server is generating mail, someone is authenticating to a legitimate mailbox, or messages elsewhere merely claim to come from your domain. These routes require different recovery work. A public contact form can also be abused even when no attacker has installed malware, so investigate its actual behaviour rather than labelling every incident a server hack.

cPanel's Track Delivery report can help examine available delivery records, but its coverage depends on the host's mail logging configuration. Ask the provider for the evidence it used to identify the source, especially where mail is routed through another service.

Contain abuse while protecting business communications

Ask the host or mail provider to suspend the specific abusive sending route where possible. Record whether that action also pauses password resets, order confirmations or customer enquiries. Do not repeatedly empty mail queues before the provider has retained the records needed to investigate the incident. Queue administration may be outside your hosting permissions.

1. Preserve relevant delivery records and a small set of representative messages in restricted storage. Avoid distributing complete customer mailboxes to everyone involved in the response.
2. If a mailbox is compromised, secure the trusted recovery route, reset its credentials and review sessions, forwarding rules and connected applications. Replace credentials in legitimate systems after access is trustworthy.
3. If a website script is implicated, restrict the affected application and preserve its code and request logs. Determine whether the script is malicious, a modified legitimate component or an inadequately protected form.
4. Provide staff with an approved alternative communication route while the normal service is restricted. Warn them against creating ad hoc forwarding rules that expose customer information.

Repair the application or identity that enabled the sending

For an infected PHP website, rebuild executable components from trusted project source or vendor packages and review the database where settings, templates or scheduled work are stored. Remove unauthorised persistence and address the initial access route. Merely deleting the file named in an abuse report leaves uncertainty about other changes that were not observed during that sample.

For a contact form, inspect its recipient configuration, validation, fixed sender behaviour and abuse controls. Public visitors should not be able to turn the form into an arbitrary mail relay. Add proportionate server-side rate limits and reject malformed inputs; then verify that genuine customers can still submit a useful enquiry. A visual challenge alone does not correct unsafe mail handling.

If mailbox access caused the incident, investigate the device and credential workflow used to access it. A newly changed password can be stolen again from an untrusted device. Also check whether the same secret was reused for hosting, another mailbox or a marketing integration, and remove that dependency where it exists.

Separate domain authentication from malware cleanup

Review SPF, DKIM and DMARC with the mail provider after the sending route is understood. These controls help recipients assess whether mail is authorised and aligned with a domain; they do not remove an infected website or revoke a stolen mailbox session. Do not tighten policies blindly while legitimate transactional or agency mail services have not been inventoried.

Create a list of authorised senders with an owner for each: the website, staff mailboxes, booking systems, help desk and marketing tools. Compare that list with the provider's recommended DNS records. Keep old record values and record when changes were made. Incorrect DNS edits can interrupt genuine mail without addressing the abusive source.

Prove normal delivery and monitor the repaired route

For example, a hypothetical service company receives a spam suspension notice after an old enquiry plugin is abused. Replacing the mailbox password does not help because the form sends directly through the hosting account. Once the form is repaired and its recipient rules are fixed, the provider can review the remaining queue and sending restriction using the evidence from the actual source.

• Send agreed synthetic tests from every legitimate route and confirm the intended recipients receive them.
• Check Reply-To behaviour without allowing visitors to control the actual delivery destination.
• Review application and provider logs for new bursts, unexpected recipients or repeated authentication failures.
• Verify that any temporarily suspended customer workflow has been restored deliberately.
• Keep a monitoring owner and reopen the incident if the same route resumes abnormal sending.

Ask for specialist help when the origin cannot be identified, several mailboxes are involved, the provider reports continuing abuse, or customer communications may have been accessed. A useful investigation ends with a documented sending route and a tested repair, rather than a promise that all future messages will reach an inbox.