Why Your Emails Land in Spam (and How SPF, DKIM, DMARC and PTR Fix It)

Your emails land in spam because receiving servers such as Gmail and Outlook.com cannot confirm that your server is allowed to send for your domain, or because your domain and IP have little or no sending reputation. You fix it by publishing four records: SPF lists which servers may send your mail, DKIM cryptographically signs each message, DMARC tells receivers what to do when those checks fail, and PTR (reverse DNS) maps your server IP back to a matching hostname. This guide shows how to check, create and verify all four on cPanel hosting or on an Ubuntu VPS, and then how to build reputation so your mail reaches the inbox.

Prerequisites

• Access to the DNS zone for your domain. This is cPanel Zone Editor if your nameservers point to your hosting, otherwise your DNS provider such as Cloudflare.
• cPanel login for shared hosting, or root/sudo SSH access for a VPS or dedicated server.
• A list of every service that sends mail as your domain: your hosting, Google Workspace, Microsoft 365, newsletter tools, CRMs and so on.
• A mailbox to receive DMARC reports, for example dmarc@example.com.

What do SPF, DKIM, DMARC and PTR actually do?

• SPF: a TXT record on your domain that lists the IPs and services allowed to send mail for it.
• DKIM: a public key in DNS that receivers use to verify a signature your server adds to every outgoing message.
• DMARC: a policy that requires SPF or DKIM to pass and to match the visible From domain. It also tells receivers to monitor, quarantine or reject failures, and where to send reports.
• PTR: a reverse DNS record that maps your sending IP to a hostname. That hostname should resolve back to the same IP and match the name your server announces in its HELO.

1. How do I check my current email DNS records?

On Ubuntu 22.04 or 24.04, install dig if it is missing, then query each record:

sudo apt update && sudo apt install -y bind9-dnsutils
dig +short MX example.com
dig +short TXT example.com | grep spf1
dig +short TXT default._domainkey.example.com
dig +short TXT _dmarc.example.com
dig +short -x 203.0.113.10

cPanel uses the DKIM selector default. Other providers use different selectors, for example google, selector1 and selector2. If you prefer a browser, MXToolbox (mxtoolbox.com) offers SPF, DKIM, DMARC, reverse DNS and blacklist lookups. Its blacklist check is worth running against your server IP.

2. How do I create a correct SPF record?

Mail sent from cPanel

In cPanel go to Email > Email Deliverability, find your domain and click Manage. The SPF section shows a suggested record. If your DNS is hosted on the server, click Install the suggested record. If your DNS is hosted elsewhere, copy the record to your DNS provider. A typical result:

example.com.  TXT  "v=spf1 +a +mx +ip4:203.0.113.10 ~all"

Google Workspace or Microsoft 365

If mailboxes live with Google or Microsoft but your website also sends mail from the server, include both in the same record:

# Google Workspace + web server
v=spf1 ip4:203.0.113.10 include:_spf.google.com ~all

# Microsoft 365 + web server
v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com ~all

Start with ~all (softfail). Switch to -all only after DMARC reports confirm that every legitimate sender is listed.

3. How do I enable DKIM in cPanel?

Go to Email > Email Deliverability > Manage for your domain. The DKIM section shows whether a key exists and whether the published record is valid.

• DNS on the server: click Install the suggested record, or Repair on the domain list.
• DNS elsewhere: copy the record name default._domainkey.example.com and the full TXT value into your DNS provider exactly as shown. If the value is long, your provider may split it into quoted strings, which is fine.

On a server with WHM, the same tool is available at WHM > Email > Email Deliverability. Google Workspace and Microsoft 365 have their own DKIM setup in their admin consoles. Enable DKIM there as well, because cPanel only signs mail that cPanel sends.

4. What DMARC policy should I start with?

Start in monitoring mode so nothing legitimate gets blocked while you collect reports. In cPanel go to Domains > Zone Editor > Manage for your domain, add a TXT record named _dmarc, and enter:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1"

Receivers will send daily XML aggregate reports to the rua address. Review them for two to four weeks to find senders you forgot. Once all legitimate mail passes, tighten the policy in stages:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
v=DMARC1; p=reject; rua=mailto:dmarc@example.com

5. How do I set reverse DNS (PTR) and a matching HELO hostname?

