[ Sending-service guides ]

Authenticate email sent through Zendesk: configuration and verification

Configure the documented Zendesk sending route, preserve other mail services, and verify the delivered identities before accepting the change.

By the EmailAuth research team · 5 min read

[ Key points ]

  • Configure the documented Zendesk sending route, preserve other mail services, and verify the delivered identities before accepting the change.
  • Publish both CNAMEs before enabling custom-domain signing.
On this page
  1. Scope and prerequisites
  2. Configure the documented route
  3. Product-specific risks
  4. Prove the route at the receiving end
  5. Diagnose failures without widening access
  6. Handover and recovery
  7. Confirm the provider boundary
  8. Work through a fictional diagnostic case
  9. Separate a passing message from enforcement readiness

Scope and prerequisites

Use this guide for Zendesk Support sending from an external custom-domain support address. Add that address to Zendesk before configuring domain authorization. Addresses on public mailbox domains cannot use customer-controlled DNS, and a Gmail connector route needs separate verification. Incoming forwarding to a support address is not proof that outbound authentication is configured.

Configure the documented route

  • Step 1. Inventory every external domain used by the support addresses. Save the current SPF policy and selector records before changing them.
  • Step 2. Add include:mail.zendesk.com to the domain's single SPF TXT policy while preserving other authorized senders. Zendesk's example for its service alone is v=spf1 include:mail.zendesk.com -all. Its current instructions require the include in the first lookup layer; validate the resulting policy rather than nesting it invisibly inside another include.
  • Step 3. Publish two CNAMEs for each external domain: zendesk1._domainkey pointing to zendesk1._domainkey.zendesk.com, and zendesk2._domainkey pointing to zendesk2._domainkey.zendesk.com. Host labels are relative to the external domain unless your DNS console needs the complete name.
  • Step 4. Confirm both CNAME answers are available at authoritative DNS and through the resolvers used for verification. Keep both records; Zendesk's documented method accommodates its key rotation without manual key replacement.
  • Step 5. Only after DNS is ready, open Admin Center, Channels, Talk and email, Email. Under Email settings enable Custom domain for DKIM and save. Zendesk warns that enabling the option before the CNAMEs exist can cause delivery failures.
  • Step 6. Generate an ordinary ticket response from each relevant support identity. Save the raw delivered message and inspect the receiver's authentication results, not just the agent interface warning.

Product-specific risks

The highest-risk ordering mistake is switching on custom-domain signing before publishing both CNAMEs. If that has happened, repair the records and assess the queued mail with the support owner. Avoid a domain-wide DMARC relaxation as a workaround for one route. SPF validation can also fail when another include in the same policy is invalid; adding Zendesk again does not fix that. Do not authorize third-party systems to send from a Zendesk-owned subdomain.

Prove the route at the receiving end

Use an approved external mailbox and save the complete raw message with its timestamp and message identifier. No live tenant test is claimed in this guide. The following is an acceptance worksheet to complete during implementation, not a record of observed results.

  • Evidence field: Visible From; What to record: Actual address and domain; Acceptance question: Is this the intended sender identity?
  • Evidence field: Envelope; What to record: Return-Path and receiver-reported SPF domain; Acceptance question: Which domain did SPF actually authenticate?
  • Evidence field: SPF; What to record: Trusted receiver result and evaluated identity; Acceptance question: Did it pass, and does that identity align?
  • Evidence field: DKIM; What to record: Every d= domain, s= selector and receiver result; Acceptance question: Does at least one passing signature align?
  • Evidence field: DMARC; What to record: Receiver result and applicable policy; Acceptance question: Does an aligned passing path exist?
  • Evidence field: Route; What to record: Product, account and message type; Acceptance question: Did the test use the production path?

DMARC needs at least one aligned, passing SPF or DKIM path. A passing signature from an unrelated service domain is not enough. Strict alignment requires exact domain equality; relaxed alignment uses the applicable organizational-domain relationship. Check the domain's actual alignment settings before declaring success. A subdomain is not an automatic strict match. SPF uses the SMTP identity, not the display name or Reply-To. Consult the alignment glossary when recording the decision.

Use Authentication-Results from the receiving system you trust, not a header supplied by an arbitrary sender. Capture all signatures rather than stopping at the first failure. For forwarded mail, compare a direct test with a forwarded copy: forwarding may change SPF evaluation or alter signed content. Do not diagnose those effects by adding the forwarder's address to your provider authorization.

Diagnose failures without widening access

Compare authoritative DNS with the exact configured record names first, then check recursive visibility and service validation. A wrong name, truncated key or conflicting CNAME is not fixed by waiting for caches. Keep only one SPF policy at an owner and check the ten DNS-lookup-term limit across evaluated includes and redirects before merging another sender. DKIM selectors belong to individual signing configurations; do not overwrite another application's record to force a validation result.

If authentication passes but delivery is poor, inspect the recipient response, reputation, content and sending permissions separately. DMARC pass does not promise acceptance or inbox placement. If neither path aligns, stop expansion and correct the actual sender configuration. Do not weaken the whole domain's DMARC policy to hide a single product failure.

Handover and recovery

