How Do You Send and Forward Email Into Zendesk? Setup Guide (2026)

To send email into Zendesk, email your default address ([email protected]), or connect your own address in Admin Center under Channels > Talk and email > Email and forward it to Zendesk at the server level. Then add Zendesk to your SPF record (include:mail.zendesk.com) and publish two DKIM CNAMEs so replies from your domain don't land in spam. Every step below links to Zendesk's help documentation, checked on 24 September 2026.

How does Zendesk turn 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: Where do you 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, and open Manage 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: How do you add your own 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. Click Manage support addresses, then Add address, then Connect external address.
3. Choose Email forwarding.
4. Enter the external address you want customers to use (for example, [email protected]) and save once forwarding is in place (Step 3).

Zendesk then runs a verification check (covered in Step 4).

One important rule: don't use a distribution group, Google Group, or email alias as your external support address. Zendesk's forwarding article warns that doing so "can cause issues with routing and troubleshooting." Use a single, dedicated mailbox that you control and can forward from at the server level.

Step 3: How do you forward email from Gmail or Outlook 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. Zendesk's instructions say to allow forwarding in Manage Remote Domains 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: How do you 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: Which SPF and DKIM records does Zendesk need?

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 or 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. Zendesk's example ends in -all (hardfail), which it recommends as "the greatest security against email spoofing"; ~all (softfail) is the gentler option if you aren't yet sure every sender for your domain is listed. Zendesk checks the SPF record automatically when you add a support address and has no manual verify button.

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 > Channels > Talk and email > Email > Custom domain for DKIM). Make it the last step: Zendesk warns that switching on signing before the DNS records exist causes delivery failures. Zendesk says DNS changes typically take anywhere from a few hours to a day, depending on the TTL set at your registrar; allow up to 48 hours before deciding something's broken.

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

Step 6: How do you 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.

What goes wrong most often?

• 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 warns 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.
• Enabling DKIM before the CNAMEs resolve. Zendesk warns this causes delivery failures. Publish the records, wait, then switch signing on.
• External auto-forwarding blocked in Microsoft 365. M365 blocks external auto-forwarding by default; allow it in Manage Remote Domains before setting up the forwarding rule.

What can an AI agent do 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. Macha bills per ticket, one charge per email thread however many replies it takes, from $299 a month for 750 tickets. If that's interesting once your email is live, you can start with $50 of free usage, 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. 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? Zendesk says typically a few hours to a day, depending on your TTL settings. Allow up to 48 hours before troubleshooting.

Should my SPF record end in -all or ~all? Zendesk recommends -all (hardfail) for the strongest protection against spoofing. Use ~all only while you're still confirming every service that sends mail for your domain is in the record.

What are the six steps, in short?

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 help documentation on 24 September 2026; Admin Center menus change occasionally, so confirm the exact labels in your account.