The Email Deliverability screen checks whether your domains are set up so that receiving servers will accept mail from them. It appears in both WHM and cPanel, and it is the fastest way to find out why a domain's mail is being filtered.
It is also frequently ignored because it reports problems in DNS rather than in the mail server, which people assume is somebody else's job.
What it actually checks
Three things per domain, and it tells you which are wrong rather than that something is.
SPF, whether a record exists and whether this server is authorised by it.
DKIM, whether a key exists for the domain and whether the published record matches it.
Reverse DNS, whether the sending address resolves back to a hostname, and whether that hostname resolves forward to the same address.
A domain passing all three is not guaranteed delivery, and a domain failing any of them is being scored against on every message. Understanding SPF, DKIM and DMARC Records explains what each does.
Read the status, not the colour
The screen shows a status per domain, and the useful part is the detail behind it.
Valid. The record exists and matches what the server expects.
Problems exist: something is missing or does not match, with the expected value shown alongside what is actually published. That comparison is the whole diagnosis.
Not managed here. The domain's DNS is elsewhere, so the server can report the problem and cannot fix it.
That last case is the one people misread as broken. It is not; it means the fix has to be made at whoever answers DNS for the domain.
The repair button, and when not to use it
Where the server manages the domain's DNS, there is a button that writes the correct records for you.
Use it when the server is genuinely the only thing sending mail for that domain. It is safe there and it saves typing a long DKIM record by hand.
Do not use it blindly when other services also send for the domain; a mailing platform, a CRM, an invoicing system. The repair writes an SPF record describing this server, and if it replaces one that also authorised those services, their mail starts failing.
Check the existing record first, and merge rather than replace. One SPF record per domain is the rule; two make both invalid. Understanding TXT Records deals with the syntax.
When DNS is elsewhere
The common case on a well-run setup, and it changes the workflow instead of the goal.
The screen shows you the exact records that should exist. Copy them to wherever your DNS actually lives, then come back and re-check. The tool re-queries rather than remembering.
DKIM records are long and a copying error produces a record that exists and does not validate, which is worse than a missing one because it looks configured. Paste rather than retype, and verify with a lookup afterwards.
Reverse DNS is not yours to set
The one item on this screen you cannot fix in DNS.
Reverse records belong to whoever holds the IP address: your provider, so a failure here is a request in place of an edit. On shared hosting you generally cannot have your own, and that is normal as long as the server's own hostname is set correctly.
What matters is consistency: the name the mail server announces, the reverse record, and the forward record for that name should agree. For asking for it, see Understanding PTR and Reverse DNS.
Check it after anything that touches DNS
This screen is a regression test, and it is cheap to run.
After a domain transfer, after moving DNS to another provider, after adding a mail service, or after a migration, open it and look. Those are exactly the moments SPF and DKIM quietly disappear, and the failure is gradual rather than immediate, so nothing else tells you. What to Check After Transferring a Domain sets out that case specifically.
As a reseller, checking it across accounts after a server move is worth the ten minutes. A client whose mail started landing in spam a month after a migration will not connect the two events.
What it does not tell you
It reports configuration, not outcomes.
A domain can pass every check and still have mail rejected, because the server's address is on a blocklist, because the content looks like spam, or because a compromised account is sending from the same machine. For that direction, see What to Do When Your IP or Domain Is Blocklisted.
It also says nothing about DMARC, which is the record that actually stops someone spoofing your domain. That is a separate decision and a staged rollout. How to Stop Your Domain Being Used for Spoofing has the detail.
Confirm it from the receiving end
The screen's own verdict is a good signal and not the final one.
Send a message to an address at a major provider, open it, and read the authentication results in the headers. SPF and DKIM passing there is what actually matters, because that is the check being applied to your real mail. There is more on reading the delivery report from your side in Email Routing and Track Delivery in cPanel.
When the records are right and mail still fails, the answer is in the mail server's own settings and its log. See Exim Configuration and Mail Routing in WHM.