Save the approved DNS diff, public lookup results, service status and redacted received-message worksheet with a named owner. Keep credentials and private keys out of tickets. On failure, pause the affected sending job or use a previously tested route under the service owner's control. Restore only the changed records that belong to this integration; keep public keys needed by in-flight messages. Retest after rollback, key rotation, domain migration or a change in outbound relay. Close the change only when the product owner and mail administrator can explain the observed identity chain.

Confirm the provider boundary

The SPF page identifies include:smtp.zendesk.com and include:support.zendesk.com as older alternatives. Review any migration with the DNS owner rather than keeping duplicate authorizations indefinitely. The Gmail connector has its own SPF recommendation; do not silently treat it as the same external-domain ticket route. The stated quarterly key rotation depends on retaining both managed CNAMEs.

Work through a fictional diagnostic case

Fictional written case only: ZD-01 assumes a ticket reply uses From help@studio.example with a failing d=studio.example signature at selector zendesk1, and authoritative DNS lacks that CNAME. SPF and other signatures are unknown; full DMARC failure is not established. The support owner must halt expansion, restore the documented DNS prerequisite and retest the ticket route rather than loosening the whole domain policy. A working incoming forward is not contrary evidence. No tenant, DNS, server command or message was exercised for this case.

Separate a passing message from enforcement readiness

RFC 9989 Section 7.4 requires valid DKIM for a domain publishing p=reject and cautions about indirect-mail interoperability. A single aligned SPF result does not by itself justify a reject-policy rollout. Review all legitimate routes and policy ownership separately from this provider setup.

[ Takeaway ]

Publish both CNAMEs before enabling custom-domain signing.

[ By role ]

What this means for you

Choose your role for practical next steps.

IT / Mail Admin

Verify identities, not green badges

For Zendesk, keep product activation, DNS visibility and receiver results as separate evidence.

Next steps

  1. Capture current authoritative records before editing.
  2. Test each distinct sender and delivery route.
  3. Retain the public evidence and a narrow rollback plan.

CISO / SecOps

Limit delegated sending authority

The Zendesk integration should have a documented domain scope and accountable owner.

Next steps

  1. Review selector and envelope ownership before delegation.
  2. Exclude credentials and private keys from handover material.
  3. Require revalidation after channel or domain changes.

Founder / Non-technical

Protect the message that matters

Assign business ownership to the Zendesk route rather than treating DNS validation as project completion.

Next steps

  1. Name the critical message type and its sender.
  2. Approve a small representative test before broader sending.
  3. Keep an operational fallback and owner for failures.

[ FAQs ]

Frequently asked questions

Which Zendesk SPF include is current?

The cited setup guide uses include:mail.zendesk.com and calls for it in the first lookup layer. Preserve the rest of the valid single SPF policy.

Do I need both zendesk1 and zendesk2 CNAMEs?

Yes. Publish both records in the documented DKIM procedure so the provider-managed key arrangement remains intact.

When should Custom domain for DKIM be enabled?

After DNS has been updated and checked. Zendesk explicitly warns that enabling it first can cause delivery failures.

Does forwarding incoming mail prove outbound signing works?

No. Forwarding and outbound DKIM are separate steps. Test a ticket notification sent by the intended Zendesk route.

What proves Zendesk mail passes DMARC?

A representative received message must have at least one passing SPF or DKIM identifier aligned with its visible From domain under the applicable alignment mode. Service verification alone is insufficient.

Can Zendesk authentication guarantee the inbox?

No. The recipient retains its own acceptance and filtering policy. Keep authentication results separate from placement and reputation evidence.

What should I save for a Zendesk handover?

Save the product route, approved DNS diff, verification status and redacted receiver evidence. Include the timestamp and sender identity, but exclude credentials and private keys.

When should the Zendesk route be retested?

Retest after a domain or selector change, relay migration, sending-channel change or rollback. Cover each distinct sender domain and representative message type.

[ Sources ]

Sources

  1. Digitally signing your email with DKIM – Zendesk help

    Sections Updating your DNS records to use the Zendesk domain key · Enabling digital signatures in Zendesk

  2. Allowing Zendesk to send email on behalf of your email domain – Zendesk help

    Sections Setting up records for your domain

  3. dmarc

    Sections §4.4 · §5.3.5 · §7.4

  4. spf

    Sections §4.5 · §4.6.4

  5. dkim

    Sections §3.5 · §3.6.1 · §6.1

[ Glossary ]

Glossary

Alignment
The required relationship between the visible From domain and an authenticated SPF or DKIM domain.
Selector
The DKIM signature identifier that selects a DNS public key beneath the signing domain.
Return-Path
The delivered representation of the SMTP reverse-path, useful alongside receiver results when identifying the SPF domain.

Enterprise provenance

Why top financial institutions and governments retired their email security dashboards.

Traditional email authentication platforms sell you a dashboard and ask your engineers to do the labour. In high-stakes environments, manual oversight means delayed enforcement, configuration drift and unmonitored shadow domains.

EmailAuth is the agentic email provenance platform. Our agents enforce p=reject, keep third-party senders aligned and move your domains to full RFC 9989 compliance, the new DMARC standard,, with human-in-the-loop auditability.

Governments Large enterprises Tier-1 financial institutions

SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption

Knowledge Base