If hiring already happens in a shared inbox, the system of record should meet mail where it lives. So we built the applicant tracking system to read and reply through the customer's own mailbox over IMAP and SMTP, not through a third-party email service provider.
Where hiring actually happens
Before we wrote a line of the product, we spent time watching how small and mid-size teams actually hire. Almost none of them lived in an applicant tracking system. They lived in a shared inbox, careers@, jobs@ or hiring@, where CVs arrived as attachments, forwards flew around, and a spreadsheet tried to keep score.
The email account was the real system of record, and every tool they had tried sat awkwardly beside it. That single observation set the central constraint for the whole product. If hiring already happens in an inbox, the system of record should meet mail where it lives rather than asking the team to move somewhere else.
The path most vendors take
The conventional way to bring inbound email into a product is to route it through an email service provider such as Postmark, Mailgun or Amazon SES. You point your domain's MX records at the vendor, they receive and parse the mail, and they post a clean, structured payload to your application. It is a genuinely good pattern that scales and runs in real time, and someone else owns the messy business of accepting mail from the open internet.
But look at what it asks of the customer before they get any value. Change your DNS. Sign up with an email vendor. Verify your domain. Pass a security review. And, the part that quietly kills adoption, start using a new address for applications, because the mailbox candidates write to is now the vendor's rather than yours. For a five-person company, re-pointing MX records just to try a hiring tool is effectively being asked not to try it. There is a subtler cost too: the mail stops being authentically theirs, flowing through a third party's infrastructure under a third party's address.
What we chose instead
We made the opposite bet. Instead of intercepting mail upstream, the product connects to the mailbox the customer already owns. We read new messages over IMAP and send replies over SMTP, using the same account the team checks every day. Connecting takes a mailbox address and an app password, or a secure OAuth grant for Google and Microsoft, and nothing else. No DNS changes, no new vendor, no new address.
The shape that falls out of this decision is simple and durable. A background process checks each connected inbox on an interval and turns new CV emails into tracked applications. Replies go out over the customer's own SMTP, so they arrive from the customer's real address and thread naturally in the candidate's mail client. When the candidate replies, that reply lands back in the same inbox we are already watching, so the conversation closes the loop on its own. The mailbox is both the front door and the outbox.
The tradeoffs we accepted
This bet is not free. Polling is not real time: we check on an interval, so there is a short, bounded delay between an email arriving and an application appearing. We hold credentials, which means we are responsible for protecting them, so mailbox secrets are encrypted at rest and never written to logs. And we take on the endless variety of real-world mail servers, from app-password requirements to per-provider quirks, connection limits and folder conventions that an email service provider would have absorbed for us.
We accepted those costs because they are ours to carry, not the customer's. Polling latency measured in a couple of minutes is invisible in a hiring workflow. Credential security is table stakes we were going to build anyway. And per-provider quirks are a one-time engineering tax we pay once so that every customer pays nothing. The alternative's costs, by contrast, all landed on the customer at exactly the moment we needed them to say yes.
Keeping the door open
A good architectural bet should not become a cage. We did not want a customer who grows to high volume, and genuinely needs real-time, provider-grade inbound, to hit a wall. So underneath the email-first design we kept a second, standards-shaped entry point: a secret-guarded inbound endpoint that accepts a conventional email service provider webhook and feeds the exact same ingestion engine that IMAP polling uses.
A tenant who outgrows polling can point their MX records at a provider and switch to real-time inbound email routing without us rewriting anything. Both paths converge on one ingestion core. The email-first mailbox is the default because it removes the onboarding barrier; the webhook is the escape hatch for when scale changes the maths. The payoff is the product's whole reason to exist: onboarding measured in minutes, mail that stays authentically the customer's, and an architecture that scales with the customer instead of forcing a migration.