How Do You Connect Gmail or Outlook to Zendesk? Step by Step (2026)

To connect Gmail or Outlook to Zendesk, add your address in Admin Center > Channels > Talk and email > Email > Manage support addresses > Add address > Connect external address, then either forward your mailbox to [email protected] or sign in through the Gmail or Microsoft Exchange connector so Zendesk pulls unread mail into tickets every minute or so. Zendesk doesn't "log into" your mailbox by default: every account ships with that hosted support address, and any message sent there becomes a ticket (Zendesk: adding support addresses). Your own address ([email protected]) connects as an external support address by forwarding or by connector, and SPF, DKIM and DMARC records keep replies out of spam.

Should you use forwarding or a connector?

Before clicking anything, pick your method. They get email into Zendesk differently, and the choice affects deliverability, attachments, and how much DNS work you do.

The short version: forwarding is the more robust path for most teams, because it has no mailbox rate limits and lets you authenticate outbound mail with SPF and DKIM. Connectors are handy when you specifically want outbound mail to keep flowing through your existing mailbox. Forwarding comes first below, then the connectors.

Every Zendesk step below was checked against Zendesk's documentation on 24 September 2026. The Gmail and Outlook screens are described from Google's and Microsoft's docs, so confirm exact labels in your own admin console, since both vendors reshuffle their settings regularly.

What do you need before you start?

• Zendesk admin access. Adding support addresses lives in Admin Center, which requires an admin role. Both connectors are available on every Suite plan (Team through Enterprise Plus) and Support Team, Professional and Enterprise.
• Admin access to your email provider. For Google Workspace you need the Google Admin console; for Microsoft 365 you need the Exchange admin center. Personal/single-mailbox forwarding can be done from the mailbox itself, but org-wide setups need admin rights.
• Access to your DNS. SPF, DKIM, and DMARC records live in your domain's DNS zone (GoDaddy, Cloudflare, Route 53, etc.). Line this up early.
• A decision: forwarding or connector (see the table above).

Once email lands in Zendesk it becomes a ticket like any other, with the same statuses, macros, triggers and routing. If that model is new to you, our Zendesk ticketing system explainer covers what a ticket actually is before you start feeding it email.

How do you set up email forwarding to Zendesk?

Forwarding is two halves: tell Zendesk about your address, then tell your mailbox to forward to Zendesk. Order matters less than getting both done before you verify.

Step 1: Add your external address in Zendesk

1. In Admin Center, click Channels in the sidebar, then select Talk and email > Email.
2. Click Manage support addresses.
3. Click Add address, then choose Connect external address.
4. Select your brand (if you run more than one), choose Email forwarding, and click Next.

This is also where you'd click Create new Zendesk address if you just want a hosted variant like [email protected] . The noreply string is reserved and can't be used. But for connecting a real domain address, Connect external address is the path.

Step 2: Set up forwarding at your provider

Now point your mailbox at the Zendesk address. The destination is your default Zendesk address — [email protected] — unless you've configured a different one.

Critical rule: set forwarding up at the server/admin level, not as a client-side rule that re-sends each message. If you manually forward (or auto-forward from a desktop client) a message that originated from an external address, Zendesk sees the wrong sender and the ticket lands in Suspended instead of your queue. Zendesk also doesn't support multi-hop forwarding — mail that passes through several addresses before reaching Zendesk (Zendesk: forwarding from your existing email address).

