Infrabox vs. a generic SMTP relay
A relay and a mailbox are different categories of thing, and the comparison only makes sense once that is said out loud. A relay is a pipe: you hand it a message and it delivers it. A mailbox is a place: it has an address, it holds mail, and a person can open it.
Cold outreach needs both halves. It needs to send, and it needs the reply — the entire point of the exercise — to land somewhere a human will read it.
01the approach
The other approach, fairly
What a generic smtp relay actually involves.
Described properly, not caricatured. If this list looks straightforward to you, that is a real signal about which column you belong in.
- 01
You keep your own domain and publish the relay's authentication records on it, so the relay is authorised to send as you.
- 02
Your application or sending tool hands messages to the relay over SMTP or an API, and the relay delivers them.
- 03
Sending reputation accrues to the domain and to the relay's sending infrastructure, which you share with everyone else using it.
- 04
Receiving is a separate problem. A relay delivers outbound mail; where inbound replies go is something you have to arrange yourself, with MX records pointing at an actual mail host.
- 05
Acceptable use matters more than it looks. Relays built for transactional mail — receipts, password resets, notifications — have terms written for that use, and cold outreach is a different activity. Read them before pointing a campaign at one.
02side by side
Side by side
The comparison itself.
A dash instead of a tick means the row is a trade-off rather than a win — the two approaches simply differ, and which side you want depends on you.
| Criterion | oursInfrabox | the alternativeA generic SMTP relay |
|---|---|---|
| What you end up with | Yes:A real Google Workspace mailbox with an address, which sends and receives. | A delivery path. Messages go out as your domain; there is no mailbox behind the address unless you build one. |
| Replies | Yes:MX is published during provisioning, so the address genuinely receives and replies land in the mailbox. | Handled separately. A relay's job ends when the message is delivered outbound. |
| Domain and DNS setup | Yes:Domain registered through the platform, DNS connected, MX, SPF, DMARC, verification and DKIM all published as part of the run. | You bring the domain and publish the relay's records on it yourself. |
| How your sending tool connects | Trade-off:Ordinary SMTP with STARTTLS and a credential we issue — no Google sign-in, no app password. | Ordinary SMTP or an API with a credential the relay issues. |
| Per-message economics | Trade-off:Priced per mailbox per month, regardless of how much that mailbox sends within its daily cap. | Usually priced per message or per volume band, which is far cheaper at very high volume. |
| Sending volume ceiling | Trade-off:A per-mailbox daily cap set to mirror what Google allows a Workspace user. Volume comes from more mailboxes. | Built for high throughput from a single sending identity — which is exactly what it is good at. |
| Fit for cold outreach | Yes:It is what the product is for. | Depends entirely on the provider's acceptable-use terms, which for transactional services are generally written around a different activity. |
03where we lose
Where we lose
When a generic smtp relay is the right answer.
Every comparison page should have this section and almost none do. These are the cases where we would tell you not to buy from us.
You are sending application mail
Volume is the dominant cost
Nobody is going to reply
The bottom line
Use a relay for machine-generated mail at volume. Use mailboxes when a human is meant to reply and that reply has to land somewhere real. They are not competing products so much as answers to different questions.
Our side of it costs $3.79 per mailbox per month.
Plus the domain, priced per TLD per year. That is the entire price list — no provisioning fee, no onboarding fee, no volume tier to negotiate. Put your own numbers in.
04questions
Questions
On this comparison.
Doesn't Infrabox use an SMTP relay too?
Yes — your sending tool connects to our relay over SMTP, and the relay delivers through Google on the mailbox's behalf. The difference is what sits behind the address: a provisioned Google Workspace mailbox that receives, rather than a delivery path with nothing behind it.
Can I point my sequencer at Infrabox the same way?
Yes. It is ordinary SMTP with STARTTLS on port 587 and a username and password we issue. Any sequencer that can send over SMTP can send from these mailboxes.
Which gets better deliverability?
Not a question we are going to answer with a number, because we do not have one that would be honest. What we can say structurally: authentication is table stakes for both, and mail from a domain that can also receive and be replied to behaves differently from mail from an address that goes nowhere.
Can I use both?
Plenty of teams do, and should. Application mail through a relay, outreach through mailboxes. Keeping them on separate domains keeps their reputations separate too.
The other comparisons
Infrabox vs. doing it by hand
Registrar, Admin Console, DNS records, verification, DKIM, a credential per mailbox. Everything the manual path actually contains, and when it is still the right path.
Read itInfrabox vs. buying Workspace seats directly
Same mailboxes underneath, different amount of work on top. What you gain, what you give up, and who should choose which.
Read it
Think you are on our side of the table?
Tell us how many mailboxes across how many domains, and which tool you send with. If one of the other approaches suits you better, we will say that instead.