TL;DR: Zendesk’s move to make sender authentication the default for inbound support email means broken SPF or DKIM can now prevent legitimate messages from becoming tickets, according to EasyDMARC. The shift extends inbox-authentication pressure beyond consumer mail to support workflows, making DMARC visibility and forwarding-path controls operationally important.
At a glance
What this is: Zendesk is making sender authentication the default for inbound support email, and mail that fails SPF or DKIM can now be suspended instead of becoming a ticket.
Why it matters: For IAM and identity teams, this turns email authentication from a deliverability concern into an access-to-service control that can block legitimate business communications when sender identity is not provable.
By the numbers:
- Zendesk says the rollout starts on June 18 2026, with eligible accounts moved from September 23, 2026.
- EasyDMARC says 52.1% of the top 1.8 million domains have a valid DMARC record.
Context
Email authentication has moved from a deliverability hygiene issue to an operational control point for support workflows. When a support platform checks SPF, DKIM, DMARC, and ARC before turning mail into a ticket, the sender’s ability to prove domain identity becomes part of business continuity, not just security posture.
That matters because support inboxes sit outside the traditional inbox-enforcement story. Consumer mailbox rules from Google, Yahoo, and Microsoft focused on bulk senders reaching end users, but Zendesk extends the same logic to customer service intake, where forwarded mail, agent replies, and unauthenticated internal systems can all be affected.
Key questions
Q: What breaks when support platforms enforce sender authentication but SPF or DKIM is misconfigured?
A: Legitimate mail can be suspended before it becomes a ticket, even when the sender believes delivery succeeded. The practical failure is not just spoofing resistance but hidden service denial. Teams lose visibility into requests, forwarded mail becomes fragile, and support queues no longer reflect what customers think they sent.
Q: Why do forwarded emails fail authentication more often than direct sends?
A: Forwarding changes the path that SPF evaluates, so the forwarder’s IP can invalidate the original sender’s alignment. DKIM can survive if the signature remains intact, and ARC can preserve evidence through the chain. Without those controls, a message that is valid at origin may fail at intake.
Q: How can security teams tell whether email authentication is enough?
A: It is not enough when the sender account, domain, and communication style can all be genuine. If the decision to trust a message depends on identity context, recipient relationship, or unusual hosting choices, then authentication alone is only one input, not the control outcome.
Q: Should organisations enable stricter inbound mail checks before every sender is fully aligned?
A: Not usually. Stricter checks are best introduced only after you know which systems send mail, how forwarding behaves, and whether DKIM survives every path. Otherwise, a well-meant control can break customer communication, internal alerts, and agent replies at the same time.
Technical breakdown
How support inbox authentication decides whether mail becomes a ticket
Zendesk’s Minimal profile creates a decision tree around SPF and DKIM, with DMARC and ARC adding stricter handling in other profiles. The key distinction is that message acceptance no longer guarantees ticket creation. A message can be received by the platform, then suspended if authentication outcomes do not meet the configured bar. That changes the control from transport to intake, which is why mail that previously “arrived” can still disappear from an operational workflow. See the DMARC, SPF and DKIM Guide.
Practical implication: Treat support inbox authentication as a service entry control and test how each sending path behaves under SPF, DKIM, DMARC, and forwarding conditions.
Why forwarded mail and agent replies are the fragile paths
Forwarding breaks the simple assumption that the original sender’s authentication will survive unchanged. SPF often fails because the forwarder’s IP no longer matches the original domain path, while DKIM can survive if the signature remains intact. ARC is designed to preserve authentication evidence through forwarding chains. Zendesk’s strictest profile uses that evidence to decide whether auto-forwarded mail should be trusted, which means every relay, alias, and mailbox rule becomes part of the authentication surface. See the Email Authentication for Developers Guide.
Practical implication: Map every forwarding path and verify that DKIM survives transit, because forwarding is where support-ticket failures are most likely to emerge.
Why broken SPF can be worse than no SPF at all
Under Zendesk’s Minimal profile, a domain with no SPF and no DKIM can still pass if the other checks do not fail. But a published SPF record that fails, combined with missing or broken DKIM, can trigger suspension. That creates a governance problem many teams miss: stale DNS records become an active liability rather than a neutral gap. Once authentication is enforced at intake, half-maintained mail policy can be worse than no policy, because the platform now reacts to the failure instead of ignoring it.
Practical implication: Audit SPF hygiene as a live control, not a one-time setup task, and remove obsolete senders before they turn into support-ticket outages.
Threat narrative
Attacker objective: The practical objective is not always theft but denial of trusted communication, which can hide legitimate requests, delay support handling, and make spoofed mail harder to distinguish from real traffic.
- Entry occurs when a legitimate sender or forwarded message reaches a Zendesk-powered support address with incomplete or broken authentication.
- Credential or trust evidence is then evaluated through SPF, DKIM, DMARC, and ARC, and weak authentication causes the message to be suspended instead of ticketed.
- The impact is service degradation, because the sender believes support received the message while the help desk never sees it in the active queue.
Breaches seen in the wild
- Internet Archive breach 2024: An exposed GitLab token opened Internet Archive code and 31 million user records; unrotated Zendesk tokens let the attacker back in weeks later.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Support inbox authentication is becoming an intake control, not just a mail hygiene setting. Once a platform decides whether a message becomes a ticket based on SPF, DKIM, DMARC, and ARC, the identity proofing question shifts from inbox delivery to service access. That is a governance change, because availability of customer communications now depends on the quality of sender identity signals rather than simple receipt. Practitioners should treat this as part of identity and access design, not an email-only concern.
The new failure mode is partial authentication drift. Many organisations will not fail because they never configured email authentication; they will fail because they configured it once and then let DNS, forwarding, or sender inventory drift. A stale SPF record can become the trigger for suspension, while unauthenticated internal systems and agent mail create hidden dependencies. This is a textbook case of identity control rot, where policy exists on paper but no longer matches live traffic.
DMARC reporting is now operational evidence, not just compliance paperwork. If support workflows can be blocked by sender authentication, then aggregate reports become a map of which identities are actually speaking for the domain. That makes reporting essential for exception handling, not merely audit comfort. Teams that still treat DMARC as a future-state project are leaving a live exposure window open across customer support, internal systems, and forwarded mail.
Mailbox platforms are inheriting policy burden once reserved for major inbox providers. The practical signal is that authentication thresholds are moving deeper into the service stack, where the business cost of failure is immediate and visible. That will force IAM and email owners to align more closely on sender inventory, delegated mail paths, and domain governance. The right posture is to assume every externally facing workflow that accepts email may soon enforce similar controls.
What this signals
Inbox authentication is spreading beyond consumer email. The important change is not that one platform tightened policy, but that authentication controls are now moving into the workflow systems that receive business-critical mail. That means email identity governance will increasingly need to cover support desks, customer service aliases, and other operational intake points, not just outbound campaigns.
Broken sender identity now creates a service failure mode. When a message can be accepted and still vanish into a suspended queue, teams need controls that verify the entire path, not just the original sender. That pushes organisations toward stronger mail identity governance, especially where forwarding, agent replies, and unauthenticated internal systems intersect with customer communications.
For practitioners
- Fix DKIM on every active mail stream Sign each sending source with DKIM on your own domain, including application mail, service desks, and agent mailboxes, so forwarded messages still have a durable authentication signal.
- Rebuild SPF around live senders only Remove obsolete services, stay below the 10 DNS lookup limit, and verify that every authorised sender passes in production rather than only on paper.
- Inspect the Suspended tickets view daily Sort by suspension reason and watch for repeated authentication failures, because Zendesk accepts the mail and hides it from the active queue instead of bouncing it.
- Test forwarding paths end to end Validate how aliases, forwarders, and security gateways affect SPF, DKIM, and ARC before you rely on them for support intake.
- Move toward DMARC enforcement before tightening intake Use aggregate reports to understand every sender first, then progress from monitoring to enforcement so support workflows are not broken by unknown mail sources.
Key takeaways
- Email authentication is no longer only about inbox reputation. It now decides whether some support requests become tickets at all.
- Forwarding paths are a primary risk because they can break SPF even when the original message was legitimate.
- Teams need live DMARC visibility, clean SPF records, and durable DKIM signing if they want support mail to remain reliable.
Related NHI Mgmt Group resources: DMARC, SPF and DKIM Guide · Email Authentication for Developers Guide · Email Identity and BEC Guide · Workforce Identity Security Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Inbound mail acceptance now depends on whether sender authentication is valid and aligned. |
| NHI-02 — Secret Leakage | Broken or stale DKIM and SPF setups often stem from exposed, outdated, or unmanaged credentials and keys. | |
| Recommendation — Treat failed sender authentication as a control gap and verify every mail path against NHI-04. Inventory and rotate mail signing keys and remove stale authentication artefacts before they cause suspension. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Mail authentication relies on ongoing management of authenticators and their lifecycle. |
| Recommendation — Apply IA-5 to manage DKIM keys, SPF records, and their rotation across all sending systems. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article highlights unmanaged sender sources and agent accounts that can silently fail authentication. |
| Recommendation — Use CIS-5 to inventory every sending account and disable mail paths that are no longer authorised. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Authentication and authorisation for mail senders determine whether messages are accepted into support workflows. |
| Recommendation — Apply PR.AA-05 to verify that only authorised domains and systems can submit trusted mail into support channels. | ||
Key terms
- Email Authentication: Email authentication is the set of controls that help recipients verify whether a message really came from a domain. SPF, DKIM, and DMARC reduce spoofing and impersonation, but they work best when combined with domain lifecycle management and user awareness.
- SPF: SPF is a DNS-based policy that lists which systems are permitted to send email on behalf of a domain. It helps mail receivers validate whether the sender matches the domain’s declared sources, reducing the chance of forged or impersonated messages.
- DKIM: DKIM is an email signing method that relies on a public key published in DNS to let receivers validate message integrity. In practice, the DNS record becomes part of the trust chain, so key management and DNS governance must stay aligned if organisations want reliable authentication.
- ARC: ARC is an older archive format for storing crawled web content and HTTP transactions. Like WARC, it can contain page content and supporting resources that expose personal, financial, or credential-related information, so organisations need content-aware scanning rather than assuming it is only a static record.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners who need to connect identity controls to operational risk. It helps teams translate identity governance into practical security decisions across modern enterprise workflows.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org