If your helpdesk sends from support@yourcompany.com but the underlying mail is signed by a vendor domain like mail.helpdesktool.com, DMARC fails alignment and a meaningful share of your replies land in spam. DKIM CNAME delegation fixes this in an afternoon: you add 2-3 CNAME records pointing to your helpdesk vendor, they manage the signing keys, and outbound mail signs d=yourcompany.com so DMARC passes cleanly.

Key takeaways

• DKIM CNAME delegation lets your helpdesk vendor manage signing keys while outbound mail still signs as your own domain — required for DMARC alignment.
• A misaligned DKIM signature (signed d=vendor.com instead of d=yourdomain.com) is the #1 reason helpdesk replies hit spam on B2B SaaS support teams.
• The full setup is 6 steps: pick a sending domain, get CNAME targets from your vendor, add DNS records, verify, set DMARC to p=quarantine, then monitor.
• CNAME records beat raw TXT records here because vendors can rotate keys without you touching DNS again.
• If your helpdesk doesn't support CNAME-delegated DKIM aligned to your domain, that's a deliverability bug — not a configuration limit.

Why misaligned DKIM is killing your reply deliverability

When Gmail or Microsoft 365 receives an email from support@yourcompany.com, they check three things: SPF, DKIM, and DMARC. DMARC is the strict one — it requires that either the SPF return-path domain or the DKIM d= domain matches the visible From: domain. This is called alignment.

Most helpdesks send through their own infrastructure by default. So even though the From: header says support@yourcompany.com, the DKIM signature is d=mail.vendor.com and the SPF return-path is something like bounces+abc@vendor.com. Neither aligns. DMARC fails. Your reply gets quarantined or junked.

If you've published a DMARC policy of p=quarantine or p=reject (which you should, for anti-spoofing), this is fatal. If you haven't, Gmail's adaptive spam filtering still penalizes unaligned senders, especially on B2B inboxes.

DKIM CNAME vs TXT records: why delegation wins

You have two ways to publish DKIM keys for your domain:

For a helpdesk, CNAME delegation is the right answer for two reasons:

1. Key rotation. Vendors rotate DKIM keys every 6-12 months as a security practice. With a TXT record you'd have to update DNS each time. With CNAME, the vendor updates the target and you do nothing.
2. No private key handling. You never see the signing key, so it can't leak from your side.

The trade-off: you trust the vendor's infrastructure. For any reputable helpdesk that's a fair trade.

The 6-step DKIM CNAME setup for your helpdesk

This is the workflow that gets a 5-15 agent support team from "replies landing in spam" to "DMARC-aligned and deliverable" in roughly two hours.

Step 1 — Decide the sending domain

Pick the domain you want outbound replies to sign as. Options:

• Your root domain (yourcompany.com) — replies look most legitimate, but you may already have an existing mail setup here.
• A support subdomain (support.yourcompany.com) — cleaner separation, easier to manage, and you can isolate reputation. This is what we recommend for SaaS teams.
• A reply subdomain (reply.yourcompany.com) — works but looks more transactional than human.

For a 10-agent B2B SaaS team, support.yourcompany.com strikes the right balance.

Step 2 — Get CNAME targets from your helpdesk

In your helpdesk's email settings, enter the sending domain you chose. It should generate 2-3 CNAME records — typically:

helptal1._domainkey.support.yourcompany.com  →  helptal1._domainkey.<vendor>.com
helptal2._domainkey.support.yourcompany.com  →  helptal2._domainkey.<vendor>.com

The two-key setup is intentional. Vendors rotate between them so they can change signing keys without a publishing gap.

Step 3 — Add the CNAMEs to DNS

Go to your DNS provider (Cloudflare, Route 53, NS1, GoDaddy, whatever). Add each CNAME record exactly as provided. Two things teams get wrong here:

• Don't add the root domain. If your vendor gives you helptal1._domainkey.support.yourcompany.com, the host/name field should be helptal1._domainkey.support (because the provider appends yourcompany.com). Check your provider's UI — some auto-append, some don't.
• Disable proxying on Cloudflare. If you use Cloudflare, set the orange cloud to grey (DNS-only) for these records. Proxied CNAMEs break DKIM resolution.

Step 4 — Verify in your helpdesk

Most helpdesks have a "Verify" button that polls DNS until the CNAMEs resolve and the keys are found. DNS propagation takes anywhere from 5 minutes to a few hours; usually under 15 minutes on modern providers.

