cPanel Emails Going to Spam? Fix SPF, DKIM & DMARC

Why does mail from your cPanel mailbox look fine in your own inbox but land in a client's Gmail spam folder?

Usually, the receiving server cannot authenticate the sender properly, the sending domain has a reputation problem, or the message triggers spam filtering.

When I see cPanel emails going to spam, I start with three things: SPF, DKIM, and DMARC. After that, I check the actual sending IP, reverse DNS, and message headers.

The mistake is assuming that a working mailbox means email deliverability is configured correctly.

It doesn't.

You can send and receive perfectly well in webmail while Gmail or Outlook sends your outgoing messages straight to Junk.

Short answer: Open cPanel's Email Deliverability page, verify SPF and DKIM, publish DMARC, check reverse DNS for the actual outbound IP, and test a real message in Gmail. If authentication passes but delivery is still poor, investigate IP reputation and the content of the email before changing more DNS records.

Why cPanel emails are going to spam in 2026

Email providers do not trust a message simply because it came from a working mailbox.

They evaluate sender authentication, domain and IP reputation, message content, recipient engagement, and other indicators.

Three authentication technologies matter most.

SPF (Sender Policy Framework) identifies servers authorized to send email using your domain in the SMTP envelope.

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature that receivers can verify using a public key published in DNS.

DMARC (Domain-based Message Authentication, Reporting and Conformance) checks whether an SPF or DKIM pass aligns with the domain in the visible From address. It also allows the domain owner to publish a policy for messages that fail authentication.

A message can pass SPF and still fail DMARC.

For example, your hosting provider's mail server might authenticate its own envelope-sender domain successfully, while the visible From address uses your business domain.

If neither SPF nor DKIM passes with the required alignment, DMARC fails.

Gmail's sender requirements

Starting February 1, 2024, Google introduced stricter sender requirements for personal Gmail accounts.

All senders must generally:

• Authenticate messages using SPF or DKIM.
• Have valid forward and reverse DNS for their sending infrastructure.
• Use TLS for mail transmission.
• Follow RFC 5322 message formatting requirements.
• Keep user-reported spam rates below 0.3%.

Google also recommends keeping spam rates below 0.1%.

For senders reaching approximately 5,000 or more messages to personal Gmail accounts within a 24-hour period, additional requirements apply.

These include:

• SPF and DKIM authentication.
• A published DMARC record, which may initially use p=none.
• DMARC alignment with the visible From domain.
• One-click unsubscribe for qualifying marketing and subscribed messages.
• A clearly visible unsubscribe link in applicable marketing messages.

The threshold concerns messages sent to personal Gmail accounts, not simply the total number of messages leaving your server.

Google's Email sender guidelines explain these requirements.

Google also announced increased enforcement against non-compliant traffic beginning in November 2025, including temporary and permanent rejections.

Outlook and Hotmail requirements

Microsoft introduced additional requirements for high-volume senders to consumer Outlook.com services beginning May 5, 2025.

For domains meeting Microsoft's high-volume threshold, both SPF and DKIM must pass, and DMARC must pass with at least one aligned authentication mechanism.

An important correction: Microsoft's updated enforcement guidance specifies SMTP rejection for messages failing the required authentication checks.

A rejection may include:

550 5.7.515

This is not simply an ordinary spam-folder placement problem.

See Microsoft's official guidance: Fix NDR error 550 5.7.515.

Shared hosting makes reputation harder to control

With shared hosting, multiple customers may send through the same outbound SMTP IP.

If that IP develops a poor reputation, legitimate messages from unrelated accounts can be affected.

But shared hosting is not automatically bad.

A reputable provider with properly managed mail infrastructure may outperform a newly assigned dedicated IP.

Before buying a dedicated IP, identify the actual source of the delivery problem.

Check Email Deliverability in cPanel first

Before changing DNS, find out what cPanel already reports.

Open:

cPanel → Email → Email Deliverability

The page shows the authentication status for domains associated with your hosting account.

Depending on your configuration and cPanel version, you may see:

• Valid authentication records.
• Problems Exist.
• Suggested SPF or DKIM records.
• Reverse DNS warnings.
• Options to repair or manage existing records.

If Email Deliverability is missing, your hosting provider may have disabled the feature.

The official cPanel Email Deliverability documentation explains the interface.

Step 1: Check the affected domain

Select the domain whose messages are going to spam.

Do not automatically edit your main hosting domain if your application sends from a separate domain.

For example:

• Website: example.com
• Sending address: billing@example.com
• SMTP server: mail.example.com

You need to check authentication for the domain actually used by your email.

Step 2: Open Manage