On shared hosting, Cloudesta already manages PTR for the shared server IPs. On a Cloud VPS or dedicated server, you need to set it up:

• Create an A record for a mail hostname, for example mail.example.com pointing to 203.0.113.10.
• Open a support ticket asking Cloudesta to set the PTR for 203.0.113.10 to mail.example.com. PTR records belong to the IP owner, so you cannot set them from your own DNS.
• Set the server hostname and the name your mail server announces in HELO to the same value.

On Ubuntu with Postfix:

sudo hostnamectl set-hostname mail.example.com
sudo postconf -e 'myhostname = mail.example.com'
sudo systemctl reload postfix
postconf myhostname smtp_helo_name

On a cPanel/WHM server, use WHM > Networking Setup > Change Hostname instead. The goal is forward-confirmed reverse DNS: the IP resolves to mail.example.com, and mail.example.com resolves back to the same IP.

6. Why do Gmail and Outlook.com still junk or reject my mail?

Authentication is required, but it does not guarantee inbox placement. The usual causes are:

• Missing or failing records. Gmail, Yahoo and Outlook.com now require SPF, DKIM and DMARC from bulk senders, and they increasingly reject unauthenticated mail outright.
• Poor IP or domain reputation. Causes include a blacklisted IP, a brand-new domain, or a compromised script or mailbox that sent spam.
• Marketing content. Watch for image-only messages, URL shorteners, spammy subject lines, and mismatched link text.
• No unsubscribe. Bulk mail must include a List-Unsubscribe header with one-click support, and you must honour opt-outs promptly.
• Complaints. Gmail expects a spam-complaint rate below 0.3%. Sending to purchased or stale lists pushes you over that limit quickly.

For newsletters, use a dedicated email service provider rather than your web server. For staff mailboxes, a managed service such as Cloudesta Business Email takes care of the sending infrastructure for you.

7. How do I warm up a new domain or IP?

• Publish SPF, DKIM, DMARC and PTR before you send anything.
• Start with a few dozen messages a day to engaged recipients who are likely to open and reply.
• Roughly double the volume every few days over three to six weeks, and watch bounces and complaints.
• Register with Google Postmaster Tools and Microsoft SNDS to monitor your reputation.

Verify it works

Send a message to a Gmail address. Open it, then choose More > Show original. You should see SPF: PASS, DKIM: PASS and DMARC: PASS. From any Ubuntu machine, confirm that the PTR and the forward lookup match:

dig +short -x 203.0.113.10        # expect mail.example.com.
dig +short A mail.example.com     # expect 203.0.113.10

mail-tester.com is also useful: send a message to the address it gives you to get a combined score covering authentication, content and blacklists.

Common problems

• SPF shows "permerror: too many DNS lookups" → SPF allows a maximum of 10 lookups, and each include, a and mx counts, including nested ones. Remove services you no longer use and replace a/mx with ip4: entries.
• DKIM fails with "no key" or "body hash did not verify" → Check the s= value in the message's DKIM-Signature header. It must match the DNS record name, for example s=default means the record must be default._domainkey. Also make sure the TXT value was pasted completely, without extra spaces or quotes.
• Forwarded mail fails SPF → Forwarding sends your message from the forwarder's IP, which is not in your SPF record. DKIM survives forwarding, so make sure DKIM passes and aligns. That keeps DMARC passing even when SPF fails.
• Two SPF records exist → Delete one and merge all mechanisms into a single v=spf1 record.
• Outlook.com rejects mail with error code S3150 or similar → Check your IP on MXToolbox. If it is blocklisted, remove the cause first, then submit Microsoft's delisting form.

Frequently asked questions

How long do DNS changes for SPF, DKIM and DMARC take to work?

Usually minutes to a few hours, depending on the record's TTL. PTR changes take effect once Cloudesta support confirms the update on your ticket.

Should I use ~all or -all in SPF?

Use ~all while you are still finding all your senders. Switch to -all once your DMARC reports show that every legitimate source passes.

Can I set reverse DNS myself on my Cloudesta VPS?

No. PTR records are controlled by the IP owner, so open a support ticket with the IP and the hostname you want, and make sure that hostname already has a matching A record.

Need help? Open a ticket at https://cloudesta.com/submitticket.php with your domain, server IP and a full copy of a bounced or junked message's headers.