Fix 'Invalid' Status in cPanel's Email Deliverability Tool
You open cPanel, click into Email > Email Deliverability, and see a red "Invalid" or "Not Enabled" next to your domain. Nothing about your mail looks broken to you — so why is cPanel complaining? Here's what that page is actually checking, and how to clear each status without breaking mail that already works.
What the Email Deliverability tool actually does
Every time you add a domain to cPanel, it can generate a local SPF and DKIM TXT record for that domain, meant to authenticate mail sent through cPanel's own Exim mail server. The Email Deliverability page (cPanel > Email > Email Deliverability, or WHM > Email > Email Deliverability if you manage multiple accounts) compares what cPanel expects to see in DNS against what's actually published, and flags a status for each domain.
It only checks the records cPanel itself cares about — SPF and DKIM for the local mail server, plus a DMARC check on some versions. It has no idea whether you're using Google Workspace, Titan, Zoho, or cPanel's own webmail for actual mail delivery. That mismatch is where most of the confusion starts.
Reading the statuses
| Status | What it means |
|---|---|
| Valid | DNS matches what cPanel expects exactly. No action needed. |
| Invalid – Local Record Conflicts | A record exists at that host, but it doesn't match cPanel's expected value — usually because something else (Google Workspace, Titan, Zoho, a manual edit) added its own SPF or DKIM record. |
| Not Enabled | No record exists at all yet. Common right after adding a new domain, or when DNS is hosted outside cPanel. |
| No Authority | cPanel isn't the authoritative DNS for this domain (nameservers point elsewhere, e.g. Cloudflare), so it can't check or fix anything automatically. |
Symptom: "Invalid – Local Record Conflicts" after switching to Google Workspace or Titan
Cause: when you moved your mail off cPanel's Exim and onto an external provider, you (or your provider's setup wizard) added a new SPF TXT record with include:_spf.google.com or similar. cPanel's local zone still has its own older SPF record from when the domain was first added. Two separate SPF TXT records at the same host is technically invalid per the SPF spec, and it's exactly what the tool is flagging.
Fix: you need exactly one SPF record per domain, merged. In cPanel's Zone Editor (Domains > Zone Editor > Manage), find both TXT records starting with v=spf1 and combine them into a single line:
v=spf1 include:_spf.google.com include:secureserver.net ~allDelete the duplicate, keep only the merged one, then go back to Email Deliverability and click Repair (or Manage > Update) to re-scan. If your mail flows entirely through the external provider and cPanel never sends outbound mail for that domain, you can drop the cPanel-specific mechanism entirely — just make sure whatever remains still authorizes your actual sending source.
Symptom: DKIM shows "Not Enabled" even though mail is working fine
Cause: this is common on domains added a while ago, before DKIM signing was default, or on accounts migrated from another server where DKIM keys weren't carried over. Mail can still be "working" in the sense that it's delivered — it's just not signed, which hurts deliverability over time and will eventually get flagged by receiving mail servers.
Fix: from the Email Deliverability page, click the domain's Manage button and select Install the Suggested DNS Records. cPanel generates a fresh DKIM keypair and pushes the public key as a TXT record automatically — no manual copying needed, as long as cPanel is authoritative for the zone.
If your nameservers point to Cloudflare or another external DNS provider (you'll see "No Authority" instead of "Not Enabled" in that case), cPanel can't push the record for you. Click View DNS Records to copy the exact host and value it wants, then add that TXT record manually wherever your DNS is actually managed. It'll look something like this:
Host: default._domainkey.example.com
Type: TXT
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSq...Give it 15–30 minutes to propagate, then re-check the tool.
Symptom: the tool keeps flagging a domain you don't even send mail from
Cause: parked domains and addon domains inherit an entry in Email Deliverability by default, even if nothing ever sends mail as that name. It's cPanel being cautious — any domain on the account could theoretically be used to send mail through Exim, so it wants every one authenticated.
Fix: if the domain genuinely never sends mail, the cleanest fix is still to publish a minimal SPF record that hard-fails everything:
v=spf1 -allThis tells receiving servers "nothing is authorized to send as this domain, ever," which both satisfies the deliverability check and closes off a spoofing vector — domains with no SPF record at all are easier to forge convincingly.
Preventing this from creeping back
- Any time you switch email providers (moving to or off Google Workspace, Titan, Zoho), re-check Email Deliverability the same day — don't wait for a bounce to notice a conflict.
- Keep one merged SPF record per domain, never two. If a setup wizard tells you to "add this SPF record," check the zone first for an existing one to merge into instead of pasting a second.
- If DNS is managed outside cPanel (Cloudflare, Route 53, your registrar), don't rely on the automatic Repair button — it can't reach that zone. Copy records manually and re-check.
- Revisit the tool after any server migration; DKIM keys don't always carry over automatically and a "Not Enabled" status post-migration is easy to miss.
None of this is cosmetic. Mailbox providers increasingly treat a broken or duplicate SPF record as a stronger spam signal than having no SPF at all, so a red status here is worth clearing even if mail seems to be arriving fine today.
Frequently asked questions
Will fixing the Email Deliverability status affect mail that's already working?
Not if you merge records correctly instead of just deleting one. Removing an SPF record your live provider relies on will break authentication for that provider, so always combine the mechanisms into a single record rather than picking one to delete.
Why does WHM show different results than my cPanel account's Email Deliverability page?
WHM's version scans every account on the server at once and is meant for resellers or admins managing multiple domains. The underlying checks are identical — same SPF, DKIM, and DMARC logic — just surfaced per-account instead of individually.
I clicked Repair and it says it succeeded, but the status still shows Invalid. Why?
DNS propagation delay. cPanel writes the record immediately if it's authoritative, but the tool's re-check can query before the change has fully propagated, especially with a high existing TTL. Wait 15–30 minutes and re-scan before assuming the repair failed.
Do I need DMARC too, or is SPF and DKIM enough for a Valid status?
cPanel's tool primarily checks SPF and DKIM; DMARC isn't always required for a Valid status depending on your cPanel version. That said, publishing a DMARC record is still worth doing separately — it tells receiving servers what to do when SPF or DKIM fail, which neither record does on its own.
Can I just ignore a domain stuck on 'No Authority'?
Yes, if you're intentionally managing DNS elsewhere (Cloudflare, a dedicated DNS provider) — that status is informational, not an error. It just means cPanel can't verify or auto-repair records for that zone, so any fixes need to happen manually at your actual DNS host.