Email; How to integrate, block and respond

Last updated: September 16, 2026

Admins and Superadmin

Connect your HR email addresses so every email becomes a request, ready for AI categorization, prioritization for your team to action/respond. This ensures teams only need to manage one space for all inbound requests. There's no limit to how many emails to forward and configure as 'send as.'

How it works

  • Incoming emails are forwarded to Kinfolk and automatically create requests. The AI categorizes and prioritizes them, the same way it does with Slack requests.

  • Outgoing emails can be sent directly from Kinfolk using your own sender address (e.g. people@company.com). Any replies will automatically create a request in Kinfolk.

  • Spam and unwanted emails can be managed through your existing email filters. For additional control, use Kinfolk's blocklist to prevent specific addresses from creating requests.

A few callouts

  • This can only be done at email level, not domain level.

  • This is particularly useful if you need the emails to land in the inbox (perhaps for auditing purposes), but no action is needed, so don't need to be in Kinfolk.


How to integrate email

Before you begin, make sure you have:

  • Your email address — The address you want to receive emails at (e.g. support@yourcompany.com)

  • Your Kinfolk forwarding address — This looks like abc123xyz@inbox.kinfolkhq.com. You can find this in your Email settings

    Screenshot 2026-03-10 at 08.35.31.png
  • Admin access to your email provider — For example, Google Workspace Admin Console or Microsoft 365

  • Admin access to your DNS provider (optional) — Only required if you want to send emails from Kinfolk. Examples: Cloudflare, Namecheap, GoDaddy


Receiving emails in Kinfolk

Choose your email provider below for instructions.

If you use Google Workspace

  1. Open Email forwarding settings in your Admin Console

  2. Click Default routing, then Configure (or Add another rule)

  3. Configure the forwarding rule:

    • Name: Kinfolk forwarding (or any name you prefer)

    • Address: Your support email (e.g. support@yourcompany.com)

    • Forward to: Your Kinfolk forwarding address (e.g. abc123xyz@inbox.kinfolkhq.com)

    • Messages affected: Select All incoming messages

  4. Click Save

We recommend you keep a copy in your original inbox, check the box, and also route to the original destination before saving.

Microsoft 365

  1. Go to the Exchange Admin Center

  2. Navigate to Mail flow → Rules

  3. Click Add a rule → Create a new rule

  4. Configure the rule:

    • Name: Kinfolk forwarding

    • Apply this rule if: The recipient is your support address

    • Do the following: Redirect the message to your Kinfolk forwarding address

  5. Click Save

Other email providers

Forwarding can typically be set up through your email provider's admin panel or your domain registrar. If you need help, get in touch, we're happy to assist.

Tip: To block specific addresses from creating requests, add them to your blocklist in Email settings.

Once the above is done, you will need to 'validate' this/these email address in the "allowed senders" section.

  1. The reason for this extra stage is in case (in the unlikely event) the unique email address was discovered/shared, unwanted emails may come through

  1. There's no limit to how many email addresses can be forwarded to Kinfolk

Screenshot 2026-03-10 at 08.35.31.png

How to block emails

Spam and unwanted emails can be managed through existing email filters.

However, if they do come through, it's recommended that they're "archived" in the platform, so they aren't conflating your stats (particularly as emails can't be deflected).

Kinfolk does have a blocklist feature to utilise if needed, which means emails from a specific address won't trigger requests. Simply list the email address (these will still land in your email inbox).

A few callouts

  • This can only be done at the email address level, not the domain level.

  • This is particularly helpful if there are emails which need to be received for audit purposes (invoices, receipts for payroll platforms etc), but don't need to be actioned and responded to in Kinfolk.

Screenshot 2026-03-10 at 08.35.41.png

Sending emails

To send emails from Kinfolk using your company domain, you'll need to add a sender address and configure DNS records. This ensures your emails are authenticated and reach your employees' inboxes. Without the below configuration, the default sender address will be <your-org-name>@inbox.kinfolkhq.com.

Step 1: Add your sender address

  1. Go to Email settings

  2. Enter the email address you want to send from (e.g. people@yourcompany.com)

  3. Click Add Address

Kinfolk will generate the required DNS records, displayed in a table below.

Step 2: Add DNS records

Copy each CNAME record into your DNS provider. The steps vary by provider, but generally:

  1. Log in to your DNS provider (Cloudflare, Namecheap, GoDaddy, etc.)

  2. Navigate to DNS settings for your domain

  3. Add each CNAME record using the name and value shown in Kinfolk

  4. Save your changes

Step 3: Verify your domain

  1. Return to Email settings

  2. Click Verify DNS

  3. Once each record is verified, the status will update to Verified