Click Manage beside the relevant domain.

Review the existing SPF and DKIM records alongside the suggested values.

If cPanel controls the authoritative DNS zone, a Repair option may be available.

Review the proposed changes before approving them.

This is particularly important if your domain also sends mail through Microsoft 365, Google Workspace, or another service.

Blindly replacing a working SPF record can break another legitimate sender.

Step 3: Repair only what is wrong

If the domain's DNS is managed by cPanel and the suggested changes are appropriate, use Repair.

cPanel may take up to five minutes to complete its record recheck.

For me, finding the spam emails was the hectic part: working out which messages were landing in spam and why.

What actually fixed it was going into cPanel, finding the issue on this screen, and correcting the authentication problem instead of guessing at DNS from the outside.

There is one important limitation.

If your authoritative DNS is hosted somewhere else, cPanel generally cannot publish the records there.

For example, if the domain uses Cloudflare nameservers, the changes must be published in Cloudflare.

The same applies to DNS hosted at a registrar or another external provider.

Step 4: Verify the real DNS records

Use a DNS lookup tool or run:

dig +short NS example.com
dig +short TXT example.com
dig +short TXT default._domainkey.example.com
dig +short TXT _dmarc.example.com

The first command identifies the domain's nameservers.

The second checks TXT records, including SPF.

The third checks the example DKIM selector.

The fourth checks DMARC.

Important: default is common for cPanel DKIM, but you must verify the actual selector from your hosting configuration or message headers.

An empty response does not necessarily mean DKIM is missing; the sender might use a different selector.

On Windows PowerShell, you can use:

Resolve-DnsName example.com -Type NS
Resolve-DnsName example.com -Type TXT
Resolve-DnsName default._domainkey.example.com -Type TXT
Resolve-DnsName _dmarc.example.com -Type TXT

Replace example.com with your real domain.

If you recently updated DNS, query an external resolver directly:

dig @1.1.1.1 +short TXT example.com

This helps distinguish stale resolver caches from records that have not been published correctly.

A similar DNS troubleshooting approach is explained in setting a DNS server for a cURL request.

Fix SPF, DKIM, and DMARC records

Authentication records need to be correct for your real mail setup.

Copying somebody else's DNS records will not solve deliverability.

Keep exactly one SPF record

A typical SPF record for a server might resemble:

v=spf1 a mx ip4:203.0.113.10 ~all

The IP address is an example documentation address.

Do not publish it as your real sending IP.

This policy authorizes addresses identified through the domain's A and MX mechanisms, plus the explicitly listed IPv4 address.

It finishes with ~all, meaning other sources receive an SPF soft-fail result.

You should not automatically include a or mx unless those hosts genuinely need authorization to send mail.

A more restrictive configuration might authorize only the known outbound IP:

v=spf1 ip4:203.0.113.10 ~all

If Google Workspace also sends legitimate mail for the domain, you may need:

v=spf1 ip4:203.0.113.10 include:_spf.google.com ~all

Only add Google's SPF mechanism if you actually use that service.

Other mail providers will supply their own authorization instructions.

The common mistake: publishing two separate SPF records.

For example:

v=spf1 ip4:203.0.113.10 ~all

and:

v=spf1 include:_spf.google.com ~all

Publishing both at the same domain is invalid.

SPF evaluation can produce a PermError, preventing the intended authentication result.

Merge all legitimate sending services into a single SPF policy.

Watch the SPF DNS lookup limit

SPF permits a maximum of 10 DNS-querying mechanism and modifier evaluations during policy processing.

Mechanisms such as include, a, mx, and exists, along with redirect, can count toward that limit.

If you combine numerous third-party services, the total can exceed the limit.

That can produce an SPF PermError even when the record looks syntactically correct.

Avoid adding every mail service you have ever used.

Remove obsolete senders, and check the evaluation path with an SPF validation tool.

Do not assume that splitting the record into multiple SPF TXT records fixes this problem. It creates another error.

Should you use ~all or -all?

These endings are not interchangeable.

~all indicates soft fail for unauthorized senders.

-all indicates fail.

While auditing legitimate sending systems, I generally prefer starting with ~all.

Once all sending sources are documented and tested, a stricter SPF policy may be appropriate.

But changing to -all is not a substitute for DMARC, and it does not guarantee better inbox placement.

A strict SPF policy can also cause problems for legitimate messages when sending infrastructure is undocumented or incorrectly configured.

Configure DKIM correctly

DKIM uses a private signing key on the sending server and a matching public key in DNS.

A common cPanel selector is:

default._domainkey.example.com

The corresponding DNS TXT value contains the DKIM public key.

