If emails from your website are going to spam, the problem is not always the email content or the form on the website. Delivery depends on the entire chain: the domain, DNS records, SMTP, IP address, server reputation, email headers, and CMS settings.
For a website owner, the basic checklist looks like this:
- SPF authorizes the server or SMTP service that actually sends the emails;
- DKIM is enabled, and emails are actually being signed;
- DMARC is configured at least in a relaxed mode;
- a PTR record exists and points to a proper hostname configured on the mail server;
- the server hostname looks correct;
- the IP address is not on a blacklist;
- the IP address and domain do not have a poor email reputation;
- emails are sent via SMTP, not through PHP mail();
- the From address uses the website domain, not a random address;
- Return-Path does not conflict with domain authentication;
- the SMTP plugin for WordPress or the online store is configured correctly;
- the email content does not look like spam;
- the sending frequency does not look suspicious.
It is also important to distinguish between the symptoms. If emails are not delivered at all, check SMTP, ports, logs, and the sending queue. If emails are delivered but go to spam, or are returned with a bounce message, the most common causes are SPF, DKIM, DMARC, PTR, IP reputation, email content, or headers. If the issue affects only some recipients, check the recipient addresses separately, as well as Gmail, Outlook, corporate mailboxes, and blacklists. If everything broke after migrating the website, check the new IP address, DNS, SMTP plugin, From/Return-Path, and test email sending.
For WordPress, WooCommerce, and other CMS platforms, it is better not to use built-in sending through PHP mail(). A more reliable option is to connect an SMTP plugin and send emails through authenticated SMTP: either your own mail server or an external SMTP service.
You should also be careful with addresses such as [email protected]. A noreply address is not prohibited in itself, but if the domain is not configured with SPF, DKIM, and DMARC, these emails may appear less trustworthy.
After migrating a website to a new VPS, it is not enough to check that the page opens. Email sending must be tested separately: registration, password recovery, inquiry forms, orders, WooCommerce notifications, and emails to administrators and customers.
The core logic is simple: an email must not only be sent, but also look trustworthy to the receiving server. This requires proper DNS records, correct headers, a clean IP reputation, working SMTP, and a careful sending frequency.
Symptom-Based Troubleshooting
When a website’s emails aren’t working properly, the first step is to identify the symptom. “Emails are going to spam” and “emails are not being delivered at all” are two different problems.
In the first case, sending may be working, but the receiving mail server does not trust the message. In the second case, the message may not even leave the website, VPS, or SMTP server. That is why troubleshooting should begin not with installing a new plugin, but with the question: what exactly happens to the email after it is sent?
Emails are not delivered at all
If emails are not being delivered at all, the first step is to determine whether they are actually being sent from the website. Sometimes the issue is not with SPF, DKIM, or IP reputation, but with the CMS itself, the SMTP plugin, the form, the email queue, or network restrictions.
For WordPress and WooCommerce, check the following:
- Whether an SMTP plugin is installed;
- Whether the SMTP host, port, username, and password are configured correctly;
- Whether authentication is enabled;
- Whether PHP mail() is being used instead of SMTP;
- Whether there are any errors in the sending log;
- Whether the hosting provider or VPS is blocking outbound connections.
If the website runs on its own VPS, check the mail logs and the sending queue. An email may be created but remain stuck on the server because of a connection error, a blocked port, or a rejection by the receiving side.
Check outbound SMTP separately. If the provider blocks port 25, your own mail server may not be able to send emails directly. External SMTP typically uses port 587 or 465, and the website must connect to that server specifically.
In this scenario, SPF, DKIM, and DMARC are also important, but they will not help if the email never physically leaves the website or SMTP server. First, establish reliable sending, and only then check deliverability.
Once an email at least starts reaching the recipient, the next level of diagnostics begins: whether it lands in the inbox or goes directly to spam.
Emails are going to spam
If emails are being delivered but end up in the spam folder, sending is technically working. The issue is most often related to trust in the domain, the IP address, or the email itself.
Start by checking domain authentication:
- SPF authorizes the actual sending server;
- DKIM signs the emails;
- DMARC is configured and does not conflict with the sending sources;
- Return-Path does not look unrelated or random;
- From uses the site’s domain.
Next, check the PTR record, hostname, and IP reputation. If the site sends emails from a new VPS without a proper reverse DNS record, major email providers may treat those messages more cautiously.
It is also important to review the headers of the received email. In Gmail, you can do this with “Show original”. This shows whether SPF, DKIM, and DMARC passed, which server sent the email, and which domain was used in From and Return-Path.
However, technical configuration is not the only factor. An email may look suspicious because of its content: too many links, URL shorteners, aggressive wording, attachments, empty body text, poor HTML layout, or identical bulk messages.
For an online store, order, payment, registration, and password recovery emails should be checked separately. They should be clear, use a proper sender, and avoid unnecessary “marketing” elements if they are transactional notifications.
It is a good idea to send a test email formatted like a real one to specialized services that will check the correctness of all DNS records, the signature, and the email content.
If emails go to spam for only some recipients rather than all of them, the issue may depend on the specific email provider. In that case, review the next scenario.
Emails are delivered only to some mailboxes
Sometimes emails are delivered normally to one mailbox but end up in spam or never reach another. For example, an email may arrive in a corporate mailbox but not in Gmail or Outlook, or vice versa.
First, rule out the simplest case: if the recipient address is incorrect or the recipient’s mailbox is full, the email will not be delivered, and we will receive a bounce message (NDR, Non-Delivery Report) with a detailed description of what happened. The important point here is to make sure you receive these NDRs: typically, they are sent to the return address (Return-Path) or to the sender address (Mail From).
If everything is fine with the recipient, the issue will require further investigation.
This is normal when diagnosing delivery issues: different email systems use different filters, reputation databases, and validation rules.
In this case, you need to test delivery to several types of mailboxes:
- Gmail;
- Outlook/Hotmail;
- Yahoo or another major email service;
- Corporate email;
- Email on your own domain;
- A temporary test mailbox for checking headers.
If the issue appears only with Gmail, you should carefully check SPF, DKIM, DMARC, From, Return-Path, and the domain’s reputation. If emails are not reaching corporate mailboxes, the cause may be stricter anti-spam filters, a blacklist, or the receiving server’s policy.
You also need to check whether the sending path differs. For example, emails from a contact form may be sent through an SMTP plugin, while WooCommerce emails are sent through PHP mail() or another mechanism. As a result, some emails are signed with DKIM and some are not.
For the site owner, this is an important signal: you need to check not just “one test email,” but all real sending scenarios. Registration, form submissions, orders, password changes, and administrator notifications may be sent in different ways.
If the problems started immediately after the site was migrated, diagnostics usually begin with the IP address, DNS, and SMTP settings.
Everything broke after the site migration
After moving a site to a new VPS, email often breaks not because of the CMS, but because the environment has changed. The site has been migrated, the IP address has changed, SMTP settings have been reset, DNS records are still outdated, and the new server either has no email reputation yet or has a poor one.
After a migration, check the following:
- Whether the sending IP has changed;
- Whether SPF has been updated for the new server or SMTP service;
- Whether DKIM works in the new environment;
- Whether the Return-Path has changed;
- Whether PTR is configured for the new IP;
- Whether outbound SMTP is blocked by the new provider;
- Whether the new IP has been added to a blacklist;
- Whether the WordPress SMTP plugin still works after the migration.
A common mistake is to migrate the site and check only the homepage. Forms, WooCommerce, password recovery, and administrator notifications are left untested. As a result, the problem is discovered only when a customer does not receive an order email or a user cannot regain access.
If email was sent through an external SMTP service before the migration, make sure the settings were preserved: host, port, username, password, encryption, From, and Return-Path. If messages used to be sent from one IP and are now sent from another, SPF and reputation must also be checked again.
After the migration, it is best to send test emails to different mail systems and review the headers. This lets you immediately see whether SPF, DKIM, and DMARC passed, which IP was used, and why the message may have ended up in spam.
Ultimately, symptom-based diagnostics helps avoid trying to fix everything at once. If emails are not being sent, check sending, SMTP, and logs. If they are going to spam, review authentication, reputation, and content. If the issue affects only some mailboxes, compare filters and headers. If everything broke after the migration, check the new IP, DNS, SMTP, and the site’s real email-sending scenarios.
Website Deliverability Checklist
Deliverability is not simply the fact that an email was sent. It is the likelihood that the email will reach the recipient and land in the inbox rather than in spam.
For a website, WordPress site, or online store, it is best to start the check with the domain. The receiving server must be able to determine that the email was actually sent on behalf of that domain and was not forged by a random script.
SPF, DKIM, DMARC
SPF, DKIM, and DMARC are the basic set of domain authentication mechanisms. Without them, emails sent from a website may look suspicious even when SMTP is working without errors.
SPF must authorize the server that actually sends the emails. If the website sends email through an external SMTP service, that service must be listed in SPF. If emails are sent directly from a VPS, SPF must authorize the IP address of that VPS.
You can check SPF as follows: dig TXT example.com +short
It is not enough for DKIM to simply exist in DNS. Emails must actually be signed. This can be checked in the headers of a received email: they should include the DKIM check result and the DKIM-Signature header.
DMARC tells the receiving server what to do with emails that fail SPF or DKIM. At first, it is better to use a relaxed policy, p=none, so you do not break legitimate emails from the website, CRM, WooCommerce, or an external SMTP service.
You can check DMARC as follows: dig TXT _dmarc.example.com +short
SPF, DKIM, and DMARC establish trust in the domain. But an email is not evaluated only by its domain—the receiving server also checks the sender’s IP address.
PTR, hostname, and IP reputation
A PTR record maps an IP address to a domain name. For a mail server, this is usually something like: 203.0.113.10 → mail.example.com
You can check the PTR record like this: dig -x 203.0.113.10 +short
Ideally, these should be consistent:
mail.example.com → 203.0.113.10
203.0.113.10 → mail.example.com
The server hostname should also be meaningful. If emails are sent from a VPS, it is better for the SMTP server to identify itself not with a random provider string, but with a proper name such as mail.example.com, matching the PTR record.
IP reputation is especially important after moving a site to a new VPS. If the IP address was previously used for spam or lacked a healthy sending history for a long time, emails may be delivered less reliably even with correctly configured DNS records.
The next step is to check whether the IP address or domain is on a blacklist.
Blacklist
A blacklist is a list of IP addresses and domains that have been associated with spam, suspicious activity, or malicious email sending. If a VPS IP address is listed, messages may be sent to spam or rejected before the message content is even analyzed.
You should check blacklists if:
- Messages have suddenly started landing in spam;
- Messages are not reaching some recipients;
- The website has been moved to a new VPS;
- The IP address previously belonged to another customer;
- The logs contain rejections from receiving servers;
- There was suspicious bulk sending.
Public blacklist lookup services are typically used for checking. However, it is important not to rely on a single service: different mail systems may use different reputation databases.
If the IP address is on a blacklist, the first step is to eliminate the cause. You should not simply submit a delisting request and continue sending mail in the same way. Check the website, forms, user accounts, SMTP access, sending limits, mail queue, and logs.
Even if the IP address is clean, the message itself still needs to look correct. To verify this, check the From field, Return-Path, and technical headers.
From, Return-Path, and email headers
The receiving server checks not only the email body but also the technical headers. For deliverability, the From header, Return-Path, DKIM signature, and SPF/DMARC results are especially important.
From is the address the user sees. For example: From: Shop <[email protected]>
Return-Path is the address used for technical bounces and delivery errors. It may differ from the From address, especially when an external SMTP service is used.
Problems begin when From uses the website’s domain, while Return-Path is associated with another domain that does not pass SPF or DMARC alignment. In this case, the email may appear less trustworthy.
Headers should be checked in the received email. You can use dedicated services, or, for example, in Gmail you can open “Show original” and review the results:
SPF: PASS
DKIM: PASS
DMARC: PASS
If any item shows fail or softfail, you need to go back to the DNS records, SMTP service, or sender settings.
It is also important that the sender address uses the website’s domain. Emails from an online store should be sent from [email protected], not from a random Gmail address or a server’s technical address.
For WordPress and WooCommerce, the sending method is a separate risk area. Even a correct From address will not help if the website sends emails through an unreliable mechanism.
WordPress SMTP plugin
By default, WordPress can send emails using PHP mail(). This is not always reliable and often results in poor deliverability, because emails may be sent without proper authentication, a DKIM signature, or a clear SMTP route.
For WordPress, WooCommerce, and sites with forms, it is better to use an SMTP plugin. It connects the site to a mail server or an external SMTP service over an authenticated connection.
In the SMTP plugin settings, check the following:
- SMTP host;
- Port 587 or 465;
- Encryption type;
- Username and password;
- From Email;
- From Name;
- Return-Path, if this setting is available;
- Whether all emails are sent through SMTP;
- Whether there is a send error log.
After configuration, send a test email from the plugin. However, a single test is not enough: you need to check the site’s actual emails, including the inquiry form, registration, password reset, WooCommerce order, administrator notification, and customer email.
If some emails are sent through SMTP and others through PHP mail(), the results may differ. Some emails will pass SPF/DKIM, while others may end up in spam.
Once the technical sending setup is complete, you still need to check the email itself: its text, links, attachments, and sending frequency.
Email content and sending frequency
Even perfectly configured SPF, DKIM, DMARC, and SMTP do not guarantee inbox placement if the email itself looks like spam.
Mail systems evaluate an email’s content: the subject line, body text, links, attachments, HTML layout, images, message repetition, and user complaints.
An email may end up in spam if it contains:
- Too many links;
- URL shorteners;
- Suspicious attachments;
- A subject line that looks like aggressive advertising;
- Body content made up almost entirely of an image;
- No clear sender;
- Broken HTML or a layout that looks like a bulk mailing template;
- Emails sent too frequently;
- No unsubscribe link;
- Users complain or do not open the messages.
For an online store, transactional emails are best kept simple: order, status, amount, contact details, and a link to the website. A password recovery email should not be overloaded with advertising, banners, and a large number of external links.
Sending frequency also matters. If a new site or a new IP suddenly starts sending hundreds of emails, it can look suspicious. It is better to increase volume gradually and monitor bounces, complaints, and spam placement.
Ultimately, the deliverability checklist works only as a single chain: the domain must pass SPF, DKIM, and DMARC checks; the server must have a proper PTR record and a good reputation; the email must be sent through a correctly configured SMTP server; and the content and sending frequency must not resemble spam.
What to Do If the Problem Persists
If SPF, DKIM, DMARC, PTR, blacklists, the SMTP plugin, and message headers have all been checked, but emails still end up in spam, you need to move from general diagnostics to targeted troubleshooting.
First, collect several real examples of emails. Do not use a single test email from the plugin; use the actual emails that matter for the site: a form submission, registration, password reset, order, administrator notification, and customer email.
For each email, check:
- Where it was sent;
- Whether it landed in the inbox or in spam;
- Whether SPF, DKIM, and DMARC passed;
- Which From address and Return-Path were used;
- Which IP address sent the email;
- Whether there are any errors in the headers;
- Whether the sending route differs from other emails sent by the site.
If the problem occurs only with one type of email, such as WooCommerce order emails, you should not investigate all site mail. Focus on the specific scenario: the email template, plugin, From address, attachments, links, and sending method.
If the problem occurs only with Gmail, Outlook, or corporate email, compare the headers across different systems. Different email services may evaluate the same domain, IP address, and email content differently.
If the site uses its own VPS for sending and emails are important to the business, consider using an external SMTP service. This is especially relevant for online stores, user accounts, SaaS projects, and sites where password reset emails or order notifications cannot be lost.
External SMTP does not replace SPF, DKIM, and DMARC. However, it simplifies delivery, provides clear logs, reduces dependency on the reputation of a new VPS, and helps you identify more quickly where the sending process is failing.
It is also worth separating transactional emails from bulk mailings. Password resets, orders, and customer notifications should not be sent in the same way as a marketing campaign to an old mailing list. If the mailing campaign receives complaints, it may hurt the delivery of important emails.
If the problem appeared after a migration, DNS rollback, or SMTP change, do not immediately change everything at once. It is better to document the current setup, test one scenario, fix it, and then move on to the next one.
The working sequence is as follows:
- Check the technical sending setup.
- Check DNS and domain authentication.
- Check the IP address, PTR, and blacklists.
- Review the headers of a real email.
- Compare different email systems.
- Check the email content and sending frequency.
- Switch to an external SMTP service if necessary.
If emails still consistently end up in spam after that, the problem may be the domain reputation, IP history, user complaints, or the quality of the recipient list. In that case, there may be no quick fixes: you need to gradually rebuild trust, reduce complaints, clean the list, and send only expected emails.
Conclusion
Emails from a website do not end up in spam for one single reason. The problem usually arises from a combination of factors: DNS records, SMTP settings, IP reputation, email headers, the sending method used in the CMS, and the content of the email itself.
For a website owner, it is important not just to “check the mail,” but to trace the entire path of the message: from the form, WordPress, or online store to the receiving server, whether Gmail, Outlook, or corporate email.
If emails are not being delivered at all, you need to check SMTP, ports, logs, the queue, and the sending settings. If emails are going to spam, SPF, DKIM, DMARC, PTR, blacklists, From, Return-Path, IP reputation, and the email text are more important. If everything broke after a site migration, the first things to check are the new IP address, DNS, the SMTP plugin, and actual sending scenarios.
For WordPress and WooCommerce, it is better not to rely on PHP mail(). A more reliable approach is to use an SMTP plugin and send emails through authenticated SMTP: either an external service or a properly configured mail server.
For an online store, SaaS project, or website with user accounts, email deliverability is not a secondary setting. Registrations, orders, password resets, customer notifications, and support operations all depend on it.
The right approach is to configure domain authentication, check IP reputation, review the headers of real emails, test different mail systems, and remember to repeat these checks after migrations, IP address changes, SMTP plugin updates, or moving the site to a new VPS.
FAQ
Why do WordPress emails end up in spam?
WordPress emails most often end up in spam because mail sending is poorly or incorrectly configured. The site may use PHP mail(), send emails without authenticated SMTP, fail to sign them with DKIM, or use a From address that does not align with the domain authentication.
SPF, DMARC, PTR, IP reputation, and the email content also play a role. If WordPress sends emails from the site’s domain, the receiving server must be able to see that this domain has actually authorized those messages.
For WordPress, it is better to use an SMTP plugin and send emails through an external SMTP service or a properly configured mail server. After setup, you should check not only the test email from the plugin, but also real-world scenarios: forms, registration, password recovery, WooCommerce orders, and administrator notifications.
Why are emails from the website not being delivered at all?
If emails are not being delivered at all, the problem may not be the spam filter but the sending process itself. The email may not be leaving the website, may be stuck in the queue, may be blocked at the VPS level, or may be unable to connect to the SMTP server.
Start by checking the SMTP settings: host, port, username, password, encryption, and authentication. Then check the website logs, the SMTP plugin logs, and the mail server logs.
If you use your own VPS, check whether outbound SMTP is blocked. Some providers restrict outbound port 25. Ports 587 or 465 are typically used for sending through an external SMTP server.
Which is better: PHP mail or an SMTP plugin?
For a website, it is better to use an SMTP plugin. PHP mail() can work, but it often results in poor deliverability: messages are sent without proper authentication, a clear routing path, logs, or a valid signature.
An SMTP plugin connects WordPress or an online store to a specific mail server or external SMTP service. This makes troubleshooting easier and improves delivery predictability.
The plugin alone does not guarantee inbox placement. You still need to configure SPF, DKIM, DMARC, From, and Return-Path, and test the actual emails sent by the site.
How do you check SPF, DKIM, and DMARC?
SPF and DMARC can be checked through the domain’s DNS records:
dig TXT example.com +short
dig TXT _dmarc.example.com +short
DKIM is checked using its selector. For example, if the selector is named default, the command might look like this: dig TXT default._domainkey.example.com +short
However, DNS records alone are not enough. You need to open the headers of an actual received email and check whether SPF, DKIM, and DMARC passed. In Gmail, you can do this via “Show original”. Alternatively, you can use dedicated services that show issues and headers and provide configuration recommendations.
Cloudflare describes SPF, DKIM, and DMARC as three email authentication methods that work together to verify the sender and protect the domain from spoofing.
What is Return-Path and why is it important?
Return-Path is the technical address where delivery errors are sent. Users typically see the From address, while Return-Path is used by mail systems for bounce messages and to check the sending route.
For example, a user might see:
From: Shop <[email protected]>
The technical bounce address, however, may belong to an external SMTP service.
This is normal in itself. Problems arise when Return-Path, From, SPF, and DMARC conflict with one another. In that case, the receiving server may trust the message less.
That is why, after configuring SMTP, it is important to check not only the sender address shown in the email interface, but also the technical headers.
Do you need to warm up a new IP address before sending email?
Yes, if the website sends email directly from a new VPS or dedicated IP address. A new IP address with no sending history can look suspicious, especially if you immediately start sending a large volume of email.
Warming up means gradually increasing the sending volume and monitoring recipient responses: bounces, complaints, spam placement, open rates, and unsubscribes.
For a small site with infrequent transactional emails, this is less noticeable. But for an online store, newsletters, a SaaS project, or a user account area, a sudden IP address change can affect deliverability.
If you do not want to manage IP reputation manually, it is easier to use an external SMTP service.
When should you switch to an external SMTP service?
You should switch to an external SMTP service if email is important to your business and must not be lost: orders, inquiries, registrations, password resets, receipts, customer notifications, and support messages.
External SMTP is especially useful if:
- The VPS is new and has no email reputation;
- The provider blocks outbound SMTP;
- The IP address is blacklisted;
- WordPress emails often end up in spam;
- You do not have time to administer a mail server;
- You need logs, statistics, bounce handling, and clear diagnostics.
In its sender guidelines, Gmail emphasizes the importance of email authentication using SPF or DKIM, and, for DMARC, alignment between the domain in the From header and the domain that passed SPF or DKIM.
External SMTP does not remove the need to configure the domain. SPF, DKIM, and DMARC are still required, but the service usually provides clear instructions and ready-to-use DNS records.
Sources
1. Gmail Help — Email sender guidelines
