Zendesk Email Not Creating Tickets: Troubleshooting Guide

Every step below is checked against Zendesk's own documentation (June 2026). Zendesk revises its admin UI periodically, so confirm labels in your own account as you go.

Symptom: what "not creating tickets" actually looks like

Before you change anything, get specific about the symptom — it points straight at the cause:

• No ticket appears anywhere, including Suspended tickets → likely an upstream delivery or forwarding problem (the mail never reached Zendesk), or an unverified support address.
• Nothing in the agent's main views, but tickets sit in Suspended tickets → the mail arrived and Zendesk deliberately set it aside (spam, failed auth, no-reply, blocklist). This is the single most common real cause.
• Some senders work, others don't → authentication (SPF/DKIM/DMARC) or blocklist/allowlist rules hitting specific domains.
• Automated/system emails never come through (order confirmations, alerts, no-reply notices) → suspended by design.
• The ticket exists but is in the wrong place or closed → a trigger or wrong brand/support-address mapping, not a delivery failure at all.

Triage in 60 seconds

Do these three checks first — they resolve most cases before you touch DNS:

1. Open the Suspended tickets view. In Support, click Views in the sidebar, then Suspended tickets. If the missing emails are here, you've found your answer — jump to Cause 1.
2. Check the support address status. Go to Admin Center → Channels → Talk and email → Email. Under your support addresses, look for a green verified state. Anything showing forwarding check failed or an unverified warning is your problem — jump to Cause 2.
3. Send a controlled test. From a normal external mailbox (a personal Gmail, not a no-reply system), email your support address with a plain-text subject and body. Watch where it lands: a main view, Suspended tickets, or nowhere. That single test eliminates half the possibilities.

The causes, ranked by likelihood

Cause 1 — The email arrived but landed in Suspended Tickets (most common)

This is the answer far more often than people expect. Zendesk has a filter that intercepts mail it judges to be spam, automated, or improperly authenticated and routes it to the Suspended tickets view instead of creating a normal ticket. The mail is in Zendesk — it just isn't where agents look.

Confirm: Open Views → Suspended tickets. Each row shows a Cause column explaining why it was held — per Zendesk's causes list, common labels include "Detected as spam", "Failed email authentication", "Email for 'noreply' address", and "Sender or domain is on the blocklist". Read the cause before you do anything — it tells you which of the causes below to fix permanently.

Fix (recover the held mail): Select the legitimate suspended tickets, then use the Recover action — the dropdown offers Recover manually, Auto recover, or Delete permanently (recovery docs). Recovering turns the email into a real ticket. Two things to know: suspended tickets auto-delete after 14 days, so check this view on a schedule, and a recovered ticket's creation date reflects when you recovered it, not when the email originally arrived — relevant if you track first-response SLAs.

Recovery clears the backlog; the causes below stop it from happening again.

Cause 2 — Support address not verified / forwarding never completed

When you connect an external address (e.g. [email protected]) to Zendesk, the address must be verified before mail flows reliably. A half-finished setup is a classic "no tickets at all" cause.

Confirm: In Admin Center → Channels → Talk and email → Email → Manage support addresses, check the address state. A red "Forwarding check failed" or unverified status means Zendesk isn't confident your forwarding is wired correctly (why isn't my address verified).

Fix: Use the options menu next to the address and select Verify forwarding to re-run the test. The flow to (re)connect is Add address → Connect external address → Email forwarding, then enter your external address and save. One trap that catches many teams: the verification email Zendesk sends can itself get suspended, because it can be detected as coming from a no-reply or system user (verification email not received). If verification "never arrives," check Suspended tickets for it first.

Cause 3 — Forwarding misconfigured in Gmail/Workspace or Microsoft 365

If the address is verified but mail still doesn't arrive, the forwarding rule in your mail provider is the suspect. Zendesk relies on your provider forwarding inbound mail to your Zendesk address.

Confirm: Send a test directly to your original mailbox (e.g. [email protected]) and watch whether it forwards. If it lands in your inbox but never reaches Zendesk, forwarding is the break.

Fix:

• Google Workspace / Gmail: set up forwarding at the admin/server level (routing rules) rather than a personal client filter, which is fragile and can strip headers. Our companion guide on connecting Gmail and Outlook to Zendesk walks the exact flow.
• Microsoft 365 / Outlook: Microsoft blocks external auto-forwarding by default via its outbound anti-spam policy. You must explicitly allow it — in the Microsoft 365 admin, enable forwarding (e.g. via Manage Remote Domains / the outbound spam filter policy) for the Zendesk destination (Zendesk forwarding doc). Until you do, M365 silently drops the forward and you'll see nothing in Zendesk — not even a suspended ticket.

Always forward at the server level, not via a client-side rule; client rules can strip the headers Zendesk needs and break verification.

Cause 4 — SPF / DKIM / DMARC failures

Email authentication protects your domain from spoofing — but a misconfigured record will cause Zendesk to suspend or reject legitimate mail, especially forwarded mail (forwarding often breaks SPF/DKIM alignment).

Confirm: In Suspended tickets, look for causes like "Failed email authentication" or "Email authentication failed" (a DMARC failure). On the address itself, an SPF record check error can appear even when forwarding works (fixing email/SPF/DNS errors).

Fix: Add Zendesk to your domain's SPF record (so Zendesk is authorized to send as your domain), confirm DKIM is set up, and make sure your DMARC policy isn't rejecting forwarded mail. Zendesk's verify forwarding, SPF, DNS, and TXT guide lists the exact records. This is the usual explanation when some senders/domains work and others fail.

Cause 5 — Sender on a blocklist (or blocked by allowlist rules)

Zendesk can suspend mail from addresses or domains you've blocklisted — or, if you run an allowlist, suspend everything not on it.

Confirm: Suspended-ticket causes "Sender or domain is on the blocklist" or "Sender domain not on allowlist" point here.

Fix: In Admin Center → People → Configuration → End users (or your account's allowlist/blocklist settings), review the lists. Remove legitimate senders from the blocklist, or add the needed domains to your allowlist. Be deliberate — an overly aggressive allowlist quietly suspends every new customer who hasn't been pre-approved.

Cause 6 — Automated emails are suspended by design

No-reply addresses, auto-responders, out-of-office replies, and notification systems are intercepted on purpose to prevent loops and spam tickets.

Confirm: Causes like "Automated response mail", "Email for 'noreply' address", or "Detected email as being from a system user" (mail-daemon/postmaster) tell you the suspension was intentional.

Fix: If you genuinely need a specific automated sender to create tickets, you can recover those individually and/or add the sender to your allowlist so future mail isn't held. Don't blanket-disable suspension for automated mail — that's what invites mail loops.

Cause 7 — A trigger routed or closed the ticket (it only looks missing)

Sometimes the ticket was created perfectly — and then a trigger immediately routed it to a group, solved it, or set it pending, so it never showed in the view the agent was watching.

Confirm: Search all tickets (not just your view) for the sender's address. If the ticket exists but is solved/closed or assigned elsewhere, a business rule did it.

Fix: In Admin Center → Objects and rules → Business rules → Triggers, review triggers that fire on ticket creation — look for ones that auto-solve, set assignee/group, or add tags based on the inbound address. Adjust the conditions so legitimate inbound email isn't auto-closed. If you're new to how tickets are meant to flow, our Zendesk ticketing system explained primer is a useful baseline.

Cause 8 — Wrong support address or brand mapping

On multi-brand accounts, mail to an address that isn't mapped to the right brand (or isn't added as a support address at all) won't create tickets where you expect.

Confirm: In Manage support addresses, verify the address customers actually email is listed and mapped to the correct brand.

Fix: Add any missing support address and assign it to the right brand. Then re-test from that exact address.

Cause 9 — Email loops and bounces

If your support address forwards to an address that forwards back, or a notification triggers a reply that triggers another notification, Zendesk suspends the mail to stop a loop.

Confirm: Causes "Detected as email loop" or "Received from support address" indicate a loop.

