How to Send & Forward Email Into Zendesk: Complete Setup Guide (2026)

This guide walks through the whole thing, step by step, for 2026: how Zendesk turns email into tickets, your default support address, adding and verifying an external address on your own domain, forwarding from Gmail / Google Workspace and Outlook / Microsoft 365, and the SPF and DKIM DNS records that keep your mail out of the spam folder. Every step is checked against Zendesk's current help documentation, linked throughout so you can confirm in your own account.

How Zendesk turns email into tickets

Zendesk is, at its core, an email engine. Every Zendesk account has at least one support address — an email address Zendesk monitors. When a message arrives at a support address, Zendesk creates a ticket from it: the sender becomes the requester, the subject becomes the ticket subject, and the body becomes the first comment. Replies your agents write are emailed back to the customer, and when the customer replies again, that reply threads onto the same ticket instead of opening a new one.

There are two kinds of support address:

• The default Zendesk address — created automatically, ends in @yoursubdomain.zendesk.com. Works instantly, but it's not your brand.
• An external address — your own [email protected], connected to Zendesk via forwarding. This is what almost every real deployment uses.

The rest of this guide is about getting from the first to the second cleanly.

Step 1: Find your default support address

When you create a Zendesk account, Zendesk automatically generates a default support address in the form [email protected] (replace yoursubdomain with the subdomain you chose at signup). You can email it right now and it will create a ticket — it's the simplest way to confirm the ticketing engine works before you layer your own domain on top.

To see it: in Admin Center, click Channels in the sidebar, then Talk and email > Email. Your support addresses are listed under Support addresses. The default one is there from day one and can't be deleted.

It's fine for testing, but you don't want customers seeing a .zendesk.com address — so the next step is connecting your real one.

Step 2: Add your external support address in Zendesk

Connecting your own address is a two-part job: tell Zendesk about the address, then set up forwarding in your mail provider so messages actually reach Zendesk. Do the Zendesk side first.

1. In Admin Center, go to Channels > Talk and email > Email.
2. Under Support addresses, click Add address, then Connect external address.
3. Enter the external address you want customers to use (for example, [email protected]).
4. Choose Email forwarding, then click Next.

Zendesk will now wait for you to set up forwarding and will run a verification check (covered in Step 4).

One important rule: don't use a distribution list, Google Group, or email alias as your external support address. Zendesk specifically warns against it — aliases and groups cause routing and troubleshooting problems. Use a single, dedicated mailbox that you control and can forward from at the server level.

Step 3: Forward email from your provider to Zendesk

This is the part you do outside Zendesk, in your email provider. The golden rule across every provider: forward at the server level, not from a desktop client. If you set up auto-forwarding inside the Outlook or Gmail desktop app (rather than in the admin/server settings), Zendesk will treat the forwarded mail as coming from you rather than the original customer — and the ticket gets suspended. Server-level forwarding preserves the original sender so the ticket is created against the real customer.

Gmail / Google Workspace

You have two options:

• Single mailbox (Gmail): Open Gmail Settings > See all settings > Forwarding and POP/IMAP, click Add a forwarding address, and enter your Zendesk address (your default [email protected] or the external address you're routing through). Gmail sends a confirmation request — that confirmation arrives in Zendesk as a ticket, so you'll grab the confirmation link from there.
• Whole domain (Google Workspace admin): For org-wide control, use routing rules in the Google Admin console (Apps > Google Workspace > Gmail > Routing) to forward mail for your support address to Zendesk. This is the recommended approach for teams because it runs at the server level and doesn't depend on any one user's settings.

Outlook / Microsoft 365

Use the Exchange admin center, not the Outlook desktop client:

• Mail flow rule: In the Exchange admin center, go to Mail flow > Rules, create a new rule, and redirect/forward messages sent to your support mailbox to your Zendesk address.
• Mailbox forwarding: Alternatively, select the mailbox in the Exchange admin center and enable forwarding under the mailbox's mail flow / forwarding settings. You may need to allow automatic forwarding to external domains in your remote-domain settings first, since Microsoft 365 blocks external auto-forwarding by default.

Either way, the requirement is the same: forwarding happens on the server so the customer's original address is preserved.

Step 4: Verify forwarding

Once forwarding is configured, Zendesk needs to confirm mail is actually reaching it. Zendesk sends a verification (test) email through your forwarding path. Because that email originates from an external address, it usually arrives as a ticket — and it's often suspended, so check your Suspended tickets view if you don't see it in your main views.

To complete verification:

• In the newer Admin Center, open the options menu next to the support address you added and click Verify forwarding. Zendesk checks that its test message made the round trip.
• If your mail provider also sent its own confirmation email (Gmail does this when you add a forwarding address), find that ticket and click the confirmation link inside it.

When verification passes, the address shows as verified and is ready to use. If it fails, forwarding isn't working — re-check Step 3.

Step 5: Authenticate your email with SPF and DKIM

Forwarding gets email into Zendesk. SPF and DKIM make sure the replies Zendesk sends out on your behalf actually land in customers' inboxes instead of spam or a "via zendesk.com" warning. These are DNS records you add at your domain registrar / DNS host — outside Zendesk. Loop in whoever manages your DNS.

SPF tells receiving mail servers that Zendesk is allowed to send on behalf of your domain. Add (or merge into your existing) SPF TXT record so it includes Zendesk:

v=spf1 include:mail.zendesk.com ~all

You can only have one SPF record per domain — if you already have one (for Google Workspace or Microsoft 365), add include:mail.zendesk.com to it rather than creating a second record. The closing qualifier (~all softfail vs. -all hardfail) depends on how strict your domain policy is; confirm the value Zendesk recommends in your account before you tighten it.

DKIM cryptographically signs your outbound mail. Zendesk uses two CNAME records (it rotates keys for security):

After the CNAMEs are live, enable DKIM signing inside Zendesk (Admin Center > the email settings for your domain). DNS changes can take anywhere from a few minutes to 48 hours to propagate, though most hosts update within 1–4 hours, so don't panic if it isn't instant.

(If you run DMARC, authenticated SPF + DKIM are what let your support mail pass it — worth confirming once both are live.)

Step 6: Test the full round trip

Before you point customers at the address, test it end to end from an outside account (a personal Gmail works well):

1. Send a fresh email to [email protected].
2. Confirm a ticket appears in Zendesk with you as the requester.
3. Reply from inside the ticket and confirm the response lands in your test inbox — sent from your address, not a .zendesk.com one.
4. Reply to that response and confirm it threads onto the same ticket instead of opening a new one.

If all four work, you're live.

Common pitfalls

• Suspended tickets from client-side forwarding. The most common failure: forwarding set up in a desktop mail app instead of at the server. Move it to server-level forwarding (Google Admin console routing / Exchange mail flow).
• Using an alias or distribution group. Zendesk explicitly advises against it. Use a dedicated, controllable mailbox.
• Verification email never arrives as a ticket. Forwarding isn't actually working — check for typos in the forwarding target and confirm forwarding is enabled and confirmed in your provider. Check the Suspended tickets view too.
• Two SPF records. Only one SPF TXT record is valid per domain. Merge Zendesk's include into the existing record.
• Expecting DNS to be instant. Allow up to 48 hours for SPF/DKIM to propagate before concluding something's wrong.
• External auto-forwarding blocked in Microsoft 365. M365 blocks external auto-forwarding by default; enable it for your support mailbox in the remote-domain settings.

Where an AI agent fits — once email is flowing

Getting email into Zendesk is the plumbing. The next question is what happens to those tickets. Once your inbox is reliably creating tickets, an AI agent layer that runs on top of Zendesk — like Macha — can triage incoming email, tag and route it, and draft (or send) first replies grounded in your help center and past tickets, so routine email questions get answered without a human touching them and the rest reach an agent already sorted. Macha plugs into your existing Zendesk setup rather than replacing it, so the forwarding and authentication work you just did stays exactly as is. If that's interesting once your email is live, you can 7-day free trial, no credit card required.

FAQ

What's the difference between a default and an external support address? The default address ([email protected]) is created automatically and works instantly but shows the Zendesk domain. An external address is your own ([email protected]), connected via forwarding, so customers only ever see your brand.

Why is my forwarded email creating a suspended ticket? Almost always because mail is being forwarded from a desktop email client instead of at the server level, which makes Zendesk see you as the sender. Set up forwarding in the Google Admin console (routing) or Exchange admin center (mail flow) instead, and it will preserve the original customer as the requester.

Do I really need SPF and DKIM? For testing, no — but for production, yes. Without them, the replies Zendesk sends on your behalf are far more likely to hit spam or show a "via zendesk.com" notice. SPF authorizes Zendesk to send for your domain; DKIM signs the messages.

Can I use a distribution list or alias as my Zendesk support address? No. Zendesk advises against distribution groups, Google Groups, and aliases because they cause routing and troubleshooting issues. Use a single dedicated mailbox you can forward from.

How long do the DNS changes take? SPF and DKIM DNS changes can take up to 48 hours to propagate, though most DNS hosts update within 1–4 hours.

The bottom line

Getting email into Zendesk comes down to six moves: know your default address, add your external address in Admin Center, forward to it at the server level, verify the forwarding, authenticate with SPF + DKIM, then test the full round trip. The two mistakes that trip up most teams are forwarding from a desktop client (which suspends tickets) and skipping email authentication (which sends replies to spam) — get those right and customers email your address, get a real ticket, and get an on-brand reply. From there, layering an AI agent on top to triage and draft responses is the natural next step.

Setup paths and DNS values were verified against Zendesk's current help documentation in June 2026; Admin Center menus change occasionally, so confirm the exact labels in your account.