It typically begins with:

v=DKIM1; k=rsa; p=

The p= parameter must contain the actual public key supplied by your email system.

Do not publish the incomplete example above.

Google requires DKIM keys of at least 1024 bits for mail sent to Gmail and recommends 2048-bit keys.

A 2048-bit key is a sensible choice when your hosting infrastructure supports it.

However, do not regenerate a working key without planning the change.

If the private key changes before the matching public key is available in DNS, DKIM verification can fail.

For key rotation, use the hosting provider's supported process and allow DNS updates to propagate before retiring old signing keys.

Also check that your DNS provider stores long DKIM values correctly. Some interfaces automatically split long TXT values into multiple quoted strings within a single record.

That is different from publishing multiple competing records at the same selector.

Publish DMARC and monitor results

DMARC uses a TXT record at:

_dmarc.example.com

An initial policy can be:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

This publishes a monitoring policy and requests aggregate authentication reports.

The rua address must be a real mailbox or a functioning reporting destination that you control.

Be aware that reporting mailboxes can receive substantial XML report traffic.

p=none does not instruct receivers to quarantine or reject failing messages.

It lets you examine authentication and alignment before enforcing a stricter policy.

After monitoring legitimate senders and fixing their authentication, you can consider:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com

For a later enforcement stage:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com

Do not jump to p=reject without testing legitimate traffic.

Forwarded mail, mailing lists, billing systems, and third-party applications can expose authentication problems that were previously unnoticed.

Also remember that DMARC does not require both SPF and DKIM to align simultaneously.

At least one must pass authentication and align with the visible From domain.

For bulk senders, the provider may additionally require both SPF and DKIM authentication checks to pass.

If your DNS uses Cloudflare

When Cloudflare is authoritative for the domain, publish your mail authentication records in Cloudflare DNS.

Use this procedure:

1. Open cPanel Email Deliverability and copy the correct SPF and DKIM suggestions.
2. Open Cloudflare → DNS → Records.
3. Add or edit the SPF TXT record for the sending domain.
4. Add the DKIM TXT record using the complete selector and public key.
5. Add the DMARC TXT record.
6. Verify the published values with an external DNS lookup.
7. Send a real test message.

At the root domain, Cloudflare commonly uses @ as the record name.

For a typical cPanel DKIM selector, use:

default._domainkey

For DMARC, use:

_dmarc

The actual record name can vary when signing from a subdomain.

If your SMTP host uses an A record such as mail.example.com, make sure it is not Cloudflare-proxied.

SMTP and related mail protocols are not handled by Cloudflare's ordinary HTTP reverse proxy.

A conventional MX record points to a hostname, and the mail hostname's A or AAAA record should resolve directly to the appropriate mail server.

For website-side proxy issues, see Cloudflare JS Challenge Breaking a Laravel SPA.

All records pass, but emails still go to Junk

This is where many troubleshooting guides stop too early.

You can have SPF, DKIM, and DMARC all passing and still land in spam.

Authentication establishes whether a message is authorized. It does not establish whether the recipient wants it.

Verify the actual sending IP

Do not assume that the Shared IP Address shown in cPanel is the outbound mail IP.

Your host may route email through a different SMTP server or external filtering service.

Send a test message to Gmail.

Open the message, choose Show original, and examine its authentication results and Received headers.

Identify the outbound server and its IP from the message path.

Then check reverse DNS:

dig +short -x 203.0.113.10

Replace the example IP with the actual outbound address.

Suppose the result is:

server123.yourhost.com.

Check forward DNS:

dig +short A server123.yourhost.com

You generally want the reverse hostname to resolve forward to the sending IP.

If the SMTP connection uses another IP, check that address too.

For IPv6 sending, verify the corresponding AAAA and PTR records.

In hosted environments, your provider usually controls reverse DNS for its IP addresses.

Ask them to correct the configuration rather than adding unrelated DNS records to your domain.

Check the SMTP hostname and HELO identity

A sending server normally identifies itself during the SMTP conversation using EHLO.

Poorly configured servers sometimes identify themselves with a hostname that does not resolve properly.

While the HELO identity does not always have to be identical to the visible From domain, it should be a legitimate, properly configured server identity.

If you use cPanel's managed Exim service, ask the hosting provider to check the outbound SMTP hostname, IP selection, and reverse DNS configuration.

Check reputation and blocklists

Look up the actual sending IP using a service such as MXToolbox.

A blocklist result can indicate a problem, but not every list is equally important to every receiving provider.

A clean result also does not guarantee good reputation at Gmail or Microsoft.

For Gmail traffic, Google Postmaster Tools may provide useful domain reputation, compliance, and spam-rate information when sufficient data is available.