Gmail (single personal mailbox): open Gmail Settings > See all settings > Forwarding and POP/IMAP, click Add a forwarding address, enter your Zendesk address, and confirm. (Google sends a confirmation code to that address — it'll surface in Zendesk as a suspended ticket you can open to grab the code.)

Google Workspace (org-wide, recommended): in the Google Admin console go to Apps > Google Workspace > Gmail > Default routing, click Add setting, choose Single recipient and enter the address you use as your support address. Under the action, choose Change envelope recipient and set it to your Zendesk address, e.g. [email protected]. Save. This server-side route is Zendesk's recommended Workspace setup (Zendesk: forwarding Gmail/Google Workspace email).

Outlook / Microsoft 365 (org-wide, recommended): in the Exchange admin center, open the mailbox (or shared mailbox), go to Mailbox features, and set up forwarding to your Zendesk address. One gotcha that trips up almost everyone: Microsoft 365 blocks automatic external forwarding by default. You (or your M365 admin) must first allow it in the anti-spam outbound policy / Manage remote domains, or forwarding silently fails and you'll hit an "access denied" error (Zendesk: access-denied error in Office 365; Microsoft: control automatic external email forwarding). Described from Microsoft's docs — confirm the exact panel in your tenant.

Step 3: Enter and verify the forwarding address

Back in Zendesk, in the Enter forwarding address field, type your external address ([email protected]) and click Save. Then click the options menu (•••) next to that address and choose Verify forwarding. Zendesk sends a test message through the forwarding path; when it arrives, the address shows as verified (Zendesk forwarding docs). If verification fails, the usual causes are a forwarding rule that isn't active yet or M365's external-forwarding block from Step 2.

How do you connect Gmail or Outlook with a connector instead?

Connectors skip forwarding entirely: Zendesk authenticates into your mailbox via OAuth and pulls mail out. The path starts the same — Admin Center > Channels > Talk and email > Email > Manage support addresses > Add address > Connect external address — then you pick a connector instead of "Email forwarding."

Option A: Gmail connector

1. From Connect external address, select your brand, then choose Gmail connector.
2. Decide on backfill: there's a Create tickets from last 300 emails option — deselect it if you only want new, unread messages turned into tickets.
3. Click Next, sign in to the Gmail account, and grant the requested permission: Read, compose, and send emails from your Gmail account.

Once connected, Zendesk checks the inbox roughly every minute and converts new, unread inbox messages into tickets, tagging each imported message with a Zendesk label in Gmail. You can connect multiple Gmail accounts, each added as its own support address (Zendesk: Gmail connector).

There's an optional Send email via Gmail toggle: with it on, ticket notifications go out from your Gmail account rather than Zendesk's servers — but you still need SPF/DKIM set up to authorize it, and Gmail-sent notifications can't carry real attachments. Google caps sending at 500 messages a day for a Gmail account and 2,000 for Google Workspace, so heavy senders should keep outbound on Zendesk's servers with SPF instead.

Option B: Microsoft Exchange connector (Outlook / Microsoft 365)

For Outlook/365, the equivalent is the Microsoft Exchange connector, which uses the Microsoft Graph API with OAuth. During sign-in, Zendesk requests scopes including Mail.Send, Mail.ReadWrite, and User.Read, and an Exchange admin must consent to the connection; whoever authorizes must be able to sign in as the mailbox account. Zendesk then fetches new, unread inbox messages into tickets (labeling them Zendesk, or RejectedByZendesk on failure), and outbound ticket notifications are sent from your Microsoft email address (Zendesk: Microsoft Exchange connector).

Two things to weigh before choosing this over forwarding:

• It's Exchange Online only. On-premises Exchange Server isn't supported.
• Personalized email replies don't work through it, a Microsoft API constraint; the mailbox's configured sender name appears instead.
• Rate limits per mailbox: sending 30 emails a minute and 50 MB per 5 minutes; receiving 25 emails a minute; 50 MB max per email.
• A daily recipient cap: 10,000 different recipients per 24 hours per mailbox, which Microsoft is cutting to 2,000 for existing customers starting in October 2026.

Earlier versions of this guide also listed side conversations as unsupported. Zendesk's connector article no longer says that (checked 24 September 2026). The recipient cap is the new constraint to plan around: a support mailbox answering more than 2,000 distinct customers a day will hit it after October. If that's you, or personalized replies matter, use forwarding for Outlook/365 instead, which sidesteps both.

How do you make Zendesk replies come from your domain?

By default, Zendesk sends outbound replies from its own servers, and recipients may see a "via zendesk.com" note next to your address (or worse, replies get filtered to spam). Domain authentication fixes both. Three records, in your DNS:

• SPF authorizes Zendesk to send on your behalf. Add Zendesk to your domain's SPF TXT record with include:mail.zendesk.com (Zendesk's suggested record is v=spf1 include:mail.zendesk.com -all) (if you also send via Google, keep include:_spf.google.com). A domain can only have one SPF record, so merge, don't duplicate (Zendesk: allowing Zendesk to send on behalf of your domain).
• DKIM digitally signs your outbound mail so receivers can verify it. Add the CNAME record(s) Zendesk provides to your DNS, then in Zendesk go to the email settings, find Custom domain for DKIM, click Enable, and Save (Zendesk: digitally signing email with DKIM). Note: digital signing is only available when you're using an external email domain.
• DMARC tells receivers what to do with mail that fails SPF/DKIM. Once SPF and DKIM pass, a p=none DMARC policy to start (monitoring) is sensible before tightening (Zendesk: authenticating incoming email — SPF, DKIM, DMARC, ARC).

