Authentication & deliverability
The records that decide whether your domain is believed.
Before a receiving server decides where your message goes, it asks a much duller question first: is this domain who it says it is? That is answered entirely by DNS records and one verification check — and those are the part Infrabox can genuinely do for you, so they are what this page is about.
What happens after that question — whether the person wanted the message — is not something any infrastructure vendor can sell you. We would rather state the line than blur it.
- records
- MX · SPF · DKIM · DMARC
- verified by
- connection
- SMTP · port 587
- daily cap
- 2,000 / mailbox
- placement rate
- Not claimed
The last row is not an omission. It is the point of the section headed “where the line is”.
01the records
What gets checked
Five things a receiver looks at.
Four are DNS records, and each one answers exactly one question. The fifth is not a record at all — it is a gate Google puts in front of the domain before it will carry any mail.
MX
Where does mail go?
Says where mail for the domain should be delivered. Without it the domain cannot receive — and a sending domain that cannot take a reply is not a sending domain, it is a leak.
SPF
Who may send as you?
Lists which servers may send as the domain. One stray include, one lookup too many, and receivers stop treating the domain as authorised. The easiest record to get subtly wrong.
DKIM
Was it altered?
The signature proving a message was not altered in transit. Google exposes the key only through the Admin Console, which is why it is the record most setups quietly skip.
DMARC
What if they disagree?
Tells receivers what to do when SPF and DKIM disagree with the visible From address. Publishing a policy is the difference between having an opinion about your domain and having none.
Not a record — a gate
Google’s domain verification
Google will not let a domain send at all until it has confirmed you own it, and Google decides when it is satisfied. It is step 5 of 8, and it is the one that takes the longest.
And what none of them decide
Whether the recipient wanted it
All five answer identity, not welcome — which is why getting every one of them right is necessary and still not sufficient. That distinction is the whole reason this page has a section headed “where the line is”.
02failure modes
Why it goes wrong
None of this is hard. All of it is easy to get slightly wrong.
Every failure below is silent. Nothing throws an error, no page goes down, and the domain keeps sending — into a spam folder, for weeks, until somebody notices the reply rate.
Doing it by hand
- The SPF record is edited by hand and gains an extra include, or trips the DNS lookup limit.
- DKIM never gets switched on, because the toggle is several menus deep and nothing breaks visibly when it is off.
- DMARC is never published at all, so receivers are left to guess.
- Verification is attempted once, fails because DNS has not propagated, and is quietly abandoned.
- It is all done correctly on the first domain, then approximately on the next nine.
What provisioning does instead
- Workspace & DNS. MX, SPF and DMARC records are published for the domain.
- Domain verification. Google is asked to confirm you own the domain. Google sets the pace here.
- DKIM signing. A DKIM key is generated, published to DNS and switched on.
- The same steps run identically on the tenth domain as on the first, because it is a pipeline rather than a person following a checklist at 6pm.
- A step that is merely slow is retried rather than failed, and the dashboard shows which step each mailbox is sitting on.
03the relay
Connecting your tool
Four fields, and no Google login anywhere in the process.
Infrabox runs its own SMTP relay. Your sequencer connects to it the way it connects to any SMTP server, and the relay delivers through Google on the mailbox’s behalf — which is what makes automated provisioning possible at all.
smtp connection
- Host
- smtp.infrabox.io
- Port
- 587
- Security
- STARTTLS
- Auth
- Username and password we issue
- No app passwords. A freshly created Workspace user cannot generate one anyway — app passwords need 2-step verification, which needs a sign-in, which is exactly what Google challenges. Why that dead end exists.
- No Google sign-in. Your sending tool authenticates to Infrabox. It never reaches a Google login screen or a consent prompt.
- No integration work. If your sequencer can send over SMTP — and they all can — it can send from these mailboxes today.
- Sending only. The credential sends; it does not include IMAP. Replies still arrive, because MX was published during provisioning.
The daily cap, and why it is where it is
Each mailbox is capped at 2,000 messages a day, in a window resetting at UTC midnight. That is not a pricing tier in disguise — it is set to mirror the limit Google enforces on a Workspace user. Raising it would not buy you throughput, it would buy you rejections one hop later.
The default allowance is 5 mailboxes per domain, adjustable per account up to 20. Volume comes from more mailboxes and more domains, not from pushing one harder than Google allows.
04where the line is
Where the line is
What this page deliberately does not claim.
No inbox-placement rate. No “95% of your mail lands”. No deliverability guarantee and no money back if a campaign underperforms. None of those numbers exist in our systems, so printing one here would mean making it up.
No claim that correct authentication makes a campaign work. Authentication is necessary and it is not sufficient. If the list is bad, the copy is generic or the volume is reckless, perfectly signed mail goes to spam — correctly.
And no reliability figure attached to the DKIM step in particular. It is implemented, it runs as step 6 of 8, and it is the one step permitted to fail without blocking the mailbox. When it does fail, you are told.
What is left after all that is a real and useful thing: the boring, error-prone, entirely mechanical work of standing a domain up correctly, done the same way every time.
- Placement rate published
- None
- Deliverability guarantee
- None
- DKIM reliability figure
- None
05questions
Questions
The ones worth asking.
Does Infrabox guarantee my mail reaches the inbox?
No, and be wary of anyone who does. Authentication decides whether a receiver can tell your mail is really yours and unaltered. It does not decide whether the person receiving it wants it — and that second thing is most of what modern filtering is actually measuring.
We publish no inbox-placement percentage, because we have no measurement that would honestly support one.
So what does DKIM actually buy me?
Our own provisioning code puts it about as plainly as it can be put: a mailbox with no DKIM record still sends and still receives — it just signs nothing, so its deliverability is worse. Qualitatively worse. There is no number attached to that sentence in our codebase and there is not going to be one on this page.
It is also the one provisioning step allowed to fail without blocking the mailbox, for exactly that reason. If it does fail, the dashboard says so rather than hiding it.
Why does domain verification take so long?
Because it is Google’s check, not ours, and it waits on nameserver delegation and DNS propagation — which routinely take hours and are outside anyone’s control. The step is built to wait rather than fail: up to 40 attempts, backing off from 60 seconds to a 15-minute ceiling. The full step-by-step timing is here.
Do I connect my sending tool to Google?
No. Your tool connects to the Infrabox relay over ordinary SMTP with a credential we issue. It never sees a Google login screen, never needs an app password, and never has to clear a 2-step verification prompt. The relay guide has the settings.
Is there a sending limit per mailbox?
Yes — 2,000 messages per mailbox per day by default, in a window that resets at UTC midnight. That figure is not a commercial lever; it mirrors what Google enforces for a Workspace user, and a cap set above it would just mean failures one hop later.
Can I read replies over this connection?
Not with the SMTP credential — it sends, and that is all it does. There is no IMAP in it. The MX records published during provisioning mean the mailbox genuinely receives, so replies land; getting them into your tool is a separate connection.
How many mailboxes should I put on a domain?
The default allowance is 5 Google mailboxes per domain, raisable per account to 20. What the right number is for your volume is a judgement about concentration risk, not a fact we have, so we are not going to print one as though it were.
Stand a domain up properly.
Tell us how many mailboxes across how many domains, and which tool you send with. We will tell you what it costs and what to expect.