Custom SMTP
Send candidate emails from your own domain via your own SMTP server — Google Workspace, Microsoft 365, or any standard provider.
The first email a candidate receives from you sets the tone for everything after it — and an email from a generic platform address instead of your company domain undercuts it immediately. The Custom SMTP app routes all candidate email through your own mail server, so interview invitations, updates, and offers arrive from you@yourcompany.com, authenticated by your own domain's reputation.
The gap this closes is twofold: brand and deliverability. Candidates trust and recognise mail from the company they applied to, and mail providers trust messages from domains with proper SPF and DKIM records — which your company domain already has if you use Google Workspace, Microsoft 365, or any standard provider. Connecting your SMTP server takes the standard four details — host, port, username, password — and every candidate email the ATS sends flows through it from then on. It is included in your subscription with no per-email fees; you use the mail service you already pay for, and the sending history lives with your own provider. Combined with the interview scheduler, the whole candidate conversation happens under your name.
On this page
01Works with the mail you already have
Google Workspace, Microsoft 365, and every standard email provider expose SMTP credentials. Enter your host, port, username, and password in the ATS settings, send the test email, and you are done. There is no proprietary email product to adopt and no DNS surgery beyond what your provider already configured for your normal business mail.
02Deliverability rides on your domain
Email authenticated by your own domain's SPF and DKIM records inherits the reputation your business mail has already earned. That matters at the moments hiring can least afford a lost message — an interview confirmation that never reaches the inbox is a no-show; a missed offer email can be a lost hire. Sending from your own infrastructure keeps those messages on the reputation path your provider maintains.
03Credentials handled with care
Your SMTP password is stored for sending and never rendered back to the browser — the interface shows only that credentials are present. Email dispatch runs in the background so a slow mail server never makes a recruiter wait. Review what is included at each level on the pricing page; custom SMTP does not carry per-message charges from Expertini.
Platform architecture & operations
A1Connection architecture
This app is configuration-based: what you save is acted on directly by the platform — no third-party account link is involved. Settings are validated on save, stored per organisation, and take effect on the next request.
Changes are immediate and reversible; removing the configuration stops the behaviour visibly. As with every connector, secrets (where any exist) are stored encrypted and shown only as presence flags.
A2Write semantics and data flow
Every data movement is an explicit action with a logged result. Writes happen on your click — or automatically only where you enabled a rule (auto-push on hire is off by default, per-provider). Reads — imports of people, accounts, or files — run when you press Import, deduplicate against what you already have (clients by name, people by email), skip rather than overwrite, and report created-versus-skipped honestly, which is why re-running any import is safe by design.
Each action writes a row to the app-activity journal (ats_app_activity): what ran, when, for which record, and the outcome — including the vendor's own error text verbatim when something fails. Usage reporting inside the ATS aggregates that same journal, so integration reporting and integration reality cannot diverge.
Anything that leaves the request path — notification fan-out, webhook delivery, activity journalling, mail — runs in fire-and-forget background threads. A slow external endpoint can never make the interface hang, and a failed side effect is logged rather than silently retried into inconsistency.
A3Operational considerations
Connections are organisation-level and gated to owner and admin roles; recruiters use the features a connection powers but cannot connect, disconnect, or reconfigure. Disconnecting removes stored credentials immediately and stops the dependent features visibly, not silently. Data already imported stays yours and editable.
Imported people arrive marked as imported with conservative privacy defaults — no consent is assumed for anyone who never filled in your application form, and retention defaults apply. Everything written is yours to take: CSV exports and the Data Export app cover the same stores the product itself reads. The exit is as open as the entrance — by design, not concession.
A4Placement in the integration topology
This integration is live in the registry today. One connection per provider unlocks every feature it powers, and the topology grid below shows the neighbouring connectors in the same capability area — statuses come from the same registry that drives the in-app hub, so this page can never claim more than the product does. For anything the catalogue does not cover, Webhooks and Zapier are the generic, documented escape hatch.
Dependency map
Interface blueprint
Interaction flow — states, validations, feedback
Neighbouring connectors — Email & Sending
Frequently asked questions
Which email providers are supported?⌄
Will this improve email deliverability?⌄
Are my SMTP credentials safe?⌄
Does Expertini charge per email sent?⌄
At a glance
- Candidate email from your own domain
- Works with Google Workspace, Microsoft 365, and any SMTP host
- Standard four-field setup with a test send
- Inherits your domain's SPF and DKIM reputation
- Credentials never re-shown in the browser
- No per-email charges from Expertini
See custom smtp on your own hiring.
Bring a real job description to a 30-minute demo — free trial included.
Book a demo