For Microsoft consumer mail, use the available sender-support and postmaster resources.

If the IP is shared, your hosting provider is usually best placed to investigate its reputation and request any appropriate delisting.

Check the email itself

I would also inspect the messages that are being filtered.

Common problems include:

• Sending unsolicited bulk messages.
• Using misleading subject lines.
• Linking to suspicious or compromised domains.
• Sending through inconsistent domains and providers.
• Using a newly established domain at high volume.
• Sending to old contact lists with excessive bounces.
• Repeatedly emailing people who do not engage.
• Sending messages from contact forms that impersonate the visitor.

Avoid trying to bypass spam filters with unusual formatting tricks.

Write clear messages, send to legitimate recipients, and make unsubscribing easy when applicable.

When should you switch to an SMTP relay?

Consider a reputable transactional email service when:

• Your hosting provider cannot fix outbound authentication or PTR problems.
• Important password resets and invoices are being delayed or rejected.
• The shared mail IP has persistent reputation issues.
• You need reliable sending logs, bounce handling, and API or SMTP integration.
• Your legitimate sending volume exceeds practical shared-hosting limits.

Possible providers include Amazon SES, Mailgun, Postmark, and Resend.

A dedicated IP is not automatically the best choice.

For smaller senders, a reputable provider's shared IP pool may be easier to operate successfully.

When migrating, configure SPF, DKIM, DMARC alignment, return-path settings where supported, and any tracking domains required by the provider.

Do not delete the old provider's authentication records until the migration is complete and its remaining legitimate messages have stopped.

Fix Laravel and PHP mail on cPanel

If your PHP website or Laravel application sends email, it needs a properly authenticated sending configuration.

Laravel 12 supports SMTP and several API-based email transports.

See the Laravel 12 mail documentation.

Configure Laravel SMTP

First, create a real email account in cPanel.

For example:

no-reply@example.com

Open cPanel's Connect Devices interface for that mailbox and check the recommended SMTP hostname, port, and encryption settings.

For a server supporting authenticated SMTP with STARTTLS on port 587, a typical .env configuration is:

MAIL_MAILER=smtp
MAIL_HOST=mail.example.com
MAIL_PORT=587
MAIL_USERNAME=no-reply@example.com
MAIL_PASSWORD="replace-with-real-password"
MAIL_FROM_ADDRESS=no-reply@example.com
MAIL_FROM_NAME="${APP_NAME}"

Replace every example value with the actual details supplied by your hosting provider.

Use the correct SMTP hostname so TLS certificate validation succeeds.

For some hosting environments, the secure SMTP hostname is the server hostname rather than mail.example.com.

If your provider requires implicit TLS on port 465, configure the SMTP transport accordingly. Do not change the port without also checking the required encryption mode.

Recent Laravel installations commonly rely on Symfony Mailer's transport settings and scheme handling. Check the relevant config/mail.php implementation before applying settings copied from an older Laravel project.

Never disable TLS certificate verification just to make authentication work.

Clear cached configuration

If your production Laravel application has cached configuration, changing .env alone may not affect the active settings.

Run this from the Laravel project directory:

php artisan config:clear

If your deployment normally uses cached configuration, rebuild it after verifying the environment values:

php artisan config:cache

Be careful with these commands on a production application.

They affect the application's configuration cache, so apply them using your normal deployment process.

If you are using long-running queue workers, restart them after configuration changes:

php artisan queue:restart

This tells Laravel queue workers to exit gracefully after their current jobs, so your process manager can restart them with the updated configuration.

A process manager must be configured to bring the workers back.

Send a real test message

You can create a simple Laravel mail test using Tinker.

Open:

php artisan tinker

Then run:

\Illuminate\Support\Facades\Mail::raw(
    'Laravel SMTP delivery test.',
    function ($message) {
        $message->to('your-test-address@gmail.com')
                ->subject('SMTP delivery test');
    }
);

Replace the recipient with an email address you control.

If the command completes successfully, the configured transport accepted the message for sending.

That does not prove inbox delivery.

Check the receiving mailbox, Spam folder, and message headers.

For authenticated delivery, inspect the SPF, DKIM, and DMARC results in Gmail's Show original view.

Configure a Laravel failover mailer

Laravel supports failover mail transports.

If the primary provider is unavailable or fails during sending, Laravel can attempt another configured transport.

An example configuration inside the existing mailers array in config/mail.php is:

'failover' => [
    'transport' => 'failover',
    'mailers' => ['smtp', 'postmark'],
    'retry_after' => 60,
],

This example assumes that the smtp and postmark mailers are both already configured correctly.

