Zendesk SPF, DKIM & DMARC Setup Guide

Overview

Zendesk is a customer support platform that sends email on behalf of your domain for ticket notifications, agent replies, satisfaction surveys, and automated trigger-based responses. Its SPF record uses include:mail.zendesk.com, costing 1 DNS lookup. Support desk email volume can be substantial — every ticket update, agent response, and automation rule generates outbound messages from your domain.

DKIM Setup and Key Rotation

DKIM in Zendesk uses two CNAME records with selectors zendesk1 and zendesk2. This dual-selector design supports quarterly key rotation — Zendesk introduces a new key on one selector while the previous key remains active on the other, maintaining continuous DKIM verification during the transition. The CNAME delegation model means Zendesk manages the signing keys behind the records; no manual key updates are required after initial setup.

The order of operations for DKIM is critical: publish both CNAME records in your DNS and allow them to propagate before enabling DKIM signing in the Zendesk Admin Center. Enabling signing without published records causes immediate delivery failures — Zendesk begins adding DKIM signatures to outbound messages, but receiving mail servers cannot locate the public key to verify them. The result is DKIM verification failures on every message until the records propagate or signing is disabled.

DMARC Alignment

DMARC alignment requires both SPF (via include:mail.zendesk.com) and DKIM (via CNAME delegation) to be configured. With relaxed alignment, either mechanism passing is sufficient for DMARC to pass. For organizations enforcing strict DMARC alignment (adkim=s), the DKIM signing domain must exactly match the From header domain — verify that Zendesk is signing with your exact domain and not a subdomain.

Troubleshooting

DKIM Enabled Before DNS Records Propagated

This is the single most common Zendesk authentication failure. An administrator publishes the CNAME records and immediately enables DKIM signing in the Admin Center without waiting for propagation. Every outbound message then fails DKIM verification until the records are visible to receiving servers. The fix: disable DKIM signing in Zendesk, wait for CNAME propagation (verify with a DKIM checker tool), then re-enable signing. Allow at least 1-2 hours for propagation, though most providers complete it within 30 minutes.

Ticket Replies Landing in Spam

If authenticated ticket replies are still landing in spam, check several things in order. First, verify that include:mail.zendesk.com is present in your SPF record — not include:zendesk.com (which is incorrect). Second, confirm DKIM is enabled and both zendesk1 and zendesk2 CNAME records resolve correctly. Third, check that the support email address in Zendesk uses your domain (e.g., support@example.com), not a Zendesk-provided address. Fourth, inspect message headers from a recent ticket reply to confirm Authentication-Results shows SPF and DKIM passing.

Multiple Zendesk Instances (Sandbox and Production)

Organizations with both a Zendesk sandbox and production instance sometimes configure DKIM for one but not the other. Sandbox instances that send test emails from your domain without DKIM signing will generate DMARC failures in your aggregate reports. Either configure DKIM for both instances or ensure the sandbox uses a different sending domain (e.g., sandbox.example.com) to isolate test traffic from production DMARC reporting.

Zendesk Triggers and Automation Volume

Zendesk triggers fire on ticket events and can generate significant email volume. Poorly configured triggers — such as a trigger that fires on every ticket update, including internal notes — can send unexpected emails from your domain. These messages are authenticated if SPF and DKIM are configured, but the volume itself can affect your sending reputation. Audit your trigger rules regularly and ensure internal-note updates do not generate external notifications.

Additional Setup Notes

Why Support Desks Get Skipped

Zendesk support email is frequently overlooked during email authentication configuration. Organizations set up SPF, DKIM, and DMARC for their primary email platform and marketing tools but leave the support desk unconfigured. Without authentication, support ticket replies fail DMARC alignment checks and can be filtered or quarantined by recipients' mail servers — directly impacting customer communication at the exact moment a customer needs help.

Lookup Budget Considerations

When adding Zendesk to an existing SPF record that already includes a primary email platform and marketing tools, the additional lookup from include:mail.zendesk.com can push the total past the 10-lookup limit. A typical stack of Google Workspace + HubSpot or Mailchimp + SendGrid already uses 3 lookups. Adding Zendesk brings the count to 4, plus any email security gateway (Mimecast, Proofpoint, MailRoute) pushes it to 5-6. Factor in nested lookups within each provider's include chain and the effective count climbs higher.

Migrating Between Help Desk Platforms

When migrating from Freshdesk, Intercom, or another support platform to Zendesk, run both SPF includes in parallel during the migration window. Remove the old provider's include only after all support email is flowing through Zendesk. When migrating away from Zendesk, disable DKIM signing before removing the CNAME records — this prevents a window where Zendesk signs messages that cannot be verified.

Using a Subdomain for Support Email

Some organizations route support email through a subdomain like support.example.com or help.example.com. When using a subdomain, the SPF record with include:mail.zendesk.com and the DKIM CNAME records are published on the subdomain's DNS zone, not the apex domain. This isolates support email reputation from the primary domain and keeps the root domain's SPF record cleaner. DMARC alignment still passes under relaxed mode because the organizational domain matches.

Managed SPF can flatten nested includes into direct IP references, freeing up lookup budget for additional providers.