If your messages are landing in spam instead of the inbox, the cause is usually a mix of sender reputation, email authentication, message content, and recipient-side filtering. In a hosting environment, this often comes down to missing or incorrect DNS records, a misconfigured mail server, sending from the wrong hostname, or a mailbox that is being used in a way that looks automated or suspicious.
For businesses using a hosting platform, control panel, or managed email service, the good news is that most delivery problems can be identified and fixed with a structured check. The most important areas are SPF, DKIM, and DMARC, followed by reverse DNS, SMTP configuration, sending volume, and the quality of the email content itself.
Why emails are marked as spam
Mailbox providers such as Gmail, Outlook, Yahoo, and other European email services use many signals to decide whether a message should reach the inbox. No single factor is enough on its own. A message may be filtered to spam if one or more of the following apply:
- The sender domain has no SPF, DKIM, or DMARC set up correctly.
- The email server IP has poor reputation or is shared with other senders who send unwanted mail.
- The message comes from a domain that does not match the authenticated sending service.
- The mail server hostname, PTR record, or HELO/EHLO name is inconsistent.
- The content looks promotional, repetitive, or suspicious to spam filters.
- The recipient has not engaged with your messages before.
- The mailbox list contains invalid, inactive, or old addresses.
- The sending pattern is unusual, such as sudden volume spikes.
When you host email through a control panel such as Plesk, these issues often appear after a migration, a DNS change, a new domain setup, or switching between a local mailbox and a third-party sending service.
Start with SPF, DKIM, and DMARC
Email authentication is the foundation of modern deliverability. If these records are missing or incorrect, receiving servers have less confidence in your messages. Even if the content is legitimate, the mail may still land in spam.
SPF: who is allowed to send mail
SPF tells receiving servers which IP addresses or services are authorized to send email for your domain. It is published in DNS as a TXT record.
Common SPF problems include:
- Multiple SPF records on the same domain.
- Missing the actual sending server or sending service.
- Using an overly strict policy before testing.
- Exceeding the DNS lookup limit because the record is too complex.
A correct SPF record should list the systems that actually send messages for your domain, such as your hosting mail server, a newsletter platform, or a ticketing system. If you use Plesk or another control panel, verify that the outgoing server IP is included, especially after IP changes or migration to a new hosting plan.
DKIM: cryptographic proof that the message is genuine
DKIM signs outgoing email with a private key on the server. The public key is published in DNS. When the message reaches the recipient, the server checks whether the content and headers match the signature.
DKIM helps because it shows the email has not been altered after leaving your server and that it was sent by an authorized system. If DKIM is missing or broken, the message is more likely to be treated as untrusted.
Typical DKIM issues include:
- The DKIM selector is missing from DNS.
- The private key on the mail server does not match the public key in DNS.
- The message is being sent through a relay that does not sign mail.
- Mail is modified after signing, which breaks the signature.
DMARC: policy and reporting
DMARC tells receiving servers what to do when SPF and DKIM do not align with the sender domain. It also provides reports that help you detect unauthorized use of your domain.
DMARC is especially useful when you send mail from multiple systems. It helps ensure that the visible From address matches the authenticated sending domain. Without alignment, even valid mail may be treated as suspicious.
A practical DMARC rollout usually starts with a monitoring policy, then moves gradually toward stricter enforcement. This gives you time to confirm that all legitimate sending sources are authenticated properly.
Check the basics in your hosting or control panel
If you manage your domain and mailbox through a hosting control panel, review the email-related settings first. Many spam issues are caused by a simple mismatch between DNS and the actual mail server configuration.
Verify the outgoing mail server
Make sure the message is being sent from the correct SMTP server. If you are using a mailbox inside your hosting account, the server should usually be your domain mail service rather than a generic or outdated host. If your email client is configured with an old SMTP hostname, authentication may fail or the mail may be sent from the wrong IP.
Confirm the domain matches the sender
The domain used in the From address should match the domain authenticated by SPF or DKIM. For example, if mail is sent as [email protected], the authenticated domain should also be example.com or a properly aligned subdomain.
Check the DNS zone
In the DNS zone, verify that the following are in place and correct:
- SPF TXT record
- DKIM public key record
- DMARC TXT record
- MX records for inbound mail
- Correct A or AAAA records for mail hostnames, if used
If you recently changed hosting providers or moved to a new managed hosting platform, old DNS records may still be present. Duplicate or conflicting records can confuse receiving servers and create intermittent delivery issues.
Review the mail server reputation
Even if authentication is correct, your messages may still go to spam if the sending IP or domain has a weak reputation. This is common on shared hosting, where many customers send mail from the same infrastructure.
Shared IP versus dedicated IP
On shared email infrastructure, your mail reputation can be affected by other senders. If another account sends unwanted mail, the shared IP may be downgraded by mailbox providers.
A dedicated IP can improve consistency for organizations with stable sending volume, but it does not automatically fix spam placement. The domain reputation, authentication, and content still matter.
Reverse DNS and server identity
Receiving servers expect the sending IP to resolve back to a valid hostname through reverse DNS, also known as PTR. The hostname used by the SMTP server should also be consistent with the domain and the banner it presents during connection.
In practice, your setup should avoid situations such as:
- IP address with no PTR record
- PTR record pointing to an unrelated hostname
- SMTP hostname that does not match the reverse DNS
- Mail server greeting with a generic or invalid name
These are common causes of spam filtering on strict providers.
Look at the content and format of the email
Authentication alone does not guarantee inbox placement. Spam filters also inspect the message itself. A legitimate business message can still be filtered if it resembles mass marketing or phishing.
Content patterns that trigger filters
- Overuse of sales language or urgency.
- Too many links, especially shortened URLs.
- Large images with very little text.
- Attachments without context.
- Subject lines that look generic, misleading, or repeated.
- HTML that is broken, unbalanced, or poorly formed.
- Missing plain-text alternative content.
For transactional or business email, keep the message clear, specific, and relevant. Avoid formatting that makes the mail look automated in a low-quality way. If you are sending from a control panel or application on your hosting account, make sure the generated templates are clean and not copied from outdated marketing software.
Sending behavior matters too
Mailbox providers analyze how you send mail over time. They pay attention to:
- Volume spikes from a new domain
- High bounce rates
- Low open or reply rates
- Repeated sending to inactive recipients
- Frequent complaints or spam reports
If you recently started sending newsletters or account notifications from your hosting environment, warm up the domain gradually. Start with the most engaged recipients and increase volume step by step.
How to troubleshoot spam delivery step by step
Use the following checklist to identify the problem in a structured way.
1. Send a test message to multiple providers
Test delivery to Gmail, Outlook, Yahoo, and one or two European mailbox providers used by your audience. Compare where the messages land and whether any provider rejects them outright.
2. Check the message headers
Open the full headers of a delivered message and look for authentication results such as SPF, DKIM, and DMARC status. You should see clear pass results and alignment with the sender domain. If one of these fails, identify whether the problem is DNS, the mail server, or a relay service.
3. Validate SPF
Confirm that there is only one SPF record for the domain. Make sure it includes every legitimate sending source. If you use both the hosting mailbox and a third-party platform, both must be authorized.
4. Validate DKIM
Check that the selector exists in DNS and that the key matches the mail server configuration. If mail is sent through Plesk, another panel, or an external relay, verify where the signing actually happens.
5. Review DMARC alignment
Make sure the visible From domain matches the authenticated domain. If you use subdomains for sending, the DMARC policy should support that structure.
6. Confirm reverse DNS and server hostname
Check that the sending IP has a valid PTR record and that the mail hostname is consistent with the server identity. This is particularly important for self-managed or dedicated hosting setups.
7. Inspect the content
Review the subject line, links, attachments, images, and plain-text version. Remove anything that looks risky, unnecessary, or spam-like.
8. Check recipient list quality
Remove old, invalid, or role-based addresses if they are not needed. High bounce rates can quickly damage reputation, even for a legitimate domain.
Common causes in Plesk and similar hosting panels
When mail is managed through Plesk or another hosting control panel, these are some of the most frequent issues:
- DKIM is disabled for the domain after migration.
- SPF record was not updated after changing the mail service.
- Outgoing mail uses a different hostname than the one published in DNS.
- Applications send mail through PHP mail() instead of authenticated SMTP.
- The server was moved, but PTR and A records were not aligned.
- The domain uses multiple DNS providers, and records are out of sync.
Using authenticated SMTP from your mailbox is usually more reliable than relying on unauthenticated local sending. It also makes troubleshooting easier because the sending path is clearer.
Best practices to improve inbox placement
To reduce the chance of spam placement long term, follow these practices consistently:
- Use a real mailbox and authenticated SMTP for important business mail.
- Keep SPF, DKIM, and DMARC correctly configured.
- Send from the same domain that users expect to see.
- Keep your DNS records clean and avoid duplicates.
- Monitor bounce messages and complaint reports.
- Use professional, clear subject lines and message bodies.
- Maintain a healthy recipient list with regular cleaning.
- Avoid sudden large sends from a new domain or IP.
For organizations in Europe, this is also important for trust and compliance. Reliable authentication supports better delivery and helps mailbox providers distinguish legitimate business communication from abuse.
When to contact your hosting provider
You should contact your hosting provider or mail administrator if:
- You cannot verify or edit the DNS records yourself.
- The mail server IP has no correct reverse DNS.
- Outgoing mail is blocked or throttled by the server.
- DKIM signing is unavailable or fails after setup.
- Your IP appears to be on a blocklist.
- Messages pass authentication but still land in spam consistently.
Provide examples of affected messages, the sender domain, the recipient provider, and the full headers. This helps support teams identify whether the issue is DNS, server configuration, reputation, or content-related.
FAQ
Why do my emails go to spam even when SPF and DKIM pass?
Because mailbox providers use many signals, not only authentication. Reputation, content, sending pattern, reverse DNS, and recipient engagement can still cause spam placement.
Can one bad email campaign affect all future mail?
Yes. If you send to a poor-quality list or generate complaints, the domain or IP reputation can drop and affect future delivery, including transactional messages.
Is DMARC required?
It is not always strictly required, but it is strongly recommended. DMARC gives you visibility into authentication alignment and helps protect your domain from spoofing.
Should I use the same domain for website and email?
Usually yes, as long as the domain is properly authenticated and maintained. If you use a separate subdomain for marketing or system mail, make sure SPF, DKIM, and DMARC are configured for that subdomain too.
Does sending from a hosting mailbox improve deliverability?
Only if the mailbox is properly configured and the server reputation is healthy. A mailbox alone does not guarantee inbox placement.
What is the fastest way to diagnose the issue?
Check the message headers first, then verify SPF, DKIM, DMARC, reverse DNS, and the SMTP server configuration. That sequence usually identifies the root cause quickly.
Conclusion
Emails going to spam are usually the result of a configuration issue, weak reputation, or message quality problems rather than a single broken setting. In a hosting or managed hosting environment, the most effective approach is to verify SPF, DKIM, and DMARC first, then check reverse DNS, SMTP settings, and the sender domain alignment. After that, review the content and sending pattern to make sure the message looks trustworthy to mailbox providers.
If you manage email through a control panel such as Plesk, keeping DNS records, mailbox settings, and sending services aligned is the key to better delivery. With a clean setup and consistent sending behavior, most legitimate business email can reach the inbox more reliably.