The payoff: with domain authentication in place, the "via zendesk.com" label disappears and replies look like they come straight from your brand. DNS changes can take a few hours to propagate, so set these up before your go-live announcement, not during it.

How do you test that the connection works?

Don't trust the config screens. Run the full loop:

1. Inbound: from an outside account (your personal Gmail, a phone), email your support address. Within a minute or two it should appear as a new ticket in Zendesk. If it lands in Suspended, check Step 2; that's the classic symptom of client-side or multi-hop forwarding.
2. Outbound: reply to that ticket from Zendesk. Confirm the customer receives it, that the From shows your domain (not @zendesk.com), and that there's no "via zendesk.com" once DNS has propagated.
3. Threading: reply back as the customer and confirm it threads onto the same ticket rather than opening a new one.
4. Attachments: if you rely on attachments, send one in — especially worth testing if you used the Gmail "Send email via Gmail" option, which doesn't carry real attachments.

Where do these tickets actually live for your team? In the Zendesk Agent Workspace, alongside any chat, messaging, and phone tickets — one queue, not a separate inbox.

Is the Gmail contextual app the same as connecting Gmail?

Worth clearing up because it's a common mix-up: Zendesk also offers a Gmail contextual add-on (sometimes called Zendesk Support for Gmail) that puts a Zendesk sidebar inside Gmail so an agent can see ticket context while reading mail. That's a convenience layer for agents who live in Gmail — it does not convert email into tickets. If your goal is "email becomes tickets," you want a support address (Method 1 or 2 above), not the contextual app.

Should you connect a shared mailbox or an agent's own inbox?

One design decision worth making deliberately: connect your shared support mailbox (support@, help@, billing@), not an individual agent's personal inbox. Tickets routed off a personal mailbox break the moment that person is out, leaves, or changes roles — and you'll be re-authorizing connectors and rebuilding forwarding rules under pressure. A shared address keeps ownership with the team, survives staff changes, and is what Zendesk's routing, triggers, and SLAs are built around. Use a connector on a personal mailbox only for a genuinely personal queue, never as your front door.

What happens to the email volume once it's in Zendesk?

Once email is flowing in as tickets, you've solved intake — but not volume. A connected support@ inbox can turn into hundreds of tickets a day, and most of them are the same handful of questions: order status, password resets, "how do I…" If a human reads and types every one, you've just moved the shared-inbox grind into Zendesk.

That's the gap an AI agent layer like Macha is built for. Macha isn't a help desk and it doesn't replace Zendesk. It runs on top of your Zendesk (see Macha on Zendesk). Once your Gmail or Outlook email lands as tickets, Macha can read each one, triage and tag it, draft (or send) a reply pulled from your knowledge base and past tickets, and escalate the genuinely tricky ones to a human with context attached, on the email volume you just connected.

