Zendesk now checks email authentication by default
- Matteo
- 4 min. read
Zendesk has announced that sender authentication is now enabled by default for incoming email.
For domain owners, this matters even if you don’t use Zendesk yourself: organizations you contact may use it to handle their support emails. Authentication problems can cause your messages to be suspended instead of reaching the normal support ticket workflow.
This news is significant because Zendesk is used by hundreds of thousands of companies all over the world. It follows a broader trend of stricter email authentication already seen with Gmail and Yahoo, Outlook and Cloudflare Email Routing.
What’s changing
Zendesk is making Minimal, its least-strict sender authentication profile, the default. New accounts have it enabled, and Zendesk scheduled a staged rollout to existing accounts between 23 September and 22 October 2026.
Account administrators can still choose a stricter profile or disable authentication. For senders, however, the change means authentication checks are becoming the standard behavior at another email destination.
Which emails are affected
According to Zendesk’s authentication documentation, the default Minimal profile applies these rules:
| Authentication results | Outcome |
|---|---|
| SPF fails, and DKIM fails or isn’t configured | Suspended |
| SPF isn’t configured, and DKIM fails | Accepted with a potential-spoofing flag |
| Other combinations | Accepted |
When a message is suspended it means it has reached Zendesk, but is held for review instead of creating or updating a normal support ticket. Your email may therefore need to be recovered by the recipient’s support team before it can be handled.
Zendesk applies stricter rules to some domains, including zendesk.com, and always authenticates messages from addresses belonging to agents in the recipient’s Zendesk account. Recipients can also choose stricter authentication profiles, so configuring SPF and DKIM correctly is the safer approach.
Stricter profiles also check DMARC
Recipients can choose two stricter authentication profiles, depending on how email reaches their support team:
| Profile | Email sent directly to Zendesk | Email forwarded to Zendesk |
|---|---|---|
| Native traffic | Stricter checks, including DMARC | Minimal checks |
| Native and forwarded traffic | Stricter checks, including DMARC | Additional checks using ARC |
Direct email goes to an address such as support@company.zendesk.com. Forwarded email first reaches another address, such as support@company.com, before being passed to Zendesk.
For direct email, the additional DMARC rule suspends a message when all three conditions are met:
- The From address uses a domain verified in the recipient’s Zendesk account.
- That domain publishes a DMARC policy of
p=quarantineorp=reject. - The message fails DMARC.
For forwarded email, the strictest profile uses ARC to check the forwarding chain and earlier authentication results. Invalid ARC seals or failing authentication throughout the chain can cause suspension. If there are no ARC headers, Zendesk falls back to the Native traffic checks.
For domain owners, these additional checks are another reason to aim for DMARC compliance, rather than stopping at an SPF record and a DKIM signature.
DMARC checks that a passing SPF or DKIM result is aligned with the domain in the visible From address. Authentication using only your email provider’s shared domain may pass SPF or DKIM without authenticating your own domain for DMARC purposes.
What you should do
If you send email from your domain, make sure that all your sending services are correctly configured. That includes your main email provider, but also contact forms, transactional email platforms and any other tools that send on your behalf.
- Verify SPF. The servers sending your messages must be authorized by the SPF record for the envelope sender domain. Where supported, configure a custom Return-Path to achieve alignment with your From domain.
- Enable DKIM signing for your domain. Look for custom DKIM settings in each sending service, and check that signatures pass and align with your From domain.
- Set up DMARC reporting. Start with
p=noneto identify authentication and alignment problems before moving toward an enforcement policy. - Test actual messages. Publishing DNS records alone doesn’t prove that a service is using them correctly. Check messages from each sending source, including after configuration changes.
Our guide to DMARC compliance explains how to identify your sending sources, fix alignment issues and gradually enforce a DMARC policy.
At DMARCwise, you can test your email authentication for free and use DMARC monitoring to find misconfigured sending sources. Getting these right helps your email meet authentication expectations across the providers your recipients rely on.