It is not a complete replacement for config/mail.php.

Then configure:

MAIL_MAILER=failover

Clear or rebuild Laravel's configuration cache as appropriate.

Important: failover does not detect whether a message later lands in the recipient's spam folder.

If the primary SMTP server accepts the message successfully and the recipient subsequently filters it, the backup mailer will not automatically resend the email.

This is a common misunderstanding.

Also ensure both mail transports are authorized to send for the selected From domain.

Otherwise, failover could introduce authentication failures.

Queue emails properly

For invoices and notifications, queueing helps prevent slower mail transports from blocking web requests.

For example:

use Illuminate\Support\Facades\Mail;

Mail::to($customer->email)
    ->queue(new InvoiceMail($invoice));

This assumes InvoiceMail is an existing mailable with a valid constructor and queue-compatible configuration.

The queue connection and worker must also be running.

For example, if your application uses a database queue:

QUEUE_CONNECTION=database

Ensure the required queue database tables exist, then start a worker:

php artisan queue:work

On production systems, use an appropriate process manager so the worker remains available.

Queued mail is not necessarily sent immediately.

If the worker is stopped, the queue may continue collecting jobs without sending them.

For larger applications, chaining Laravel queue batches can help coordinate related background operations.

But batching jobs does not bypass your SMTP provider's sending limits.

Do not spoof Gmail from PHP

Avoid using PHP's mail() function with a From address belonging to a domain you do not control.

For example:

mail(
    $to,
    'New order',
    $body,
    'From: myshop@gmail.com'
);

A normal cPanel server is not authorized to sign mail using Gmail's DKIM domain.

Its SPF authentication also will not ordinarily align with the visible Gmail From address.

This causes authentication and impersonation problems.

Use a domain you own and have configured for sending instead.

For contact forms, keep the visitor's address in Reply-To.

In a Laravel mailable, for example:

use Illuminate\Mail\Mailables\Address;
use Illuminate\Mail\Mailables\Envelope;

public function envelope(): Envelope
{
    return new Envelope(
        from: new Address(
            'no-reply@example.com',
            'Example Site'
        ),
        replyTo: [
            new Address(
                $this->visitorEmail,
                $this->visitorName
            )
        ],
        subject: 'New contact form message',
    );
}

This example belongs inside an existing Laravel mailable class.

It assumes $this->visitorEmail and $this->visitorName are populated from validated contact-form input.

Validate email addresses and sanitize or validate visitor-provided names before using them in message headers.

Also use appropriate form protections and rate limiting so attackers cannot abuse the contact form to send unsolicited mail.

FAQ

Why are my cPanel emails going to spam even though SPF passes?

SPF only verifies authorization for the SMTP envelope identity.

It does not guarantee DMARC alignment or inbox placement.

Check whether DKIM passes, whether DMARC aligns with the visible From domain, and whether your outbound IP has reputation issues.

Review the actual received message headers rather than relying only on DNS lookup results.

Does DMARC p=none help emails reach the inbox?

A p=none policy does not tell receivers to quarantine or reject messages that fail DMARC.

It can help satisfy applicable sender authentication requirements and allows you to collect aggregate reports.

However, publishing p=none alone does not automatically improve the sender's reputation or inbox placement.

You still need valid authentication and healthy sending practices.

Why does Outlook reject my email while Gmail accepts it?

Gmail and Microsoft operate separate reputation and filtering systems.

For high-volume senders, Microsoft also enforces SPF, DKIM, and DMARC requirements.

If Outlook returns error 550 5.7.515, check the message's authentication and DMARC alignment against Microsoft's published requirements.

If the message is accepted but placed in Junk, investigate reputation, content, and recipient engagement as well.

How do I confirm that SPF, DKIM, and DMARC work?

Send an email from the affected mailbox or application to a Gmail address you control.

Open the received email and select Show original.

Look for results such as:

SPF: PASS
DKIM: PASS
DMARC: PASS

These are illustrative results, not the complete raw email header.

Inspect the actual domains associated with the SPF and DKIM results to confirm that at least one authentication result aligns with the visible From domain.

You can also use a service such as mail-tester.com for additional diagnostic feedback.

Final verification: Send separate tests from cPanel webmail, your desktop email client, and Laravel or PHP if you use them. Different sending paths can use different servers and authentication identities. A successful webmail test does not prove that your website's contact form is configured correctly.

If authentication passes but cPanel emails going to spam remains a problem, focus on the actual outbound IP, SMTP infrastructure, delivery errors, and message reputation rather than repeatedly changing valid DNS records.

For additional assistance, contact HeadsNTail.