The fair framing: it's another integration to set up, and it's only as good as the knowledge you connect to it. On cost, Macha bills per ticket, from $299 a month for up to 750 tickets with setup and monitoring by the Macha team included. One conversation is charged once however much tagging, drafting and replying it takes, never per "resolution," because a resolution is an outcome definition you don't control and a ticket is something you can count. If your newly connected inbox is mostly repetitive questions, that's exactly where it earns its keep. You can try it free with $50 of usage and no credit card.

What are the most common setup mistakes?

• Forward at the server, never the client. Client-side or auto-forward rules on individual messages create suspended tickets. Use Google Workspace default routing or the M365 Exchange admin center.
• Unblock external forwarding in Microsoft 365 first. It's off by default; forwarding fails silently until you allow it in the outbound anti-spam policy / remote domains.
• Do the DNS work. Without SPF and DKIM, replies show "via zendesk.com" and risk spam folders. It's an hour of setup that pays off forever.
• Connect the shared mailbox, not a person's inbox. Future-proofs routing and ownership.
• Pick forwarding for Outlook if you need personalized replies or high recipient volume. The Microsoft Exchange connector doesn't support personalized replies, and its daily recipient cap drops to 2,000 in October 2026.
• Always test the full loop. Inbound, outbound, threading and attachments, from a real outside account, not the Zendesk preview.

Frequently asked questions

How do I connect Gmail to Zendesk? Two ways. Forwarding: in Admin Center > Channels > Talk and email > Email > Manage support addresses > Add address > Connect external address > Email forwarding, then forward your Gmail/Google Workspace mail to [email protected] and click Verify forwarding. Connector: same path, but choose Gmail connector and sign in with Google via OAuth so Zendesk pulls unread inbox mail into tickets. Forwarding is the recommended default for most teams.

How do I connect Outlook or Microsoft 365 to Zendesk? Either forward your Outlook/365 mailbox to your Zendesk support address (via the Exchange admin center, after allowing external forwarding, which M365 blocks by default), or use the Microsoft Exchange connector (Connect external address, OAuth via Microsoft Graph, admin consent required). The connector is Exchange Online only, doesn't support personalized replies, and sends at most 30 emails a minute per mailbox, so many teams forward instead.

What's the difference between forwarding and the connector? Forwarding auto-sends your mail to a Zendesk address; the connector logs into your mailbox via OAuth and pulls mail out. Forwarding is more robust and lets you authenticate outbound with SPF/DKIM. Connectors keep outbound sending inside your Gmail/365 mailbox but add rate limits and (for Microsoft) some unsupported features.

Why do my Zendesk replies say "via zendesk.com"? Because your domain isn't authenticated yet. Add an SPF record (include:mail.zendesk.com) and enable DKIM (add the CNAME records, then turn on Custom domain for DKIM in Zendesk). Once verified, the "via" label disappears and replies appear to come from your domain.

Why did my forwarded email land in Suspended tickets? Usually because the mail was forwarded from a client/desktop rule or passed through multiple addresses (multi-hop). Set forwarding at the server/admin level instead. Verification emails and confirmation codes also intentionally land in Suspended ; open the ticket to retrieve them.

Is the Gmail contextual app the same as connecting email? No. The Gmail contextual add-on shows Zendesk ticket context inside the Gmail sidebar for agents. It doesn't turn email into tickets. To convert email to tickets, use a support address with forwarding or a connector.

Which setup should most teams choose?

Most teams should use server-side forwarding from a shared mailbox, plus SPF and DKIM on their domain: it has no mailbox rate limits, keeps attachments real, and removes the "via zendesk.com" label. Choose the Gmail connector if you want outbound mail to stay in Gmail and send fewer than 2,000 messages a day. Choose the Microsoft Exchange connector only on Exchange Online, when you can live without personalized replies and stay under the recipient cap. Whichever you pick, test inbound, outbound and threading from an outside account before go-live. Once email is flowing in as tickets, it's another channel in your Agent Workspace and a candidate for AI-assisted triage and replies.

Zendesk setup steps and connector limits checked against Zendesk's documentation on 24 September 2026; Gmail and Outlook admin screens described from Google's and Microsoft's docs. All three vendors update their UIs periodically, so confirm labels in your own consoles.