The platform
From the SMTP handshake to the inbox, in one system
Most teams end up with five vendors between their application and somebody reading an email: a relay, a marketing tool, a verification service, a monitoring subscription, and a mailbox provider. Five bills, five dashboards that disagree, and — the expensive part — reputation and suppression split five ways. InkPigeon is the whole path in one place.
The stack you would otherwise assemble
Same jobs. One system, one reputation, one suppression list.
SMTP relay and send API
Usually: A transactional provider
smtp.inkpigeon.com on 587, 465 or 2525 — and a REST API over the same pipeline
Campaigns and automations
Usually: A separate marketing tool
Campaign builder and multi-step visual automations in the same app
List validation
Usually: A per-credit verification service
Syntax, DNS, MX, disposable, role and typo checks built into imports and forms
Bounce and complaint handling
Usually: A spreadsheet, or nothing
Classified automatically, suppressed permanently, surfaced before a send goes out
Deliverability monitoring
Usually: A monitoring subscription
Per-domain reputation, warm-up schedules and DNS checks in the dashboard
Analytics and webhooks
Usually: Whatever each vendor exposes
One event stream and one set of signed webhooks for every path
Mailboxes on your domain
Usually: A separate productivity suite
Optional IMAP mailboxes and webmail on the domains you already send from
What happens to one message
Every stage below is a place mail normally goes wrong. They are in one codebase, so they can talk to each other.
- 1
Handoff
Your application opens an SMTP connection on 587 with STARTTLS, or POSTs JSON to the API. Legacy software that only speaks SMTP and a modern service that prefers HTTP enter the same pipeline at this point and are treated identically from here on.
- 2
Authentication and quota
Credentials resolve to an organisation. Plan limits, per-org rate limits and acceptable-use state are checked before the message is accepted, so a problem is a clean rejection at submission rather than a silent failure hours later.
- 3
Validation and suppression
Recipients are checked against syntax, DNS and MX reality, disposable and role-account patterns, and your suppression list — which every hard bounce, complaint and unsubscribe has already written to. One list, shared by SMTP, API and campaigns.
- 4
Render
Templates merge, personalisation resolves with fallbacks, a plain-text alternative part is generated, tracking is applied according to your settings, and the List-Unsubscribe and List-Unsubscribe-Post headers are attached to marketing mail so one-click unsubscribe works the way the big providers now require.
- 5
Queue and fair scheduling
Transactional mail outranks bulk. A million-recipient campaign cannot delay a password reset, and no single organisation can starve another on shared infrastructure.
- 6
Throttling and warm-up
Delivery is paced per receiving domain, respecting the rate each provider tolerates, and follows a warm-up schedule while a new IP or domain builds a reputation. Deferrals back off and retry rather than hammering.
- 7
The wire
The message leaves your IP, signed with DKIM, aligned for DMARC, over TLS, from a host with valid forward-confirmed reverse DNS. This is the part that decides inbox or spam, and it is configured once with guided DNS checks rather than left to you to discover.
- 8
What comes back
Bounces are parsed and classified hard or soft, complaints arrive through feedback loops, opens and clicks are recorded with scanner traffic accounted for. Everything lands in one event stream, fires signed webhooks, and writes back to the suppression list automatically.
Why one system matters more than one bill
Consolidating vendors saves money, and that is the least interesting reason to do it. The real cost of a split stack is that the pieces cannot see each other.
Somebody unsubscribes from a campaign at vendor A. Vendor B, which sends your invoices, has never heard of them and keeps mailing. That is a complaint, and the complaint lands against a domain both vendors share. Meanwhile the bounce that vendor A recorded never reaches the validation service you pay separately, so the dead address gets another go next month.
Here the suppression list is one table. A hard bounce from a campaign stops an API send a second later. A complaint from a mailbox provider suppresses that address across every path you own. The reputation your transactional mail earns is the reputation your campaigns inherit — and if a campaign damages it, you can see that in the same dashboard rather than inferring it from a support ticket.
What this does not do
The limits are real and we would rather you read them here than find them in week three.
- Warming a new IP takes weeks. No platform shortens that — we schedule it and stop you outrunning it.
- You still own your DNS records and your consent. We check both and tell you when they are wrong; we cannot fix them for you.
- Validation lowers your bounce rate. It does not make it zero, and any vendor promising otherwise is selling you a guess dressed as a fact.
- A dedicated IP only helps if you send enough to keep it warm. Below that, our shared pool will place your mail better.
Point your app at it in ten minutes
Four SMTP settings, or one API key. Add a domain, follow the DNS checks, and send. The free tier is enough to prove it works before you move anything that matters.