Why business email lands in spam — SPF, DKIM, DMARC

When invoices, OTPs, or bank follow-ups from @yourcompany.in keep landing in spam, the problem is rarely “Gmail is broken.” Receivers check whether your domain authorises the server that sent the mail. Three DNS records do most of that work: SPF, DKIM, and DMARC.

SPF — who may send as you

SPF is a TXT record that lists the mail systems allowed to send for your domain. After you move to Titan, Google Workspace, or another business email host, the old SPF (or none at all) must be replaced with the provider’s include. Two competing SPF records, or a leftover cPanel include after a switch, is a common cause of silent rejects.

DKIM — the message signature

DKIM signs outbound mail so the receiver can verify it left an authorised system and was not altered. Providers give you a CNAME or TXT selector to publish. Until that DNS is live (and cached), mail may still send — but trust scores stay weak. After any host change, send a test to an external inbox and confirm DKIM passes in the message headers.

DMARC — what to do with failures

DMARC tells receivers how to treat mail that fails SPF/DKIM alignment, and optionally where to send reports. Start with a monitoring policy (p=none) if you are unsure who still sends as your domain, then tighten once reports look clean. Skipping DMARC is less dangerous than publishing a hard reject while a marketing tool or old server still sends without SPF/DKIM.

Quick checks before you open a ticket

• One SPF TXT at the root — not two.
• DKIM selector published exactly as the panel shows.
• MX still points at the current mail host (see domain DNS basics).
• Test from a phone on mobile data to a Gmail or Outlook personal inbox.

Need DNS aligned after a mail move? Contact KC Cloud or raise a support ticket with your domain and provider name. Check status if the mail panel itself is unreachable.