Screenshot 2026-03-10 at 08.57.08.png

Note: DNS changes usually propagate within 5–30 minutes, but in rare cases may take up to 24 hours. You won't see anything here if you haven't done step 1 and 2.

Step 4: Send a test email

Once verified, send a test email from Kinfolk to confirm everything is working correctly.


Conversation Creation in Kinfolk

  • Emails are forwarded to Kinfolk when one of the configured forwarding addresses is in the "To" or "CC" fields of an email, regardless of how many recipients are in these fields.

    • If an email is sent with two forwarding emails in the "To" line, the first email address will take precedence if there are default rules in place. i.e. if an email was sent to "hr@kinfolkhq.com" and "payroll@kinfolkhq.com" in the "To" field, "hr@..." would be the default as it's first in line. If there are no default rules, the AI will categorise this once to the most relevant category (regardless of what email addresses are included).


Conversation closure & Reopen

  • If a conversation is 'Closed' by a Kinfolk User, and the submitter sends another email, the ticket will not move to “New” as it does with Slack.

  • A "Closure" notification via email (when Kinfolk user marks conversations as 'closed') is configurable per organisation, but is on by default. Toggle this on/off on the 'email' page.


Multi-Sender Conversations

  • Multiple people/addresses can participate in the same email thread without creating separate tickets in Kinfolk; it will be contained to the same 'conversation'.

    • If someone is added to the conversation via email or the Kinfolk platform (using the cc feature), it remains contained in that conversation, too.

  • Use the "reply to specific email" feature when working with complex multi-message threads

  • If Kinfolk user CCs another address when responding to an email, the conversation thread will be visible to the 'new' address

  • If multiple people are involved in a conversation, as they have been brought in by CC mid-way in conversation, the Kinfolk user can choose who to respond to by using the small reply arrow. Any replies will still be threaded to the same conversation.

  • All email recipients (To, CC, BCC) are visible within the ticket conversation, so Kinfolk users can see who was copied into the initial email (bottom right hand corner of the message box)

  • When replying to an email which had multiple people in the “To” and “CC” fields, that response is only sent to the submitter of the email. It doesn’t reply to everyone

If typing just in the 'Reply' box, that will send a reply to the email sender only

Screenshot 2026-07-21 at 09.49.40.png

However, you can bring other people into the conversation using the following functionality


How threading ID works (keeping emails in the same Kin thread)

Every time Kin receives an email, it has to make a decision: add this message to an existing request, or open a new one. Getting that decision right is what "threading" means.

The important thing to know is that Kin does not decide based on the subject line alone. Two emails with the same subject will not be merged into one ticket just because the subjects match. Instead, Kin looks at hidden information every email carries — a conversation identifier your email system attaches behind the scenes — combined with who sent the message. That combination is what ties a reply back to the right conversation.

Why sender identity matters

This is the part that surprises people most. Imagine HR sends one company-wide email and 50 employees reply to it. Behind the scenes, all 50 replies can share the same conversation identifier, because they all descend from that one original email.

Kin deliberately keeps these as separate tickets, one per employee, by also matching on the sender. If it merged them, you'd get one giant ticket with 50 unrelated people in it. So when you see separate tickets for separate people replying to the same broadcast — that's working as intended, not a bug.

What to expect with email threading

Situation

What Kin does

Two new, unrelated emails that happen to share the same subject

Separate tickets

An employee replies within an ongoing email thread

Same ticket — the reply lands on the original request

Many people reply to the same company-wide email

Separate tickets — one per person

A reply that clearly references a specific existing request

Routes to that request, even if another open ticket has a similar subject

Kin sends a reply out

Threads correctly in Outlook/Gmail, so your team sees one continuous conversation

Out-of-office or any auto-replies

Will appear in the conversation thread and won't create separate tickets

What is not a sign of something broken

  • Separate tickets for separate people on the same original email — expected (see above).

  • Same subject, different tickets — expected. Subject alone is no longer used to merge new emails.

  • Older tickets that were already merged before this behaviour improved don't get automatically split apart. The improvement stops new mix-ups; it doesn't retroactively untangle historical tickets. If you have an old merged ticket, that's legacy data, not a fresh bug.

  • Emails from non-Outlook systems (e.g. Gmail, or automated messages from vendor/recruiting systems) are matched using standard email identifiers and can behave slightly differently from your employees' Outlook mail.

What might be an issue and to let us know about

If you see any of these, it's worth raising with us so we can check:

  • Two genuinely different people's emails landing in one shared ticket (a "fan-in" mix-up on new mail).

  • A reply to an ongoing thread that starts a brand-new ticket instead of continuing the existing one.

  • A reply that clearly belongs to one request showing up attached to a different one.