Kualo / docs
On this page

Why are my sent emails going to spam or being rejected?

When a recipient tells you your email landed in their spam folder, or you receive a rejection notice, it can be hard to know where to start. This guide walks you through the most common causes - authentication, how you are sending, third-party providers, and external DNS - and explains what to check first.

11 min read Updated 16 Jun 2026

When a recipient tells you your email landed in their spam folder, or you receive a rejection notice, it can be hard to know where to start. Receiving mail servers score every inbound message on content, sender reputation, and authentication signals, so there is rarely a single fix that covers every case.

Before reading on, it helps to understand the difference between two outcomes:

  • Spam placement - the message was delivered but the recipient's mail provider filed it in their junk or spam folder.
  • Rejection or bounce - the message was refused outright and was not delivered at all. You will usually receive a bounce notice with an error code.

Gathering the right evidence depends on which of these has happened. Our article on how to read an email bounce message explains bounce codes in detail if you have received a rejection notice.

How are you sending the email?

Before checking authentication records, it is worth being clear about how the message is actually leaving your system. The answer affects which records matter, which settings to check, and who controls what.

Sending from an email client or webmail

If you are composing and sending email in an email client (such as Outlook or Thunderbird) or in RoundCube webmail, your message goes out through our mail servers using SMTP. Authentication records published in your domain's DNS zone - SPF, DKIM, and DMARC - are what receiving servers check. The steps in the sections below apply directly to you.

Sending from a website application (WordPress, Magento, or similar)

Website applications such as WordPress, Magento, WooCommerce, and others need to send email for things like order confirmations, password resets, and contact form notifications. They can do this in two ways:

  • PHP mail - the application calls PHP's built-in mail() function, which hands the message to the server's local mail transfer agent. This is the default for many applications and requires no configuration, but it is also the method most likely to cause deliverability problems. Messages sent this way often lack proper DKIM signing and may not align with your SPF record.
  • SMTP - the application connects to a mail server using a username, password, and port, just like an email client does. This is the more reliable method. If you configure your application to send via SMTP using your Kualo mailbox credentials and our mail servers, messages go through the same authenticated path as your regular email.

For WordPress, we have a guide on how to set up SMTP authentication in WordPress. For other applications, look for an SMTP or outgoing mail settings section in the application's configuration, and use the server details from cPanel under Email > Email Accounts > Connect Devices.

If your application is currently using PHP mail and you are having deliverability problems, switching it to SMTP is often the single most effective fix.

Sending via a third-party email service (Mailchimp, SendGrid, Google Workspace, and similar)

If you use a third-party service to send some or all of your email - whether that is a marketing platform, a transactional email service, or Google Workspace or Microsoft 365 for your regular mailboxes - those services send from their own infrastructure, not ours. For those messages to pass authentication checks, your SPF and DKIM records need to authorise that service's servers, not (or as well as) ours.

Each provider will give you specific DNS records to add. You need to add those records in whichever DNS zone controls your domain - see the section below on third-party DNS if that is not cPanel.

If you have both Kualo hosting email and a third-party sending service active for the same domain, your SPF record needs to include both. An SPF record that only covers one of them will cause failures for the other. Be careful not to exceed the SPF lookup limit of ten DNS lookups - if you have many services, consider using an SPF flattening tool.

Check your email authentication records

Authentication records are the single most important factor you can control. If they are missing or misconfigured, even a well-written message from a clean IP address will be treated with suspicion.

SPF

An SPF record tells receiving mail servers which servers are authorised to send email on behalf of your domain. If your domain has no SPF record, or one that does not include the infrastructure you are actually sending from, messages are more likely to be flagged.

If your email goes through our servers (cPanel mailboxes or SMTP from your application):

  1. Log in to cPanel.
  2. Go to Email and open Email Deliverability.
  3. Find your domain in the list and check whether the SPF row shows a problem.
  4. If it does, click Repair to let cPanel apply the recommended record, or follow the suggested value and add it manually in the Zone Editor.

If you also send from a third-party service:

You need to include that service's sending infrastructure in your SPF record as well. Check the service's documentation for the include: mechanism to add. Your final SPF record should cover every source that sends email for your domain.

If your email goes entirely through a third-party service and not through our servers:

The SPF record should authorise that service's servers. You may not need to include our mail infrastructure at all - but check whether you have any other sending sources (such as contact forms or automated notifications from your website) that still go through our servers.

Our article on understanding SPF records explains how SPF works and what the record should contain.

The Email Deliverability tool in cPanel is the quickest way to spot SPF, DKIM, and related issues for mail sent through our servers. Always start there.

DKIM

DKIM adds a cryptographic signature to outgoing messages so the recipient's server can verify they have not been tampered with in transit. We set up the server-side DKIM key for your account; your job is to make sure the corresponding DNS record is published and matches what the server is signing with.

  1. In cPanel, go to Email > Email Deliverability.
  2. Check the DKIM row for your domain.
  3. If the record is missing or mismatched, click Repair to publish the correct value.

A mismatch between the DNS record and the server key is a common cause of DKIM failures. The Email Deliverability tool will flag this clearly.

If you send from a third-party service, that service will have its own DKIM key and will give you a DNS record to publish. This is separate from the DKIM record for our servers - you may need both.

DMARC

