DKIM Setup: Step-by-Step for Custom Domains | TrekMail

DKIM setup is not optional anymore if you want reliable delivery from a custom domain. If your key is missing, broken, truncated, or signed by the wrong domain, inbox placement gets worse fast. This guide gives you the operator workflow: generate the key, publish the DNS record, verify it from the command line, and catch the alignment mistakes that still break DMARC after the green checkmark shows up.

If you need the full domain baseline around MX, SPF, mailboxes, and client setup, start with create email with your domain. If you're choosing the platform first, business email covers the bigger decision.

The problem is simple. Most DKIM setup failures do not come from cryptography. They come from copy-paste DNS mistakes, panels that append the domain twice, 2048-bit keys getting mangled, or an ESP signing with its own domain instead of yours. You can lose hours chasing the wrong thing. The fix is a repeatable runbook.

What DKIM setup actually does

DKIM setup publishes a public key in DNS and lets your mail server sign each message with the matching private key. Receiving servers verify the signature, confirm the message was authorized by the signing domain, and detect whether key headers or body content were altered in transit.

DKIM uses asymmetric cryptography. Your sending system holds the private key. DNS publishes the public key. When a message leaves your server, it gets a DKIM-Signature header with a signing domain (d=) and selector (s=). The receiving server looks up that selector in DNS and validates the signature against the message content. That mechanism is defined in RFC 6376.

Since February 2024, Google tightened sender requirements for bulk senders. Google says bulk senders must set up both SPF and DKIM, and at least one of them must align with the domain in the visible From header for DMARC alignment to pass. Read the current wording in Google's sender guidelines FAQ.

That matters because a technically valid signature is not the same as a useful one. A broken or unaligned DKIM setup still leaves you with spam placement, DMARC trouble, or both.

DKIM setup before you touch DNS

Good DKIM setup starts by identifying who actually signs your mail. That sounds obvious. It is also where people blow up delivery during migrations, forwarding changes, or provider swaps. The right place to generate or obtain DKIM records depends entirely on your sending path.

Ask one question first: who sends outbound mail for this domain?

1. If Google Workspace sends it, generate the DKIM key in Google Admin.
2. If Microsoft 365 sends it, enable DKIM there.
3. If SendGrid, Mailgun, or Amazon SES sends it, authenticate the domain inside that provider.
4. If TrekMail Managed SMTP sends it, use the DKIM values shown in TrekMail.
5. If TrekMail is handling inboxes but you use external SMTP, follow your SMTP provider's signing instructions, then configure SMTP in TrekMail if needed.

TrekMail supports both paths. The Nano plan is BYO SMTP. Paid plans can use managed SMTP. TrekMail's docs for Bring Your Own SMTP show SES, SendGrid, and Mailgun examples. TrekMail's deliverability troubleshooting also notes that Managed SMTP signs mail with your domain's DKIM key, which helps DMARC survive forwarding and relays.

Example: your mailbox lives in TrekMail, but outbound mail goes through SendGrid. SendGrid must be the signer. TrekMail can store the mailbox, but it cannot magically make SendGrid's DKIM setup happen for you.

This is the first hard rule of DKIM setup: generate keys in the system that signs the message. If you generate them somewhere else, the record may exist in DNS and still do nothing.

DKIM setup record types: TXT vs CNAME

DKIM setup usually means publishing a TXT record that contains the public key. Some providers instead ask you to publish one or more CNAME records that point to keys they host. Both methods work. The important part is using exactly what your sender gives you.

Classic DKIM setup uses a TXT record at:

selector._domainkey.example.com

The value looks like this:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

Managed services often use CNAME-based DKIM setup because it lets them rotate keys without asking you to edit DNS again. TXT-based DKIM setup gives you direct control, but it also means you own the breakage if the key needs rotation and nobody updates it.

The trap is the host field. If your domain is example.com and the selector is k1, the host is usually:

k1._domainkey

Not this:

k1._domainkey.example.com

Many DNS panels append the root domain automatically. If you enter the full name in a panel like that, you end up publishing k1._domainkey.example.com.example.com. That record does not exist where receiving servers expect it.

If you want a TrekMail reference for the required DNS layer, use Required DNS Records. It also points out that some DNS providers want DKIM TXT values split into quoted parts.

DKIM setup step by step in DNS

The practical DKIM setup workflow is short: get the selector, publish the record, wait for DNS, verify the exact response, then enable signing if your provider requires a final toggle. Skip the verification step and you are guessing.

Use this runbook.

1. Open the sending provider and generate or reveal the DKIM record.
2. Copy the selector exactly. Do not rename it unless the provider supports that.
3. Create the DNS record at selector._domainkey.
4. Paste the full TXT value or CNAME target exactly as provided.
5. Set TTL to 3600 unless you have a reason to do something else.
6. Wait for propagation.
7. Verify with dig or nslookup before sending production mail.
8. Enable signing in the provider if the UI has a final activation switch.

Example TXT-based DKIM setup:

; DNS record
k1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Example CNAME-based DKIM setup:

; DNS record
s1._domainkey.example.com. 3600 IN CNAME s1.domainkey.u123456.wl.provider.net.

DNS propagation is usually quick, but not instant. TrekMail's DNS troubleshooting guide says most updates appear in about 5 to 15 minutes. If your status still will not turn green after that, the issue is usually formatting, duplicate records, or the wrong host name, not mystical DNS behavior.

