Shared emails let your recruiting team send candidate-facing messages from a professional, team-owned address — like recruitment@yourcompany.com — instead of individual personal inboxes or Kula's default no-reply address. Replies come back into Kula rather than scattering across everyone's individual inbox, so the whole team can see the same conversation thread.

Setting one up

A shared email is tied to your company's domain, and getting it working candidate-facing requires domain verification:

• Add and verify your domain. Kula supports MX, TXT, and CNAME-based verification, with a guided flow you can hand off to your IT team. If your domain's MX records are already claimed by your primary mail provider (a common situation), you can skip MX entirely and verify using a forwarding rule instead — for example, adding the shared email on a dedicated subdomain like talent@kula.yourdomain.com, verified via a CNAME record.

• Set up email forwarding so replies sent to your shared address are routed to Kula. Both Google Workspace and Microsoft-based forwarding are supported.

• Decide who can use it. Share the address with specific users, specific roles, or the entire organization.

• Optionally set it as the default for candidate-facing communication. If no shared email is set as default, Kula falls back to a Kula-hosted address in the form talent@yourcompany.kula.ai rather than the generic no-reply address.

Where shared emails can be used

Once configured and shared with you, a shared email appears as an option in the "From" dropdown almost anywhere Kula sends a candidate-facing email:

• Email activity

• Ad-hoc emails

• Rejection emails

• Offer emails

• Flow emails to candidates

• Assessment emails (used automatically if a shared email is set as default)

• Application submission emails (used automatically if set as default)

• Referral emails (used automatically if set as default)

The one exception is calendar invites, which always go out from the interviewer's own connected calendar rather than a shared email.

Good to know

• A shared email can't be set as your default sender until its forwarding rule is actually working. This is by design — Kula won't let a candidate-facing default point at an address that can't reliably receive replies. If you're trying to use a "do-not-reply"-style address as a shared email, keep in mind that this kind of address inherently doesn't support forwarding, so it can be added and used for sending, but not set as a default.

• Deleting a shared email currently isn't self-serve. If you need one removed — for example, after decommissioning an old team alias — that requires reaching out to support rather than a delete option in Settings.

• Shared-email threads with users in CC have a real, currently unresolved risk of being tracked twice — once through the shared email and once through the individual user's own connected mailbox. If you're seeing duplicate activity entries on a candidate tied to a shared-email conversation, this is a known, open issue rather than something wrong with your setup.

• Shared-mailbox sending through outreach Flows is a newer path and has had at least one real, high-impact throttling bug, where a daily email-send limit wasn't being enforced for a Flow using a shared mailbox, causing all scheduled emails to send in one burst instead of being spread out. If you're running high-volume outreach through a shared email, it's worth double-checking that any daily limits you've set are actually taking effect.

• CC and BCC fields require selecting an existing Kula user — you can't freetext an outside email address. If your team relies on shared inboxes partly for looping in non-Kula-user stakeholders (HR, a hiring manager without a seat) on candidate threads, that's not currently possible directly from the email composer.

• Assigning a shared email to a specific role or group has had at least one real, since-fixed bug where the address didn't reliably show up for members of the assigned group even though it should have. If a shared email seems to be missing from your "From" options despite being shared with your role, it's worth confirming with an admin exactly who it's currently assigned to.

FAQ

• How do I set up a shared email for my team? Go to Settings → Shared Emails, verify your domain (MX/TXT/CNAME, or a forwarding-rule-only path if MX isn't available), set up forwarding, and choose who it's shared with.

• Our domain's MX records are already used by our primary email provider — can we still set up a shared email? Yes — you can skip the MX route and verify using a forwarding rule instead, typically on a dedicated subdomain.

• Why can't I set our do-not-reply address as the default shared email? A shared email needs a working forwarding rule to be eligible as a default, and "do-not-reply" addresses structurally can't forward replies — so they can be used for sending but not set as default.

• I should have access to a shared email based on my role, but I don't see it in the From dropdown — why? This has been a real, previously-occurring bug tied to how a shared email is assigned to a role or group. Check with your admin that the address is actually assigned to your role, and if it still doesn't appear, contact support.

• How do I delete a shared email we no longer use? There's no self-serve delete option currently — reach out to support to have it removed.

Need help?

For connecting your own individual mailbox (separate from a shared team address), see "Connecting your email and calendar." For how email replies sync and get tracked generally, see "Email sync and tracking." For capturing candidate emails and resumes sent outside a shared inbox entirely, see "Maildrop." For anything else, reach out to us at support@kula.ai or use the in-app chat.