Zendesk Notifications Not Sending: Causes and Fixes

This guide debugs it the authoritative way — read the ticket Events log to see whether Zendesk even attempted the notification — then walks the causes ranked by how often they're the real culprit, split into customer-facing email notifications and agent notifications, with a concrete fix for each. Everything below is checked against Zendesk's own documentation; Zendesk revises its UI periodically, so confirm labels in your own account.

The symptom: "notifications aren't going out"

"Not sending" usually shows up as one of these:

• Customers don't get the auto-reply when they submit a ticket, or the email when an agent replies.
• Agents don't get an email when a ticket is assigned to them or their group.
• Notifications were working and silently stopped after someone edited the account.
• Notifications go out for some tickets but not the one in front of you (e.g. nothing fires when you add an internal note).

All four are diagnosable the same way, and most have nothing to do with Zendesk being "down." Resist the urge to start toggling settings blindly. Read the evidence first.

Step 1 — Debug authoritatively: read the ticket Events log

Every ticket keeps a complete audit trail of who (or what) changed it — and crucially, whether a notification was attempted. This is the fastest way to cut the problem in half: Zendesk never tried to send vs. Zendesk sent it but it didn't arrive. Those have completely different fixes.

To open the log on any ticket:

• Add /events to the end of the ticket URL (e.g. …/agent/tickets/12345/events), or
• In the Agent Workspace, open the ticket, click the Conversations menu, and choose Events.

Now look for the Email notification property in the events. Per Zendesk's How can I tell if Zendesk is sending email notifications to customers?, each outgoing notification appears as an Email notification entry followed by an ID number — and you can click the ID to view the exact email that went out and who it went to. That single read tells you everything:

• Email notification is present → Zendesk did send it. Your problem is delivery, not Zendesk: a bounce, a blocklist, spam filtering, or a wrong recipient. Jump to causes 4 and 7.
• Email notification is absent → Zendesk never sent it. As the doc states plainly, "if the Email notification event doesn't exist in the event log, an email notification wasn't sent." That means a trigger didn't fire (or fired with nothing to send). Work causes 1, 2, 3, 6, and 8.

Because notifications are triggers, this is the same evidence-first method you'd use for any business-rule problem — see Zendesk triggers not firing for the deeper trigger-debugging playbook (rule analysis, ALL vs ANY, the events log). With the log read, here are the causes — ranked.

Customer-facing (email) notifications

These are the emails to the requester and CCs. They are all powered by two standard triggers: Notify requester and CCs of received request (fires when a ticket is created with a public comment) and Notify requester and CCs of comment update (fires when a ticket is updated with a public comment).

1. A notification trigger is deactivated or misconfigured — the #1 cause

This is far and away the most common reason customers stop getting email. Notifications are triggers, and a trigger that's toggled inactive does nothing. Zendesk says it directly in My customers don't receive emails: "If notification triggers are inactive, ticket updates don't send an email to the customer." Both default customer triggers must show Active. A trigger can also be broken rather than off — Zendesk auto-deactivates a trigger that references a field, group, or form that was later deleted or renamed.

There's a second, sneaky version of "misconfigured": the email body has no placeholder. Per the same doc, "ensure the body of your email contains placeholders. Without a placeholder, the message does not send." Someone clears out the comment placeholder (the ticket.comments_formatted field, wrapped in double curly braces) while editing the wording, and the notification silently stops.

Confirm: Go to Admin Center → Objects and rules → Business rules → Triggers and check the Inactive tab. If a notification trigger is there, that's your answer. If it's active, open it and confirm the email body still contains at least one placeholder. Fix: Reactivate it. If it keeps deactivating, repoint the condition/action that references a deleted field or group. If a placeholder was removed, add it back. As Zendesk recommends, never edit a standard trigger destructively — clone it, edit the clone, and deactivate the original so you can always restore the default.

2. The comment was internal (public vs. internal note)

This is the "works for some tickets, not others" case — and it's by design. The customer-notification triggers require a public comment. Internal notes are private comments, so adding one never emails the requester. Agents constantly type a careful internal note, assume the customer saw it, and are baffled when "no notification went out."

Confirm: Open the ticket and check whether the comment was posted as Public reply or Internal note. In the Events log, an internal note won't produce an Email notification to the requester. Fix: If the customer should have received it, the comment must be public. There's no notification to "turn on" for internal notes to customers — that's intentional. Train agents to watch the public/internal toggle, the most common cause of "the customer never got my message."

3. Trigger order — an earlier trigger changed the ticket first

The subtle one. Triggers run top-to-bottom in the exact order they're listed. An earlier trigger's action can change the ticket so that, by the time the notify trigger is evaluated, its conditions no longer match — for example, an earlier rule sets the status to Solved or strips a tag the notification trigger depends on, and the notify trigger is skipped.

