Adding DKIM signing to your domain

To add DKIM, you enable signing on the system that sends your mail, then publish the public key in DNS at selector._domainkey.yourdomain as a TXT record. Receivers fetch that key and verify each message’s DKIM signature. On Hostworld shared or reseller hosting, you do this in cPanel’s Email Deliverability and it will generate the record for you.

This picks up from a domain you already send email from and for which you can edit DNS. If you are hosting your website or mail with Hostworld, you can reach cPanel for the domain.

Before you start

• Decide where your mail is sent from. DKIM is configured on the actual sender. That might be your Hostworld cPanel account, Google Workspace, Microsoft 365, or a self-managed VPS running your own MTA.
• Have DNS access. You will publish a TXT record at selector._domainkey.yourdomain. The record must be a single TXT RR for that selector. Long values can be split inside that one record into quoted chunks that DNS concatenates. Creating two separate TXT records at the same selector is undefined.
• Pick a strong algorithm. Sign with rsa-sha256. rsa-sha1 must not be used. Use at least a 1024-bit RSA key. 2048-bit is recommended. ed25519-sha256 is also defined and widely implemented. If you use ed25519, the DNS record uses k=ed25519 and a shorter p= value that typically fits in one string.
• Understand policy. Gmail and Yahoo now expect authentication. Bulk senders must use SPF or DKIM and publish DMARC. DKIM has become practically mandatory if you send at any scale.
• Know the risks. Rotating a DKIM key on your mail server before the new public key is live in DNS will cause DKIM failures. Deleting a key or publishing an empty p= in DNS revokes it and also causes failures. Mis-splitting a 2048-bit key or publishing more than one TXT RR at a selector produces permerrors at receivers.
• Do not expose your private key. cPanel warns that revealing the private DKIM key is a security risk. If a private key leaks, anyone can sign as your domain until you revoke and rotate.

Step 1: Decide who will sign your domain’s mail

DKIM is applied by the system that sends your mail. Choose one of the following and stick to the provider’s method:

• Hostworld shared, reseller or WordPress hosting: use cPanel’s Email Deliverability. It generates a key and shows the exact DNS record.
• Google Workspace: use the Admin console. It gives you a TXT record to publish, then you start authentication.
• Microsoft 365: Microsoft uses CNAMEs for delegation. You publish two CNAMEs, one per selector, then enable DKIM in the Microsoft portal.
• Your own VPS or dedicated server: configure a DKIM milter such as OpenDKIM with Postfix or your chosen MTA, generate a key pair, and publish the TXT record yourself.

If you want Hostworld to host your DNS so cPanel can write records for you, change the domain’s nameservers at your registrar to our nameservers: ns1.serverworld.uk, ns2.serverworld.uk, ns3.serverworld.uk, ns4.serverworld.uk. Using any other hostname here will take your site and mail offline.

Step 2: Choose a selector and algorithm

The selector is a label that identifies a key. With d=example.com and s=foo, receivers query foo._domainkey.example.com for your public key. You can run multiple selectors over time to rotate keys cleanly.

• On cPanel and many SaaS mail platforms, a default selector is created for you. Use what the platform provides unless you have a reason to change it.
• On Google Workspace the default selector is “google”.
• On Microsoft 365 you will use two selectors, which Microsoft’s documentation calls selector1 and selector2. Two CNAMEs are published so that keys can be rotated.
• For self-managed signing you pick the selector name when you generate the key and configure the milter.

Algorithm and key size:

• RSA with sha256: signers must support rsa-sha256. RSA keys must be at least 1024 bits. 2048-bit is recommended.
• Ed25519 with sha256: supported by the standard. If you use it, publish k=ed25519 in DNS. The p= value is 44 base64 octets so it usually fits in one TXT string.

Step 3: Enable DKIM in Hostworld cPanel

This route is for Hostworld shared, reseller and WordPress hosting, and it is the one we would use ourselves. In cPanel, the Email Deliverability interface generates the key pair on our server, keeps the private half there, checks DKIM, SPF and PTR status for the domain, and shows you the public record that has to exist in DNS. The private key stays on the server: do not view or copy it, because cPanel is right that exposing it lets anyone sign as your domain.

In short: open Email Deliverability in cPanel, generate the local DKIM key for the domain, and then get the suggested TXT record into DNS. If the domain uses our nameservers, cPanel can write that record into the zone itself and the status should then show as valid. If the DNS is hosted elsewhere, copy the suggested record’s name and value across by hand. cPanel offers the value in a full view and a split view, the split view breaking it into safe 255-character chunks that belong inside one TXT record, so use whichever your other DNS interface will accept. Then let caches expire and test as in Step 4.

For the click-by-click version with the screens in order, see how to enable DKIM in cPanel. If a record will not validate, or you would rather we looked at the domain and the server configuration, open a support ticket.

Step 4: Verify that signing works and fix common DNS mistakes

Once you have published the record:

1. Send a test email to a Gmail address. In Gmail, open the message menu and choose Show original. Look for Authentication-Results and check that dkim=pass for your domain. Google’s own guidance uses this method for verification.
2. Check the exact host name you entered in DNS. Many DNS UIs auto-append the zone. If you paste a fully qualified name, you might end up with a double domain such as selector._domainkey.example.com.example.com. That will never be found by receivers. Use the name format your DNS host expects.
3. Check the record type and value shape. DKIM keys are published via TXT at the selector host name, unless your provider explicitly uses delegation. The TXT must have one RR at that name. Within that one RR, long p= values can be split into multiple quoted strings that DNS concatenates with no whitespace. Do not create multiple TXT records at the same selector.
4. Do not proxy CNAMEs through a CDN. If you are using Microsoft 365’s CNAME method, ensure records are not orange-cloud proxied in Cloudflare and that you used CNAME, not TXT.