Once verified, your helpdesk will start signing outbound mail as d=support.yourcompany.com (or whatever sending domain you chose). Check by sending a test reply to a Gmail address and viewing "Original Message" — you should see dkim=pass and d=support.yourcompany.com.

Step 5 — Configure DMARC for alignment

Now that DKIM is aligned, publish (or update) your DMARC record. At the root domain:

_dmarc.yourcompany.com  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourcompany.com; adkim=r; aspf=r"

The adkim=r (relaxed alignment) is what lets support.yourcompany.com align with yourcompany.com in the visible From header. Strict alignment (adkim=s) would require an exact match.

Start with p=quarantine, monitor reports for 2-4 weeks, then move to p=reject once you're confident nothing legitimate is failing.

Step 6 — Monitor and lock it in

Forward the DMARC rua reports into a DMARC analyzer (Postmark's free one is fine, or any of the dedicated tools). You're looking for:

• Your helpdesk traffic passing DKIM alignment.
• Any other systems sending as your domain (marketing platform, billing tool, transactional ESP) and whether they're aligned too.
• Unknown senders, which indicate either forgotten tools or spoofing attempts.

Deliverability lift usually shows up within a week — Gmail reputation in particular adjusts fast for aligned senders.

Common mistakes that quietly break this

• Adding the CNAME to the wrong subdomain. If you configured the helpdesk to send from support.yourcompany.com but added the CNAMEs at yourcompany.com, DKIM lookup fails silently.
• Forgetting SPF. DKIM alignment satisfies DMARC, but Gmail still wants SPF to pass some domain. Add the vendor's include: to your SPF record at the sending domain.
• Mixing transactional and support mail on the same subdomain. If you also send marketing or product email from support.yourcompany.com, you'll cross-contaminate reputation. Keep them separate.
• Setting p=reject on day one. You'll bounce legitimate mail from systems you forgot about. Stage to p=quarantine first.

How Helptal fits in

Helptal ships CNAME-delegated DKIM as part of standard support ticket setup — the email settings page generates the CNAME targets for your sending domain, tracks verification state (pending / verified / failed), and surfaces a UI badge when keys rotate. Outbound mail signs d=yoursupportdomain.com so DMARC aligns cleanly without you running your own SMTP. The whitelabel email footer on Growth and Business plans is the other half: branded From: name, your domain, your signature, no vendor noise in the headers.

Frequently asked questions

What is DKIM CNAME delegation?

DKIM CNAME delegation is a DNS setup where you publish CNAME records on your domain that point to DKIM keys hosted by your email vendor. The vendor manages the signing keys and rotation while outbound mail still signs as your domain. This satisfies DMARC alignment without you running your own mail infrastructure or handling private keys.

Why are my helpdesk replies going to spam?

The most common cause is DKIM misalignment: your helpdesk signs outbound mail with its own domain (d=vendor.com) instead of yours, so DMARC fails alignment. Gmail and Microsoft 365 penalize unaligned senders even without a strict DMARC policy. Setting up CNAME-delegated DKIM on your sending domain typically resolves this within a week.

Should I use CNAME or TXT records for DKIM?

Use CNAME records when sending through a SaaS helpdesk or ESP — the vendor manages the keys and can rotate them without DNS changes from you. Use TXT records only when you run your own SMTP infrastructure and control the signing keys yourself. CNAME delegation is the modern default for support email.

How long does DKIM CNAME setup take?

The DNS configuration takes about 30 minutes; DNS propagation usually completes within 15 minutes on modern providers but can take up to a few hours. Add another hour for testing and DMARC configuration. Plan for a single afternoon end-to-end, then 2-4 weeks of DMARC monitoring before moving to a strict policy.

What's the difference between adkim=r and adkim=s in DMARC?

adkim=r (relaxed) lets a DKIM signature on a subdomain like support.yourcompany.com align with a From header at yourcompany.com. adkim=s (strict) requires an exact match. Relaxed is the right choice for helpdesks because you're usually sending from a subdomain but want alignment with the root domain.

This week, audit one thing: send a test reply from your helpdesk to a Gmail address, open "Show original," and check whether the DKIM signature's d= value matches your visible From domain. If it doesn't, you've found your deliverability problem — and the 6-step fix above ships in an afternoon. If you're evaluating helpdesks and want CNAME-delegated DKIM built into setup rather than bolted on, Helptal's free plan includes sender domain verification on day one.