Confirm: In the Events log, look at what fired before the expected notification. If an earlier trigger changed the status, group, or a tag the notify trigger keys on, that's your interference. Fix: Reorder so notification triggers run after the triggers that set the values they announce, and tighten the earlier trigger so it doesn't overreach. Full method in Zendesk triggers not firing.

4. The recipient is blocklisted, bouncing, or suspended

If the Events log shows the Email notification was sent but it never arrived, the trigger did its job — delivery failed downstream. A few specifics worth knowing:

• Blocklist: counterintuitively, a blocklisted address still receives notifications if it's the requester or a CC on the ticket. The blocklist's reject keyword blocks inbound mail and gives the sender no indication it was rejected — per Understanding the allowlist and blocklist. So a blocklist entry rarely explains a missing outbound notification, but it absolutely explains "their replies never create/update a ticket."
• Bounces / delivery failures: when an outbound email bounces, the Agent Workspace shows a delivery-failure message directly on the comment (Understanding email delivery failures). That's your signal the recipient's mail server rejected it.
• No email on the user record: if the requester's user profile has no email address, there's nowhere to send.

Confirm: Click the Email notification ID in the events to see the exact recipient, check the comment for a delivery-failure banner, and verify the user profile has a valid email. Fix: Correct or add the user's email, ask the recipient to allowlist your support address, and follow up on hard bounces (the address may be dead or rejecting you).

Agent notifications

These are emails to agents — assignment alerts and comment updates. They're driven by a different set of standard triggers: Notify assignee of assignment, Notify assignee of comment update, Notify assignee of reopened ticket, Notify group of assignment, and Notify all agents of received request.

5. The agent isn't actually assigned / following / CC'd — or has notifications turned off

Agent notifications only reach an agent who has a reason to be notified: they're the assignee, a member of the assigned group, a CC, or a follower. The "Notify assignee" triggers only target the assignee — if the ticket is unassigned (or assigned to someone else), the agent gets nothing. Note too that Notify assignee of assignment fires when the assignee is changed by someone other than the assignee themselves — so an agent who self-assigns won't email themselves.

The second half: each agent can switch off their own ticket emails in their personal settings (see How can I stop receiving email notifications when a ticket is assigned to me?). An agent who muted notifications then reports "I'm not getting notified" is usually the explanation.

Confirm: Check the ticket's assignee/group against the agent in question, and confirm the relevant Notify assignee/group trigger is active. Then check whether the agent disabled their own notifications. Fix: Make sure routing actually assigns the ticket to that agent or their group; activate/repair the assignment trigger; and have the agent re-enable notifications (or add them as a CC/follower if they need visibility without ownership).

6. The agent trigger is deactivated or its conditions don't match

Same root cause as #1, but for agents. Someone disables Notify all agents of received request to stop inbox noise, then wonders why nobody's alerted to new tickets. Or an admin adds a channel/group condition that the actual ticket doesn't meet, so the trigger is skipped.

Confirm: In Admin Center → Triggers, check whether the agent-notification triggers are active and read their conditions against the actual ticket (channel, group, "created by agent vs end user"). Fix: Reactivate, or loosen/correct the over-specific condition. If you turned off "Notify all agents" on purpose, route via Notify group of assignment instead so the right agents are alerted without spamming everyone.

Cross-cutting causes (customer and agent)

7. Email deliverability — SPF, DKIM, DMARC, and spam

Even a perfectly-fired notification can be filtered or rejected by the recipient's mail server. If your domain lacks the right authentication, providers downgrade or block Zendesk's mail. Per Troubleshooting email deliverability, you need a valid SPF record that authorizes Zendesk, DKIM signing, and a DMARC policy — without them, strict providers filter or reject your messages, and notifications quietly land in spam.

Confirm: The Email notification event exists (Zendesk sent it) but the recipient can't find it. Have them check spam/junk first. Fix: Set up SPF, DKIM, and DMARC for your sending domain, and ask recipients to allowlist your support address. This is the most common reason "it shows as sent but never arrived."

8. Rate / loop suppression — Zendesk deliberately holds some notifications

Zendesk intentionally suppresses certain notifications to prevent mail storms, and this can look like "notifications not working." Two documented mechanisms:

• No-comment suppression: to avoid loops, Zendesk suppresses a notification generated when no comment was added (relevant when recovering suspended messages or allowlisting a sender) — per About mail loops and Zendesk email.
• Per-user rate limit: as a last-resort loop guard, Zendesk limits a single user to 20 email updates within an hour (About mail loops and Zendesk email). A noisy integration or a forwarding loop can blow through that and get throttled.

Confirm: High-volume automated updates, an external address auto-forwarding into Zendesk, or notifications that stop mid-burst point here. Fix: Break the forwarding loop, slow down whatever's hammering the ticket, and make sure your triggers add a real public comment when they're meant to notify (a notification with no comment is exactly what gets suppressed).

9. Sandbox / test environment sending limits

If you're testing in a sandbox, don't trust the absence of email. Sandboxes are isolated test environments with restricted outbound sending, so a notification that "doesn't arrive" in sandbox may be working perfectly — it just won't deliver externally the way production does.

