Zendesk Sender Authentication: Test SPF and DKIM Now

Zendesk has started making its Minimal sender authentication profile the default for eligible accounts. An email that fails SPF while DKIM is missing or also fails can go to Suspended tickets instead of the normal support workflow. Any team that depends on a Zendesk-powered support address should test that route from every system that sends on its behalf.

What Zendesk changed

Zendesk announced a new sender authentication standard on June 18, 2026. New accounts receive the Minimal profile by default. On September 23, Zendesk began a staged rollout that selects Minimal for eligible accounts where sender authentication had been disabled.

The change applies to every incoming email covered by the account's profile, including one-to-one messages. If your team emails a supplier, software provider, or customer through a Zendesk support address, the receiving account can apply these checks before creating or updating a ticket.

Zendesk still lets an account administrator change the profile or disable sender authentication. Treating that switch as the fix would move the risk to the support desk. The better response is to find the sending system that cannot prove its identity and repair that path.

The exact failure condition under Minimal

Zendesk documents three outcomes for its Minimal authentication profile:

Publishing an SPF record is not enough. If that record no longer authorizes the service sending the message, SPF can fail. Without a valid DKIM signature to provide the other passing signal, Zendesk sends the email to Suspended tickets with the cause "Email authentication failed."

A Zendesk administrator can still inspect the message in the Suspended tickets view. The message has not entered the normal ticket update path, so the support agent handling the account may never see it during routine work.

Zendesk also states that email from agent addresses is authenticated regardless of the account setting. Internal replies and agent mailbox workflows belong in the same test plan as external customer mail.

Run a controlled test from every mail stream

Build the test matrix before changing DNS. Use one row for each combination of sending domain and sending service, then add the Zendesk destinations the business depends on.

Send a uniquely labeled message from every row. Ask the Zendesk administrator to confirm whether it became a normal ticket and to search Suspended tickets for the test label. Save the full authentication results from the received message when available.

Do not stop after checking an online SPF or DKIM lookup. A DNS lookup can show that a record exists. The end-to-end test shows whether the actual service uses an authorized envelope domain, adds a valid signature, survives any forwarding step, and reaches the expected Zendesk workflow.

Our view is that this belongs in continuity testing, not in a one-time deliverability checklist. A support request can carry a renewal question, an outage escalation, or a reply from a buyer. The business consequence comes from the workflow that fails after acceptance, not from a campaign dashboard.

Test forwarded support addresses separately

Many support teams publish an address on their own domain and forward that mail into a native Zendesk address. That route needs its own row in the matrix.

Zendesk evaluates SPF, DKIM, DMARC, and ARC. SPF checks the server that handed over the message, so forwarding can leave Zendesk looking at a server that was not authorized by the original sender's SPF record. A valid DKIM signature can survive forwarding if the signed content and headers remain intact. ARC can preserve authentication results across forwarding hops.

Zendesk's profile rules reflect that difference. Native traffic applies stricter checks to messages sent directly to the native Zendesk address, while forwarded traffic remains under Minimal unless the account uses the stricter Native and forwarded traffic profile. Under that strictest profile, Zendesk also evaluates the ARC seals and the authentication results recorded by each forwarder.

Test both addresses when the team uses forwarding:

1. Send directly to the native Zendesk address.
2. Send the same labeled test to the public support address that forwards into Zendesk.
3. Compare the authentication results and Zendesk outcome.
4. Investigate any result that changes between the two routes.

This comparison separates a sender problem from a forwarding problem. Fixing sender DNS will not repair a forwarder that alters a DKIM-signed header or fails to preserve trustworthy authentication evidence.

Assign ownership before fixing DNS

A failed test needs an owner for the sending service and an owner for DNS. Those may be different people. The service owner can confirm the envelope sender, DKIM selector, and current sending source. The DNS owner can change the record without guessing which old provider is safe to remove.

Keep a sending-domain register with the service, owner, SPF mechanism, DKIM selector, return-path domain, and last successful end-to-end test. Retest when any of these changes:

• a sending provider is added, removed, or migrated;
• a domain or subdomain starts carrying a new mail stream;
• a relay, gateway, or forwarding rule changes;
• a DKIM key or selector rotates;
• a Zendesk authentication profile changes.

The control is complete when each active route has a named owner, a passing test, retained evidence, and a retest trigger. A green DNS screenshot without a Zendesk outcome is incomplete evidence.

Check Suspended tickets during the rollout

Zendesk tells administrators to monitor the Suspended tickets view and resolve spam or forwarding problems at the source. During the staged rollout, review suspensions for the cause "Email authentication failed" and group them by sender domain and route.

Recover a test message only after checking that it came from the expected sender. Zendesk warns that a suspended ticket is not necessarily from the identity it claims to use. The suspension is a security control, so recovery should not become an automatic bypass.

For the outbound team, the immediate action is smaller: list the Zendesk support addresses your sales, operations, and customer teams rely on, then run the matrix from every active mail stream. If you want sender ownership, authentication checks, reply handling, and campaign operations managed as one system your team keeps, book your free ICP and campaign-fit discovery call →.