Why Your Business Emails Land in Spam: SPF, DKIM, DMARC and PTR Explained

Start with the message, not a random DNS change

A customer says an invoice never arrived. Before editing records, collect the sender, recipient, timestamp, full message headers and any bounce response. Check the mail log or provider's delivery trace. Was the message rejected, temporarily deferred, accepted into spam, or never submitted by the application? These outcomes require different fixes.

Preserve this evidence before making changes. A screenshot of a green DNS checker is less useful than the receiving system's actual authentication results for the affected message.

SPF: which servers may send?

Sender Policy Framework authorizes sending servers for an envelope-sender domain, normally reflected in the Return-Path. It does not directly authenticate the address readers see in the From field. Inventory every legitimate source: staff mailboxes, website forms, billing software, helpdesks and marketing platforms.

Publish one SPF policy per domain, merging authorized sources rather than adding competing SPF records. SPF evaluation permits at most ten DNS-querying terms, including nested lookups; careless includes can exceed that limit. Forwarding can also break SPF because the forwarding server becomes the connecting sender. See the SPF specification.

DKIM: can the recipient verify the signature?

DomainKeys Identified Mail adds a cryptographic signature to selected headers and message content. The recipient retrieves a public key from DNS using the signature's selector and signing domain. A successful check establishes that the signed portions survived verification under that domain's key; it does not certify the sender's intentions.

Enable signing on each sending platform and publish its own selector as instructed. A DNS key alone does not make outgoing messages signed. Confirm the actual message contains a valid DKIM signature, and investigate modifications introduced by gateways or mailing systems when validation fails. Reference: DKIM specification.

DMARC: does authentication match your visible identity?

DMARC connects the visible From domain with SPF or DKIM. A message passes when at least one of those methods both passes authentication and aligns with the From domain under the applicable alignment mode. Passing SPF for an unrelated provider domain is therefore insufficient by itself.

For example, a billing platform can pass SPF for its own bounce domain while sending as your business. An aligned DKIM signature for your domain can provide the DMARC pass. Check both identity and result rather than counting green authentication labels.

Begin a managed rollout with reporting, identify legitimate services, and correct alignment before moving to enforcement. A monitoring policy such as p=none requests no DMARC-based quarantine or rejection; it does not prevent spoofing by itself. Review aggregate reports and test critical workflows before tightening policy. Reference: DMARC specification.

PTR: does the sending IP have a consistent hostname?

Reverse DNS maps an IP address to a hostname. Forward DNS should resolve that hostname back to the same sending IP. Google explicitly requires this consistency for mail sent to personal Gmail accounts. Check every outbound address actually used, including IPv6 when enabled.

The IP owner or infrastructure provider normally controls PTR records. Adding a PTR entry inside an ordinary domain zone usually does not configure the IP's authoritative reverse DNS. When using an external SMTP relay, investigate the relay's outbound IP rather than assuming your website server is the sender.

Why authenticated messages can still land in spam

Authentication is a foundation, not an inbox guarantee. Google also considers sending behavior and reputation. Shared-IP abuse can affect other customers using that address. Send only wanted mail, honor unsubscribes, investigate complaints and keep traffic patterns predictable.

For Gmail bulk senders, Google's published requirements include SPF, DKIM, DMARC and alignment, with one-click unsubscribe for marketing and subscribed messages. Requirements vary by recipient provider; review the current Gmail sender guidelines when planning changes.

A practical cPanel investigation

1. List sending systems. Test staff email, website notifications and billing messages separately.
2. Open Email Deliverability. Review the domain's suggested records and reported issues.
3. Check authoritative DNS. When DNS is hosted externally, publish changes there. A local cPanel repair may not update public DNS.
4. Ask the IP provider about PTR. Validate the reverse and matching forward records.
5. Retest real messages. Inspect recipient authentication results and correlate them with delivery logs.

Follow the cPanel Email Deliverability documentation for interface details. Avoid replacing a working third-party mail policy with server-local defaults without reviewing every sender.

Make delivery checks part of routine operations

Keep a record of sending platforms, DNS owners, DKIM selectors and change dates. Repeat tests after migrations, relay changes and application updates. For broader operational visibility, read our guide to proactive server monitoring.

HostGree helps investigate email delivery failures, review authentication and reverse DNS, and troubleshoot hosting mail infrastructure. Bring a failed message, its headers and the delivery timeline so the investigation starts with evidence.