Confirm: You're reproducing the issue in a sandbox or trial, not production. Fix: Validate notification behavior in production (on a safe test ticket to a real address you control). Use the Events log to confirm the trigger fired; that's the meaningful signal in a sandbox, not the inbox.

Prevention: notifications that stay reliable

• Treat notification triggers as critical infrastructure. Don't edit the standard ones in place — clone, edit the clone, deactivate the original, and name them clearly so the Events log reads like plain English.
• Never delete placeholders from a notification body. If you customize the wording, keep the comment placeholder (ticket.comments_formatted, in double curly braces) or the relevant one intact.
• Order deliberately: set values first, notify last, so an earlier trigger can't strip the conditions a notify trigger needs.
• Get email authentication right once: SPF, DKIM, and DMARC for your sending domain prevents the majority of "sent but never arrived" tickets.
• Test on a fresh ticket after every change, and skim the Events log for the Email notification entry to confirm it actually fired — to a real address, in production.
• Mind the public/internal toggle: the most frequent "the customer didn't get it" is an internal note that was never meant to notify.

For how notifications fit the wider model — tickets, comments, requesters, CCs, and business rules — see how the Zendesk ticketing system works.

Where AI fits in

Notification triggers are deterministic plumbing: if this exact event happens, send that email. They're great at it — and brittle in exactly the ways above, because they fire on conditions, not on whether the customer was actually helped. A perfectly-delivered "we received your request" email is still not an answer.

That's the layer an AI agent like Macha adds. To be clear about positioning: Macha isn't a help desk and it doesn't replace Zendesk — it runs on top of your existing Zendesk. Where a trigger can only acknowledge a ticket and route it, an AI agent reads the actual question, pulls from your knowledge base and past tickets, and can resolve it in the thread — then still handles the housekeeping (public reply, tagging, status, escalation with full context) that you'd otherwise wire up trigger by trigger. It's complementary: keep your notification triggers for deterministic acknowledgements and routing; let an AI agent handle the substantive replies.

The honest framing: it's another integration to configure, and it's only as good as the knowledge you connect. On cost, Macha bills per AI action — any automated step it takes, whether drafting a reply, tagging, or resolving — not per closed ticket, because most automation is work done along the way, not a tidy one-to-one "resolution." If you want to see it against your own ticket flow, 7-day free trial, no credit card required.

Frequently asked questions

Why are my Zendesk email notifications not working? Because in Zendesk, notifications are triggers — so "not sending" almost always means a notification trigger didn't fire or had nothing to send. Open the ticket's Events log (/events or Conversations → Events) and look for the Email notification entry. If it's missing, a trigger is deactivated, its conditions didn't match, the comment was internal, or the email body lost its placeholder. If it's present, the email was sent and you have a delivery problem (bounce, spam, blocklist) instead.

How do I check if Zendesk actually sent a notification? Open the ticket events and look for an Email notification property followed by an ID — click the ID to see the exact email and recipient. Per Zendesk, if that event doesn't exist in the log, no email was sent. That one check tells you whether to debug the trigger or the delivery.

Why isn't Zendesk sending emails to customers? Most often a notification trigger — Notify requester and CCs of received request or of comment update — is deactivated, or its email body lost a required placeholder (without a placeholder, "the message does not send"). Also check that the comment was a public reply, not an internal note, and that an earlier trigger didn't change the ticket so the notify trigger's conditions no longer match.

Why don't internal notes notify the customer? By design. Customer-notification triggers require a public comment. Internal notes are private comments meant only for agents, so they never email the requester. If the customer should see it, post it as a public reply.

Why is an agent not getting Zendesk notifications? The agent must be the assignee, a member of the assigned group, a CC, or a follower — and the matching Notify assignee/group trigger must be active. Also check that the agent didn't disable their own notifications in personal settings, and remember an agent who self-assigns isn't emailed about it.

It shows as sent in the events but the customer didn't get it — now what? That's a deliverability issue, not a Zendesk one. Have them check spam/junk, look for a delivery-failure banner on the comment, and confirm your domain has valid SPF, DKIM, and DMARC records so providers don't filter Zendesk's mail.

The bottom line

When Zendesk notifications aren't working, start from one fact: notifications are triggers. Read the ticket Events log and look for the Email notification entry — its presence or absence splits every problem cleanly. Absent means a trigger didn't fire: check whether a notification trigger is deactivated or lost its placeholder (the #1 cause), whether the comment was internal rather than public, whether trigger order changed the ticket first, or whether the agent simply isn't assigned/following. Present means Zendesk sent it and you have a delivery problem: a bounce, a blocklist, loop suppression, or — most often — missing SPF/DKIM/DMARC sending it to spam. Debug from the evidence, fix one cause at a time, and re-test on a fresh ticket to a real address in production.

Causes and fixes verified against Zendesk's official documentation, June 2026. Zendesk updates its product periodically — confirm trigger names and settings in your own account.