Every candidate email on the record, without copying your inbox

The rule is the whole design. A message is filed against a record when one of its participants matches a candidate or a client contact already in your tenant. Everything else is ignored, never read into the product, and never stored.

That means a recruiter's mail to their accountant, their landlord, their union, their doctor and their spouse never enters the recruitment system, because none of those addresses are in your candidate database. Mail to a candidate does, because that address is on a record you already hold.

The alternative approach, which several systems take, is to mirror the mailbox and then filter for display. That puts the whole mailbox into the vendor's storage and leaves the privacy of the recruiter depending on a display rule. We would rather narrow at the point of ingestion.

Connecting will use Google OAuth, and the consent screen will name the scopes. Reading messages is required to file a thread against a record and to detect a reply; sending is required so a message composed in the product leaves from the recruiter's real address rather than a no-reply relay that candidates ignore.

What will not be requested is anything unrelated. No Drive access, no contacts export, no broad account scope. Calendar is a separate connector with its own consent, because interview scheduling and mailbox filing are different jobs and an administrator should be able to approve one without the other.

Access is revocable from the Google account at any time, and revoking it stops the sync without removing what has already been filed on the records.

Threading keeps a conversation as one object rather than a scatter of individual messages. When a candidate replies, the reply attaches to the thread on the record, the sequence step that sent the original stops, and the reply handler classifies interest so the record moves or a task is raised.

Reply detection is what makes cadences safe. The single most damaging thing an email sequence can do is send step three to a candidate who answered step two, and the only reliable defence is a connector that sees the reply as it arrives rather than at the next scheduled poll.

Bounces, out-of-office notices and delivery failures are classified separately so an auto-reply does not stop a cadence and a hard bounce marks the address rather than the candidate.

Messages composed in Surhires will send through the connected Gmail account, which means they carry the recruiter's real address, the domain's own authentication and the recruiter's signature. Replies land in the recruiter's inbox and on the record at the same time.

Sending this way is materially better for deliverability than a shared relay, because the reputation belongs to your domain and your sending history. It also matters for the candidate experience: a message from a person is answered more often than a message from a system.

As with every channel, opt-out and suppression are checked before a message leaves, and email footers carry the identification and unsubscribe details the campaign relies on.

A recruiter's mailbox is a mix of work and life, and a shared work mailbox is a mix of clients and colleagues. Beyond the matching rule, the planned controls include a personal exclusion list a recruiter maintains themselves, and a per-connection choice of which labels or folders are in scope.

Nothing filed is hidden from the recruiter. Every message that lands on a record is visible with its source, and a recruiter can detach a message from a record without deleting it from Gmail. There is no silent capture, which is the property that makes people trust an email connector.

If a shared mailbox is used for a whole desk, the same rules apply, and the mailbox owner rather than each recruiter grants the consent.

It will not archive your mailbox. Surhires is not an email retention system and will not become one; filed messages are part of a candidate record with the record's retention window, not a parallel copy of your mail history.

It will not migrate historical mail from before the connection by default. Backfilling a mailbox pulls in a large volume of correspondence with people who have since asked to be forgotten, so a backfill will be a bounded, opt-in operation with a date range rather than a switch that runs on connect.