Fix: Untangle the forwarding chain so your support address forwards only to Zendesk, and ensure no auto-responder replies to Zendesk's own notifications.

Prevention: keep email tickets flowing

• Check Suspended tickets on a schedule (daily, or set up reporting) — it auto-purges after 14 days, so real customer emails can vanish unrecovered.
• Verify support addresses fully at setup, and re-verify after any DNS or mail-provider change.
• Forward at the server level, never with a client-side filter.
• Get SPF, DKIM, and DMARC right once — most "some emails work, some don't" tickets are authentication.
• Audit allowlist/blocklist and creation-time triggers quarterly so they don't silently swallow new senders.
• Send a periodic test from an external mailbox to confirm the whole path end to end.

Where AI fits in

Once email reliably becomes tickets again, the next problem is the volume — and that's a different kind of fix. An AI agent like Macha isn't a help desk and it doesn't replace Zendesk; it runs on top of your existing Zendesk so the tickets that now flow in get handled faster. Once an email becomes a ticket, an AI agent can triage it (read the message, tag it, set priority, route to the right group) and draft or send a reply from your connected knowledge base and past tickets — escalating to a human, with context attached, when it isn't confident.

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 — each automated step it takes, like drafting a reply, tagging, or routing — not per resolved ticket, because most of the value is the work done along the way, not a tidy "resolution." If you want to see it on your own Zendesk, you can explore Macha on Zendesk or try it free — 7-day free trial, no credit card required.

Frequently asked questions

Why is my Zendesk email not creating tickets? Most often the email did arrive but was set aside in the Suspended tickets view (spam, failed authentication, a no-reply sender, or a blocklist match). If nothing appears there either, the cause is usually upstream: an unverified support address or broken forwarding from Gmail/Workspace or Microsoft 365. Start by checking Suspended tickets, then the support address status in Admin Center.

Where do suspended tickets go in Zendesk, and how do I recover them? In Support, click Views → Suspended tickets. Select the legitimate ones and use Recover (Recover manually or Auto recover) to turn them into normal tickets. Note they auto-delete after 14 days, and a recovered ticket's creation date reflects the recovery time, not the original send time.

My support address shows "forwarding check failed" — what do I do? Re-run Verify forwarding from the address's options menu in Admin Center → Channels → Talk and email → Email. Confirm forwarding is set at the server level, and check whether your verification email got suspended (it can be detected as a no-reply/system message). For Microsoft 365, also confirm external forwarding is allowed in your outbound anti-spam/remote-domain settings.

Why do some senders create tickets but others don't? That pattern almost always points to SPF/DKIM/DMARC authentication or an allowlist/blocklist rule hitting specific domains. Check the suspension cause for "Failed email authentication," "Sender or domain is on the blocklist," or "Sender domain not on allowlist," then fix the relevant DNS record or list.

Why don't automated emails (no-reply, order confirmations) create tickets? Zendesk suspends them on purpose to prevent mail loops and spam — causes like "Automated response mail," "Email for 'noreply' address," or "from a system user." If you truly need a specific automated sender to create tickets, recover those messages and add the sender to your allowlist.

Does Microsoft 365 block forwarding to Zendesk? Yes — Microsoft 365 blocks external auto-forwarding by default. You must explicitly allow forwarding to your Zendesk address in the M365 admin (outbound spam policy / remote domains) before mail will reach Zendesk.

The bottom line

When Zendesk email isn't creating tickets, resist the urge to assume the channel is down. Triage first: check Suspended tickets, check the support address verification status, and send a controlled test. Those three steps resolve the majority of cases. From there, work the ranked causes — suspended mail (by far the most common), unverified addresses, broken Gmail/M365 forwarding, SPF/DKIM/DMARC failures, blocklists, intentionally suspended automated mail, and the occasional trigger or brand-mapping quirk that only looks like a missing ticket. Recover what's stuck, fix the root cause so it stops recurring, and put Suspended tickets on a recurring check so real customer emails never quietly expire.

Causes and fixes verified against Zendesk's official documentation, June 2026. Zendesk updates its product periodically — confirm labels in your own account before relying on them.