Step 5: Add DKIM for Google Workspace

If you use Google Workspace for mail, follow Google’s process:

1. In the Admin console, generate a DKIM key. Google recommends 2048-bit keys and uses the “google” selector by default. The key generation option is not available straight away on a new domain: allow 24 to 72 hours after Gmail is switched on for the domain before you expect to see it.
2. Publish the TXT record at the host name Google provides. This will be selector._domainkey.yourdomain. Paste the exact value Google gives you, as a single TXT RR at that name. If the DNS interface you are using will not accept the whole value in one field, check what that interface allows for long TXT values rather than creating a second TXT record at the same name.
3. Click Start authentication in the Admin console.
4. Send a test message and verify. In Gmail, use Show original on the received message and check DKIM=pass for your domain.

If you want Hostworld to host the DNS for your Google-hosted mail, switch the domain to our nameservers first: ns1.serverworld.uk, ns2.serverworld.uk, ns3.serverworld.uk, ns4.serverworld.uk, then add the TXT record in that DNS zone as Google instructs.

Step 6: Add DKIM for Microsoft 365

Microsoft 365 uses CNAME delegation rather than a direct TXT key:

1. Publish two CNAME records at your DNS host. One for selector1 and one for selector2 at the _domainkey host names. Point them to the exact Microsoft targets specified in Microsoft’s documentation for your tenant and domain.
2. Enable DKIM in the Microsoft 365 portal. Use the controls to activate signing for your domain.
3. Check for common errors. Do not publish TXT records where CNAMEs are required. Do not enter the full domain if the DNS host auto-appends it, which causes double-domain host names. Avoid very low TTLs and do not proxy these CNAMEs through Cloudflare.

After enabling, send a test mail and verify that DKIM=pass in the recipient’s Authentication-Results.

Step 7: Configure DKIM on a self-managed VPS with OpenDKIM

If you run your own MTA, you add a signing milter and publish the key in DNS. OpenDKIM supports different configuration models. Use one complete model. Mixing models can cause signing with an unexpected key.

• Selector and domain mapping. Use either the simple Domain/KeyFile/Selector directives or the KeyTable and SigningTable model. Do not combine them unless the documentation says to.

Example using KeyTable and SigningTable:

# /etc/opendkim/KeyTable
mail2026._domainkey.example.com example.com:mail2026:/etc/opendkim/keys/example.com/mail2026.private

# /etc/opendkim/SigningTable
*@example.com mail2026._domainkey.example.com

In this example the selector is mail2026. The DNS will be published at mail2026._domainkey.example.com as a TXT record containing the public key.

OpenDKIM runs as a milter in your MTA’s pipeline. If the milter is misconfigured or unavailable, Postfix can reject or defer mail at end of message. Make changes carefully and monitor logs after reloads. Test on a staging domain first if you can.

Publish the DNS record at the selector host name. A correct 2048-bit RSA key often needs to be split into multiple quoted strings within a single TXT RR. Receivers concatenate these with no whitespace. For example:

Name: mail2026._domainkey.example.com
Type: TXT
Value:
"v=DKIM1; k=rsa; "
"p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArEXAMPLEKEYPARTONE"
"EXAMPLEKEYPARTTWOEXAMPLEKEYPARTTHREEEXAMPLEKEYPARTFOUR...="

For ed25519, use k=ed25519 and the shorter 44-octet p= value, which typically fits in one string.

Step 8: Rotate and revoke DKIM keys safely

Keys age. Plan rotation so you do not break mail:

1. Add a new selector first. Generate a new key pair and publish the new public key at newselector._domainkey.yourdomain.
2. Switch the signer to use the new selector. Update cPanel, your SaaS provider, or OpenDKIM to sign with the new selector.
3. Leave the old selector in DNS for a while. Receivers need it to verify messages already sent.
4. Revoke the old key when safe. Remove the TXT record or publish an empty p= at the old selector to revoke it. An empty p= or missing key will cause receivers to return a permanent failure for that selector.

Do not switch the signer before the new DNS is live. With strict DMARC at large receivers, signing with a key that does not exist in DNS can trigger rejections until you correct DNS.

Step 9: Expect DKIM to break on some mailing lists

Intermediaries such as mailing lists often modify messages by adding footers or rewriting parts of the body or headers. These changes can and do break DKIM verification. This is documented in RFC 6377. If you send through a list and see dkim=fail on the final recipient, it may not be something you can fix. Verify that your original outbound messages pass DKIM at a direct recipient, and rely on other signals such as SPF and DMARC alignment where appropriate.

What next

Next, publish SPF and DMARC for the same domain so receivers have a complete picture of your sending. If you are moving more of your workload onto your own server, see our VPS guides. Our UK VPS machines run from our own data centre in Maidenhead, Berkshire, with New York available for US hosting, and they will run OpenDKIM on AlmaLinux, Ubuntu or Debian.

If at any point you want us to check a record or the server configuration, please open a support ticket.