Zendesk Now Lets One Email Address Belong to Several Customers. Here's Why It Matters.

On 3 November 2026, Zendesk rolled out shared email identities: a setting that lets several customers use the same email address and still have separate profiles. The release puts a name to a habit that most helpdesks, ours included, have built in from the start. They treat an email address as if it were a person.

What changed

Zendesk's announcement describes the shift in one sentence: "With shared email and email-optional SSO, email can be a contact method instead of the identifier of a person."

The shipped part is shared email. In Zendesk's words, it "lets multiple end-user profiles use the same email address while keeping separate records, external IDs, and ticket histories. This supports common scenarios such as household accounts, shared business inboxes, and representatives who contact support for more than one customer." And: "Agents can identify when an email address is shared and select the right person when needed."

It is off unless you turn it on. The announcement says: "No action is required if your organization doesn't want to support shared email addresses for end users. This feature is turned off by default." Admins enable it in Admin Center under Configuration > End users, in a section called Shared email identities.

The second part, email-optional SSO, is not generally available. It is an early access program (EAP) that organisations sign up for. It lets people sign in to the help center with an identifier such as an employee ID or member number instead of an email address. Zendesk notes that "Users without email can still access the help center and follow their requests; email-only features are unavailable to them."

The trade-offs Zendesk lists

Zendesk's supporting articles are clear about what changes when an address is shared:

• Sign-in. "A shared email receives notifications, but end users can't use it as a standard sign-in credential or password-reset address." People who share an address need an address of their own, or an SSO setup that doesn't require email.
• One owner, others shared. "The first end user associated with an email address is the owner." The owner is "prioritized as the requester when Zendesk receives an email."
• Inbound matching. For new email, "Zendesk uses verification status, ownership, identity age, and existing ticket participation to determine the appropriate user." A reply to an existing ticket goes to that ticket's requester or CC first.
• Nothing converts by itself. "Turning on this feature doesn't automatically convert existing email addresses to shared." If you later turn it off, existing shared addresses keep working, and moving them back to owned addresses is a manual job.
• Customers only. "This feature doesn't apply to agents."

Why email was never really a person

Keying customers by email is a shortcut, and usually a reasonable one: almost everyone has an address, and it arrives with every message. It breaks in familiar places:

• Households. Two people on one family account, writing from the same address about different orders.
• Shared business inboxes. A shop's info@ or a team's support@, where whoever is on shift writes in.
• Representatives. An assistant, accountant or agency contacting support for several clients from one address.
• People without a usable email. Frontline staff with no work address, or members known by a number.

When identity is the email, each of these becomes one blended profile. Ticket history mixes several people. Satisfaction scores, past refunds and notes get attached to the wrong person. And anyone who can read the shared inbox can see every conversation sent to it.

Where DeskLeap stands

We use the same shortcut, so here is how DeskLeap behaves today, as checked in our code on 4 November 2026:

• Tickets are keyed by email. A ticket's requester is an email address. Two people who write in from the same address are, to a ticket, the same requester.
• The customer portal is email-scoped. Customers sign in with a one-time code sent to their address and see the tickets filed under it. Anyone with access to a shared inbox sees the same history.
• Contacts are joined on email. The Contacts view combines ticket requesters and chat visitors by email address, so a shared address shows up as one contact.
• Live chat can use your own ID. If your site identifies signed-in visitors with its own user ID, verified with your widget's identity secret, each ID is a separate visitor record, even when two visitors share an email address.

So for a household or a shared inbox, DeskLeap today gives you one requester, not several. If that matters for your customers, the practical options are to identify signed-in users by your own verified ID in live chat, and to ask people writing from shared addresses to include an account or order number.

Questions to ask about any helpdesk

• What does it use as a customer's identity: email, phone, or an ID from your own system?
• If two people share an address, do they get separate histories, and can either one see the other's tickets?
• Who can sign in to the help center or portal with that address, and what can they see once they do?
• If you change the identity model later, what happens to existing records? Is the change automatic or manual?

Zendesk has given its customers a choice, left off by default, and documented the trade-offs. The useful step for any team is to know which model its own tool uses before a shared inbox causes a problem.

DeskLeap is a ticketing, live chat and knowledge base platform. The platform is 100% free with unlimited human agents; an optional AI Agent add-on is $29/mo each.

Sources

Zendesk, Announcing the ability for end users to share email addresses (rolled out 3 November 2026; edited 3 November 2026; read 4 November 2026). Zendesk, Understanding shared end-user email addresses, Turning on and off shared end-user email addresses and Turning on email-optional SSO for help center (EAP) (all updated 3 November 2026; read 4 November 2026). Quotations are verbatim from those pages. DeskLeap's behaviour is described from our own code as of 4 November 2026.