DKIM setup and the 2048-bit key problem

Modern DKIM setup should use 2048-bit RSA keys when your provider and DNS host support them. They are stronger, but they are also longer, which creates problems in older DNS panels. A long key that gets cut off is worse than no key because it looks present while verification fails.

Google's current guidance still recommends 2048-bit keys when supported, with 1024-bit as a fallback for hosts that cannot handle longer records. The real-world problem is not DNS itself. It is the admin panel in front of DNS.

A broken 2048-bit DKIM setup usually looks like one of these:

1. The panel silently trims the value.
2. The panel requires quoted string chunks and does not tell you.
3. The panel inserts line breaks into the base64 key.
4. The panel escapes characters in a way the provider did not expect.

If your DNS host requires split strings, publish the value like this:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..."
"restOfTheKeyContinuesHereWithoutAddingSpacesInsideTheBase64Data"

The receiver concatenates the quoted parts. That is normal. What is not normal is adding spaces inside the actual key material. One extra character and the whole DKIM setup is dead.

If you are managing many domains, this is where the operational cost shows up. One registrar handles long TXT values fine. Another one does not. A third one rewrites them. That is why agencies eventually standardize on a smaller registrar set or move to provider-hosted CNAME signing where possible. If your work is multi-tenant, multi domain email hosting is the bigger operating model.

DKIM setup verification that actually proves it works

A dashboard saying “active” is not proof. Real DKIM setup verification means querying public DNS directly, checking the returned record, and then confirming live mail headers show the expected signing domain and selector. Anything less is a partial check.

Use the command line first.

# macOS / Linux
dig txt k1._domainkey.example.com +short

# Windows
nslookup -type=txt k1._domainkey.example.com

You want to see the full v=DKIM1 record or the quoted chunks that clearly combine into the full key. If the result is empty, check these in order:

1. The selector is correct.
2. The host field is not doubled.
3. The record type matches what the provider asked for.
4. The value is complete and not truncated.
5. The old record is not still cached.

Then send a test message to Gmail or another mailbox where you can inspect headers. Look for the authentication results and the DKIM signature line.

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=k1; ...
Authentication-Results: ... dkim=pass header.d=example.com ...

If DNS looks fine but inbox placement still stinks, go one layer higher. TrekMail's emails go to spam guide is blunt about it: DNS must be green, domain warm-up matters, list quality matters, and content still matters. DKIM setup fixes authentication. It does not buy you reputation.

Also note the forwarding edge case. SPF often breaks when messages are forwarded. DKIM is what keeps DMARC passing in many of those flows. If forwarding is part of your setup, read email forwarding so you do not mistake a forwarding SPF fail for a full authentication failure.

DKIM setup and the alignment trap

Alignment is where many “working” DKIM setup projects fall apart. The signature can validate and still fail DMARC if the signing domain does not align with the From domain users actually see. This is a DNS problem only part of the time. Usually it is a provider configuration problem.

Here is the common failure:

From: ceo@example.com
DKIM signer: d=sendgrid.net
Result: DKIM can pass, but DMARC alignment can still fail because the signer domain does not align with example.com.

Google's sender guidance is clear here: for bulk senders, the visible From domain must align with either SPF or DKIM at the organizational domain level. So if your ESP signs with its own domain, your DKIM setup is technically alive but strategically wrong.

The fix is usually called domain authentication, white-labeling, or custom return-path setup depending on the provider. You want the final signature to look like this:

DKIM-Signature: ... d=example.com; s=s1; ...

That is the version of DKIM setup that helps DMARC and inboxing. Anything else is half-finished.

Old way vs new way for DKIM setup

The old way to handle DKIM setup is manual and brittle: every domain, every provider, every selector, every DNS quirk handled by hand. The new way is standardization. You pick a repeatable sending model, centralize DNS checks, and stop rebuilding the same fix for every domain.

TrekMail fits that newer model. You can run multiple custom domains from one dashboard, use pooled storage instead of paying per mailbox, migrate existing inboxes over IMAP, and choose between BYO SMTP or included SMTP depending on the plan. Paid plans start at $3.50/mo, and the platform is built for teams, SMBs, agencies, and MSPs that do not want to babysit email infrastructure all week.

If the bigger problem is process rather than DNS, read client email management. Most deliverability issues in multi-domain environments are ownership issues first, record issues second.

Final DKIM setup checklist

A solid DKIM setup uses the right signing system, the right DNS host name, the full unbroken key, public DNS verification, and aligned signing for DMARC. If any one of those pieces is wrong, the whole chain gets weaker fast.

1. Confirm which system signs outbound mail.
2. Publish the provider's exact selector and record type.
3. Use selector._domainkey in the host field unless your DNS host explicitly needs the full name.
4. Keep 2048-bit keys intact. Split quoted strings only if your DNS panel requires it.
5. Verify with dig or nslookup.
6. Send a test and inspect headers for dkim=pass and aligned header.d.
7. Check DMARC results after go-live.

That is the whole game. Good DKIM setup is not complicated. It is precise. If you want fewer moving parts, standardize your domains and sending path inside TrekMail, keep DNS visible in one place, and stop doing email the expensive old way.