Practical security advice for website owners
WordPress Sending Spam Emails? Find the Source Before Restoring Mail
Security guidance · References checked 2 November 2026
In this guide
Your host says the website is sending spam. Customers report strange messages from your domain. Or your normal order emails suddenly stop because a mail service has suspended sending. These symptoms need investigation, but they do not all identify the same source.
A forged From address, an abused public form, stolen mail credentials and malicious code on the server require different responses. Start by establishing how the messages were actually sent. Re-enabling mail or buying another SMTP plugin before answering that question can leave the problem active.
Ask for a useful sample and timeline
Request the provider’s alert, sending times, message identifiers and relevant delivery records. If a recipient has a sample, ask for the original message or headers through a private channel rather than relying only on a screenshot. Do not ask them to open suspicious attachments.
Record the affected domain, website installation and mail service. Shared hosting may serve several websites, and a mail credential may be used by more than one application. A domain name in a message is not sufficient evidence that the WordPress installation generated it.
Keep the incident record factual. “The provider logged this account sending these messages” is more useful than “WordPress has been hacked” when the sending source is still unknown. Preserve available logs promptly because retention may be limited.
Distinguish spoofing from authenticated sending
Email authentication can help receiving systems assess a message’s relationship to a domain. SPF, DKIM and DMARC have different roles and must be configured for the actual sending services. Google’s email sender guidance explains its requirements and authentication expectations.
Authentication is not a malware scanner. A malicious message sent through a legitimately authenticated but compromised account can pass authentication checks. Conversely, a forged message can mention your website even when your hosting was not involved.
Have the mail provider interpret the relevant headers and account records if you are unsure. Do not paste full customer emails into a public diagnostic website without considering their contents and your authority to share them. Use the minimum data needed for the check.
| Observation | Useful first evidence | Avoid assuming |
|---|---|---|
| Domain shown in a From address | Original headers and provider sending records | That WordPress sent the message. |
| High public-form volume | Submission records and notification settings | That administrator access was obtained. |
| Provider logs show authenticated sending | Credential ownership and connected applications | That SPF or DKIM alone will stop the abuse. |
Review public forms and automated replies
An unprotected form can be abused without an attacker gaining administrator access. Review recipient settings, user-controlled fields, automatic acknowledgements and submission volume. A form that sends a copy to any address a visitor enters can become a channel for unwanted mail.
Check whether the server validates input and enforces the intended limits. Browser-only validation is not enough. Anti-spam measures should be appropriate to the form, accessible to legitimate users and verified in actual submissions. Do not add several conflicting challenges without testing the customer experience.
Preserve the useful enquiry workflow while containing abuse. Depending on the evidence, an authorised maintainer may temporarily pause a risky auto-reply or limit a specific endpoint. Record that temporary change and the alternative contact route so genuine customers are not left with a silent failure.
Investigate account and code changes
If provider records point to an SMTP or API credential, review where it is stored, who can access it and which applications use it. Rotate affected secrets using a planned deployment so legitimate sending can be restored safely. Revoke old credentials where supported; simply creating another key may leave the exposed one active.
If the web server is generating the messages, review the relevant script and component activity with the host or responder. Look at recent software changes, unfamiliar tasks and unexplained access. A new file near the time of abuse is a lead, not proof on its own.
Do not delete all mail queues or logs as a first step. Some messages may be legitimate orders or password resets, and the records may help establish what happened. Coordinate containment and queue handling with the provider.
Understand what a mail success result means
A form can display success even when delivery fails later. WordPress documents that a successful wp_mail() return value means the request was processed without an immediate error; it does not prove the recipient received the message.
For verification, follow one controlled test from form submission to the provider record and the recipient inbox. Use your own address and harmless test content. Check spam placement, rejection details and any webhook or stored enquiry record that the business relies on.
This matters after cleanup because a disabled mail service or blocked account may remain unresolved even when the website code has been repaired. Website recovery and provider reinstatement are connected tasks, but neither automatically completes the other.
Restore sending in controlled stages
Agree with the provider what evidence is needed before restrictions are lifted. Confirm the affected source has been addressed, credentials reviewed and the mail configuration documented. Test essential transactional messages first using supported test methods.
Reconcile queued business messages carefully. Replaying a queue may send duplicate receipts, outdated reminders or password-reset links. Decide with the business owner which messages should be retried and which should be cancelled. Keep customer communication accurate about any interruption.
Monitor the relevant sending records after restoration. Choose a review period and owner appropriate to normal volume. A quiet first minute is not enough evidence that a scheduled source of abuse has stopped.
What to include in a support request
Send the public website URL, provider alert, approximate start time and the type of affected messages. Say whether your main concern is spoofing, suspended mail or confirmed server sending. Keep credentials, complete customer messages and exported contact lists out of the initial enquiry.
Ask the specialist to separate source investigation, website cleanup, authentication configuration and mail-provider recovery in the scope. That makes the proposed work easier to assess and avoids paying for a general cleanup when the evidence points to a different problem.
Published by NithuDev. About Nithu / Suthakaran Nithursan, website developer and security recovery specialist. Featured artwork is an AI-generated editorial illustration, not a photograph of a client, a real security incident or a verified tool result.