Cloudflare + Titan / cPanel Mail: SPF, DKIM and DMARC setup that passes

If your Titan / cPanel Mail mail is landing in spam, or someone is sending invoices as your domain, the cause is almost always the same three records — published wrongly, published twice, or never published at all. This guide fixes that for a domain whose DNS lives at Cloudflare.

What each record does

Three records, three separate jobs. Publishing one and assuming you are covered is the usual reason mail still lands in spam.

Since 2024 Gmail and Microsoft both expect all three from anyone sending at volume. A missing DMARC record alone is now enough to affect placement.

Step 1 — Find the DNS editor and lower the TTL

In Cloudflare: Dashboard → select domain → DNS → Records → Add record

Leave TTL on Auto — Cloudflare serves it at 300 seconds, which is already what you want. TTL is how long resolvers cache a record — at four hours, a typo takes four hours to correct everywhere; at five minutes it is effectively reversible. Put it back once everything passes.

Step 2 — Audit what is already there

List every record of type TXT and write down anything starting with v=spf1.

• Zero SPF records — straightforward; you add one in step 3.
• Exactly one — you will edit it, not add another.
• Two or more — already broken, and the most common state we find. Step 3 fixes it by merging.

Note any include from a previous host. Whether you keep it comes down to one question: does that server still send mail for you? A website contact form or WooCommerce order notification counts. If nothing sends from there any more, drop it.

Step 3 — Publish exactly one SPF record

Add a new record in Cloudflare with these values:

Cloudflare accepts @ or the bare subdomain and shows you the resulting full name below the field. Read it before saving. Content goes in unquoted. Cloudflare will not accept line breaks.

If you also send from your website or another service

Merge, never duplicate. One record, one v=spf1 at the start, one ~all at the end, every include in between:

v=spf1 include:spf.titan.email include:othersender.example ~all

Keep the total number of DNS-resolving mechanisms — every include:, a:, mx: and redirect= — at ten or fewer. Above ten, SPF returns a permanent error and fails as though absent.

Why ~all rather than -all? Softfail marks unlisted senders as suspicious; hardfail rejects them outright. Start with ~all and tighten once DMARC reports confirm nothing legitimate is being missed. Never use +all — it authorises the entire internet to send as you.

Step 4 — Generate the DKIM key in Titan / cPanel Mail

This half happens in Titan / cPanel Mail, not Cloudflare. Go to Titan control panel (or your host's email dashboard) → Settings → Domain settings → DNS records.

1. Open the DNS records panel in Titan; the DKIM records are pre-generated, not created on demand.
2. Copy both CNAME targets — typically titan1.dkim.titan.email and titan2.dkim.titan.email.
3. If you use cPanel's own mail server instead of Titan, the selector is default._domainkey and cPanel generates the TXT record itself under Email Deliverability.
4. In that case copy the value cPanel shows rather than creating your own key.

Leave that tab open — you come back to it in step 5, and forgetting to is the second most common failure.

Add the DKIM records in Cloudflare

Use the bare host as shown — not the full titan1._domainkey.yourdomain.com, for the same reason as the SPF record. If the value is rejected as too long, remove any line breaks your clipboard introduced; it must be one continuous string.

Step 5 — Switch signing on (the step everyone forgets)

Titan verifies automatically once the records resolve — the DNS panel turns green, with no separate switch to flip. For cPanel mail, the Email Deliverability page has a Repair button that publishes anything missing when it manages your DNS.

If you kept cPanel mail for some addresses and moved others to Titan, both SPF includes must appear in the same single record. This is the most frequent half-migration mistake we are called in to fix.

Step 6 — Publish DMARC in monitoring mode

Back in Cloudflare, one more record:

Start at p=none. It enforces nothing, but it starts the aggregate reports arriving, and those reports are how you find the sender you forgot about — the invoicing tool, the CRM, the old newsletter platform.

Resist going straight to p=reject. On a domain with a forgotten sender, reject means those messages vanish silently, and the first you hear of it is a client asking why they never got your quote.

Step 7 — Verify, then tighten

Wait fifteen minutes, then check all three. From a terminal:

dig yourdomain.com TXT +short
dig titan1._domainkey.yourdomain.com CNAME +short
dig _dmarc.yourdomain.com TXT +short

Or run the domain through our record checker, which flags duplicates and weak policies for you. For an end-to-end test, send a message to a Gmail address you own, open it and use Show original — you want PASS beside SPF, DKIM and DMARC.

The tightening schedule

• Week 1–2: leave p=none and read the reports. Identify every legitimate sender.
• Week 3: add missing senders to SPF (merged into the one record), then move to p=quarantine.
• Week 5+: if reports stay clean, move to p=reject and change SPF to -all.
• Finally: restore the TTLs.

A note on MX records

Titan's MX records are mx1.titan.email (priority 10) and mx2.titan.email (20). cPanel mail uses mail.yourdomain.com. Running both at once needs deliberate routing configuration — it does not work by default.

Authentication cannot fix a routing problem. If mail is not arriving at all — as opposed to arriving in spam — the MX records are where to look first, not SPF.

When it still does not work

Mail still in spam with all three passing

Authentication is necessary, not sufficient. Check your domain and sending IP against a blocklist, make sure you are not mailing purchased lists, and give a brand-new domain a few weeks of low-volume sending before expecting good placement.

Titan / cPanel Mail says the DKIM record cannot be found

Nine times out of ten the host field contains the domain twice. Open the record in Cloudflare and confirm it reads exactly titan1._domainkey and titan2._domainkey.

SPF was fine, then broke after adding a service

That service told you to "add this SPF record" and you added a second one. Merge them into one.

DMARC reports arrive as unreadable XML

They are meant to — the format is for machines. Paste one into any free DMARC report analyser, or point rua at a reporting service that renders them for you.