Inbound Email Setup

The inbound email setup wizard lets you point your customer-facing support email (e.g., support@msp.com) at concorbit so support tickets and replies thread inside concorbit instead of being delivered into your old PSA.

This is the "swap" you do when you want concorbit to own customer email, typically before flipping the Customer reply email source toggle on the Autotask connection page from "Autotask sends" to "concorbit sends".

URL: /settings/email/inbound
Required permission: settings.tenant

Why You'd Do This

concorbit's helpdesk module already accepts inbound email at a workspace-specific address (support@yourslug.in.concorbit.com). The inbound setup wizard adds two things on top of that:

• A way to declare the customer-facing addresses you actually receive support email at (support@msp.com, helpdesk@msp.com, etc) so concorbit can verify routing is in place.

• A guided routing setup with two paths (forwarding rule or direct MX delegation) and a test-email verification step.

Once routing is verified, concorbit's reply emails (e.g., from time entries) can safely use a concorbit reply-to address: customer replies will land back into concorbit and thread into the originating ticket. Without verification, those replies have nowhere to land.

Accessing the Wizard

You can reach the wizard from two places:

• Open Settings → SMTP and click Set up on the Inbound email card.

• Or go directly to /settings/email/inbound.

The page shows a status banner at the top: Not configured (you haven't started), Awaiting verification (declared addresses but no test email landed yet), or Verified (a test email from a declared address arrived in the last 5 minutes).

Step 1: Declare Your Sending Addresses

Enter the customer-facing addresses you will be receiving support email at, separated by commas:

support@msp.com, helpdesk@msp.com

concorbit normalises these on save (lowercase, trimmed, deduplicated). Most tenants only need 1 to 2 entries.

These addresses are used for two things:

1. To verify routing is working: the test-email step in Step 3 looks for a recent inbound message from one of these sender domains.

2. As a record of which addresses are "yours" for ticket attribution.

Step 2: Route Mail to concorbit

Pick one of the two paths. You can do this in either order with Step 1, but until both are done, verification will fail.

Forwarding Rule (Recommended)

Keep your existing MX records and inbox. Add a server-side forwarding rule from your support address to your concorbit inbound address.

Where to set this up depends on your mail provider:

• Microsoft 365: Exchange admin → Mail flow → Rules → New rule → "redirect the message to..."

• Google Workspace: Apps → Gmail → Routing → Add a Routing setting

• cPanel: Email → Forwarders → Add Forwarder

Forwarding is the recommended path because there's zero DNS risk: your existing inbox keeps working as a backup, and you can switch off the forwarder instantly if anything goes wrong.

Direct MX Delegation (Advanced)

Point your domain's MX records directly at concorbit's inbound provider. This is cleaner long-term (concorbit receives everything natively) but takes your existing inbox offline.

DNS propagation usually completes within an hour but can take up to 48. Mail in flight during the cutover may be delivered to either side.

Only do this if you're ready to fully cut over and you understand the rollback cost (changing MX back takes another DNS propagation cycle).

Step 3: Verify Routing

With Step 1 saved and routing in place from Step 2, send a test email from one of your declared sending addresses to your concorbit inbound address (shown on the page), then click Verify.

concorbit looks at the inbound email log for the last 5 minutes and checks for a message from any of your declared sender domains. If one is found:

• The page shows a green Verified badge.

• The verification timestamp is recorded on your workspace.

• The Autotask connection page (if you have one) will allow flipping Customer reply email source to "concorbit sends" without warnings.

If no matching email is found:

• You see a "no match" error message.

• Send the test (or wait for it to land) and click Verify again.

• The verify endpoint is rate-limited to 30 requests per minute.

Tying In to the Autotask Reply Source Toggle

The Customer reply email source setting on the Autotask connection page (/settings/autotask) decides who actually sends the email when a time entry has "Reply to contact" ticked:

• Autotask sends: Autotask's notification rules fire the customer email. Reply-to is whatever you've configured in Autotask. Inbound setup is not required.

• concorbit sends: concorbit's TicketTimeEntryReplyMail fires the email. Reply-to is a concorbit-managed thread token address (or your declared support address if you've set up inbound). Inbound setup is required, otherwise customer replies have nowhere to land.

The Autotask page shows an Inbound verified / Inbound not verified badge next to this toggle, plus an inline warning when inbound isn't verified. Flipping to "concorbit sends" without verification triggers a hard confirmation dialog.

Troubleshooting

Verify keeps failing even though I sent the test email.

• Check the inbound count on the wizard's status banner (e.g., "3 inbound emails received in the last 7 days"). If it stays at 0, your test never reached concorbit, meaning the forwarding rule or MX records aren't in place.

• The verify window is 5 minutes. If you sent the test more than 5 minutes ago, send a new one.

• The test must come from one of your declared addresses. Sending from a personal Gmail won't match.

My existing inbox stopped receiving mail.

• This only happens with the direct MX path. Switch the MX records back to your previous values to restore delivery, then use the forwarding-rule path instead.

Inbound activity in the wizard says zero.

• Either no test email has been sent yet, or the routing isn't reaching concorbit. Confirm by visiting the platform inbox at /admin/platform/inbox (super admin only). If mail is arriving but not being attributed to your tenant, your forwarding target may be using a different slug than expected.