DMARC builds on SPF and DKIM by telling receiving mail servers what to do when a message fails those checks. It is not strictly required, but it is increasingly expected by major providers such as Google and Microsoft, and its absence can affect deliverability.

A basic DMARC record looks like this:

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

The p=none policy means no action is taken on failures yet - it just collects reports. This is a safe starting point. You can add this record in cPanel's Zone Editor under Domains > Zone Editor.

For a full walkthrough, see how to add or manage DNS records in cPanel.

DNS changes take time to propagate across the internet. After adding or updating SPF, DKIM, or DMARC records, allow up to 24 hours before testing again.

What if your DNS is managed outside cPanel?

If your domain's DNS is managed at Cloudflare, your registrar, or another external provider - rather than through cPanel's Zone Editor - you will need to add or update your SPF, DKIM, and DMARC records there instead.

The record values are the same regardless of where you add them. You can find the recommended values for our mail servers in cPanel under Email > Email Deliverability, but you will need to log in to your DNS provider's control panel to actually publish them.

If you are not sure where your DNS is managed, check where your domain's nameservers are pointing. If they point to Kualo's nameservers (for example, ns1.kualo.com), your DNS zone is in cPanel and you can edit it there. If they point elsewhere, that is where you need to make changes.

Our guide on pointing your domain to Kualo without changing nameservers has more background on this setup.

If your DNS is at a provider that does not allow you to add or edit TXT records, contact that provider's support team. Every mainstream DNS provider supports TXT records - if yours does not, it may be worth moving DNS management to a provider that does.

What if your email is hosted with a third party but your website is on Kualo?

This is a common setup: your website and contact forms run on Kualo hosting, but your mailboxes are with Google Workspace, Microsoft 365, or another provider.

In this case:

  • Your MX records should point to your email provider, not to our servers. If they point to us, incoming mail will not reach your Google or Microsoft mailboxes.
  • Your SPF record should authorise your email provider's sending servers. If your website also sends email (for example, contact form notifications or WooCommerce order emails) through our servers, you need to include both.
  • DKIM records for your mailboxes will be provided by your email provider. You still need to publish the DKIM record they give you in your DNS zone.
  • If your website application sends email via PHP mail or SMTP, see the section above on sending from a website application.

If you are unsure how your email routing is configured, check cPanel under Email > Email Routing to see whether it is set to local, remote, or automatic. Our article on configuring email routing in cPanel explains what each setting means.

Check your email content and sending habits

Even with perfect authentication, the content of your message and how you send it can trigger spam filters.

  • Subject lines - avoid all-caps, excessive punctuation, and phrases commonly associated with spam such as "Act now" or "Free offer".
  • Links and images - a high ratio of images to text, or a large number of links, raises suspicion. Include a reasonable amount of plain text.
  • Bulk sending through a standard mailbox - if you are sending newsletters or marketing emails to a large list via a regular cPanel mailbox, you are likely to hit sending limits and damage your sending reputation. Use a dedicated tool such as MailMachine for bulk campaigns.
  • Attachments - large or unusual attachments (especially executables or password-protected archives) are frequently blocked by recipient mail gateways.
  • Compromised account - if your account or website has been compromised, spam may be going out in your name without your knowledge, damaging your domain's reputation even when your own messages look clean. Check your sent mail for messages you did not write, and review your account security.

If you suspect your account may have been compromised, change your cPanel and email passwords immediately and review our guidance on how to recover from a website hack. For general password advice, see our article on safe passwords.

You can also check your hosting account for malware using Imunify360 and Patchman, both of which are available from cPanel.

Consider the recipient's own filtering

Some spam placements are outside anyone's control. A recipient's company mail gateway, their ISP's filtering, or their own personal spam rules may classify your message as junk regardless of how well-authenticated it is. If the problem affects only one recipient or one domain, this is worth considering. Ask the recipient to check their spam folder, mark the message as not spam, and add your address to their contacts or safe senders list.

What we need to investigate

If your authentication records are correct, your content looks clean, and the problem persists across multiple recipients or providers, the issue may involve the shared IP address your account sends from, or a server-level configuration matter. These are things we handle - you cannot investigate or change them yourself on shared hosting.

Contact our support team and include the following information so we can check the mail logs and assess IP and server reputation for the specific sending event.

What to include in your support ticket:

  • The full sender email address (for example, [email protected])
  • The recipient email address or domain where the message landed in spam or was rejected
  • The date, time, and timezone of the message, and the subject line
  • Any bounce message, rejection notice, or spam report the recipient can share - full email headers are the most useful thing you can provide
  • Whether the problem affects one recipient or many
  • How the message was sent: webmail, an email client (such as Outlook or Thunderbird), a website application using PHP mail, a website application using SMTP, or a third-party sending service
  • If sent from a website application, which application (for example, WordPress, Magento, WooCommerce) and whether it is configured to use PHP mail or SMTP

Full email headers show the path a message took through the mail system and often contain the specific reason a filter acted on it. In RoundCube webmail, you can find these by following our guide on how to view message headers in RoundCube.

To raise a ticket, see how to create a support ticket in MyKualo.

Shared IP reputation, mail server configuration, and IP delisting are handled by us. Please do not attempt to contact blacklist operators directly about a shared server IP - contact our support team instead and we will investigate.

Was this helpful?
Your feedback helps us find gaps in the docs.
Still need a hand?
Real people, around the clock - start a chat or open a ticket and we'll help you put it right.