Engineering Glossary · Deliverability
DKIM: Publish the Selector, Then Read the Result
A DKIM record that looks present in the panel but returns nothing from dig is the single most common reason mail is quietly downgraded.
The short answer
DKIM attaches a cryptographic signature to outgoing mail, computed over selected headers and the body with a private key held by the signing server, and verified against a public key published in DNS under a named selector.
Two failure states are worth being able to tell apart. dkim=none means no key was found, and that is a DNS problem — usually the selector is wrong or the record was never published. dkim=fail with a body-hash mismatch means the key was found but the message changed after signing, which points at a mailing list appending a footer or a gateway rewriting links. Both look identical from your side; only the receiving header distinguishes them.
By the HostingFast team · Reviewed 12 August 2026
0
Jargon left undefined
100+
Entries, all cross-linked
Real
Working examples
Free
To read, always
Your mail server signs each message with a private key, and the matching public key sits in DNS under a selector for receivers to fetch and verify against. Unlike SPF, the signature rides inside the message, which means it survives being forwarded.
Every service sending on your behalf signs under its own selector, so multiple keys coexist without conflict. Hosting mail, your newsletter tool and your CRM can each be verified independently, and each publishes its own record.
Confirm the key is actually published
dig +short TXT selector._domainkey.yourdomain.com is the only check that counts. If it returns nothing, everything downstream is irrelevant, and no amount of resending will change the outcome. The selector is not a guess: the panel that generated the key names it, and so does every external platform that asks you to publish one.
Two things commonly go wrong at this step. A long key gets published split across quoted strings and one of them is dropped, leaving a record that exists but does not parse. Or the record is created at the wrong level, giving selector._domainkey.yourdomain.com.yourdomain.com — the classic result of pasting a fully qualified name into a panel that appends the domain for you. dig catches both in a second.
Read the verdict at the receiving end
Send to a mailbox you control, open the raw source, and find the Authentication-Results header. It will state dkim=pass with header.d= naming the signing domain, or it will state why it did not. That header is the ground truth, and it is produced by the receiver rather than by anything you control, which is precisely what makes it worth reading.
A bh= mismatch specifically means the body hash did not match the signature. Nothing was wrong with your key; something modified the message between signing and delivery. Mailing lists that append a footer, security gateways that rewrite URLs, and marketing tools that inject tracking are the usual suspects, and the fix is either to exclude that path or to accept that DMARC will have to pass on SPF alignment instead.
Why forwarding survives DKIM and destroys SPF
SPF is evaluated against the IP address that connected to the receiver. Once a forwarder relays your message, that address belongs to the forwarder, so the check runs against a server that was never in your record and fails. There is no configuration that avoids this, because the check is doing exactly what it was designed to do.
DKIM signs inside the message, so relaying it changes nothing the verifier looks at. That is why the pair is not redundant: one authenticates the transport, the other authenticates the artefact, and DMARC passes provided either aligns with the visible From domain. Systems that publish only SPF are the ones that break the moment somebody sets up a redirect.
Where this lands on HostingFast
Key generation and the matching DNS record are handled from the control panel, and full record editing is available there too for the external platforms that hand you a key of their own. Backups run daily on every plan, and restoring a file or a database is a single click in the panel, not a support ticket.
Read next: SPF for the transport-side check, DMARC for the policy that binds them to the From header, and TXT Record for the container both live in.
A hundred terms, each with the mechanism
To us, jargon nobody explained is a service defect. This glossary is the support team's collected translations — published with the dig commands, the header names and the failure codes still in them.
Backups run daily on every plan, and restoring a file or a database is a single click in the panel, not a support ticket.
- 100+ entries, each with the mechanism spelled out
- Commands you can paste, numbers you can compare against
- Neighbouring terms wired together at the foot of every page
- Written by the engineers who answer the tickets
Why HostingFast
Standard on every plan
Failure codes told apart
none, fail and a body-hash mismatch mean three different things, and the entry says which repair each one calls for.
Read before write
Every DNS entry opens with the dig command that shows what is actually live, because panels can lie by omission.
Headers as evidence
Authentication-Results is produced by the receiver, not by you, which is exactly why it settles arguments.
Mechanism, not vocabulary
What is signed, what is hashed and what survives a relay — the detail that explains every symptom.
Wired to its neighbours
DKIM runs into SPF, DMARC and TXT Record, because none of the three is a complete answer alone.
This term, landed
DKIM defined, verified from the shell and confirmed at a receiver — enough to sign an audit off properly.
Quick Start
From order to online
- 1
Query the selector directly
dig +short TXT selector._domainkey.yourdomain.com. An empty answer is the whole diagnosis, and no resend will change it.
- 2
Check for a doubled or split record
Look for the domain appended twice, and for a long key broken across quoted strings with a piece missing. Both produce a record that exists and does not work.
- 3
Confirm at a real receiver
Send to a mailbox you control, open the source, and read dkim= in Authentication-Results. pass is proof; anything else names the next thing to fix.
Built In
Loaded onto every plan
- cPanel's DNS Zone Editor, not a fixed set of preset records
- Mailboxes on your own domain, included with the plan
- Real SSH, plus Git and Composer, on the developer-focused plans
- cPanel, so key generation and DNS sit on screens you already know
- Staging environments, so a change gets measured before it ships
- Daily backups with self-service restores you run yourself from the panel
- Human support on duty every hour of every day
- Zero setup charges — there is no joining fee, ever
- A renewal price identical to the one you signed up at
- DDoS filtering absorbed out at the network edge
Frequently Asked
What people ask us most often
How do I confirm a DKIM key is published correctly?
dig +short TXT selector._domainkey.yourdomain.com, using the selector the signing system names rather than one you assume. An empty response means it was never published or the name is wrong. Watch for two specific mistakes: the domain appended twice because a panel adds it for you, and a long key split across quoted strings with one piece dropped.
What does a bh= mismatch actually mean?
That the body hash computed at the receiver did not match the one in the signature — so the message was modified after signing. Your key is fine. Look for a mailing list appending a footer, a security gateway rewriting URLs, or a marketing tool injecting tracking parameters. Either take that path out of the flow, or accept that DMARC will need to pass on SPF alignment for those messages.
Can several platforms sign for the same domain at once?
Yes, and they should. Each signing service uses its own selector, so hosting mail, a newsletter platform and a CRM can each publish a key at a different selector._domainkey name without colliding. That is the design: one domain, many independently verifiable signers, no shared secret between them.
Will you move an existing site across for us?
Yes, free of charge. Open a ticket with your current host's login details and we bring everything over — files, databases, mailboxes, configuration. You review the copy before DNS moves, and the old site keeps taking traffic right up until the new one is serving it, so there is no window where visitors hit a gap.
Keep reading
SPF (Sender Policy Framework)
The transport-side check that a forwarding hop invalidates, and the lookup ceiling that breaks it.
DMARC
The policy layer that decides what a passing signature is worth, and reports on who is sending as you.
How to Set Up DKIM Signing
Generating a key, publishing the record and proving it verified at the far end.
Plesk Reseller Hosting
Plesk-based reseller accounts for teams that work best in Plesk.
Plesk Hosting
Shared hosting on Plesk for anyone who would rather skip cPanel.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Sign it, publish it, prove it.
Full DNS control in the panel, mailboxes included with the plan, and engineers who will read the header with you.
View Plesk Reseller Hosting plans