Privacy Policy

Last updated 19 August 2026. It describes how the product behaves today. Read it before you buy — sections 5 and 6 are the ones people are usually surprised by.

1. Scope

This policy is issued by Infrabox and describes how Infrabox handles personal data across three things: this website, the customer dashboard and API, and the email infrastructure Infrabox provisions and operates for you — domains, DNS, Google Workspace mailboxes and the SMTP relay.

It does not describe how Google, your domain registrar, or the sending tool you connect to the relay handle data once it is in their hands. Section 7 names the categories of provider involved so you can go and read theirs.

Where this policy and the FAQ describe the same mechanism, they are meant to say the same thing. If they ever diverge, the product’s actual behaviour is the accurate account, and telling us at hello@infrabox.io gets the wrong one fixed.

2. Two roles, not one

Infrabox occupies two genuinely different positions with respect to personal data, and almost every question about this policy resolves once you know which one applies.

This allocation is not a convenience. It is stated in section 7 of the Acceptable Use Policy and it is what puts the lawful basis for contacting a given recipient on you rather than on Infrabox. Where your sending involves personal data of individuals in the EU, EEA or UK, a data processing agreement under Article 28 GDPR governs that processing; ask for it at hello@infrabox.io and it will be put in place alongside your subscription.

3. Account data

As controller, Infrabox collects only what running an account requires:

• Identity and contact details — your name, email address, and optionally a phone number, job title and country, taken at signup or from the sign-in provider you used.
• Team and workspace membership — which account you belong to and what role you hold in it, because access control is impossible without it.
• Subscription and billing records — what you bought, what it renews at, and the invoice history. Card details are entered with a payment processor and are not stored by Infrabox.
• Support correspondence — anything you send to hello@infrabox.io or through the get started page, kept so a conversation has a memory.
• Operational records of your infrastructure — the domains and mailboxes provisioned for you, the state of each provisioning step, DNS records published on your behalf, and the send log described in section 5.

The lawful basis for all of it is performance of the contract you entered into, except for records kept to meet a legal obligation (billing) or to defend the platform against abuse, which rest on Infrabox’s legitimate interest in running a network that is not used to send fraud.

4. Domain registration data

Registering a domain means giving a registrar registrant contact details, and those details are what appears — or is proxied — in WHOIS. Infrabox handles this with an explicit switch rather than a default nobody sees:

• By default, the registrant is Infrabox, using Infrabox’s own contact details, with WHOIS privacy enabled. Your personal details are not sent to the registrar as the registrant.
• You can opt in to your own identity at purchase, in which case the contact details you supply are transmitted to the registrar as the registrant of record and are subject to that registrar’s WHOIS handling and ICANN’s requirements.

This is a deliberate choice with consequences either way, which is why it is a question and not a setting buried in an account page. The FAQ covers what the choice means commercially.

5. What sending through Infrabox records

This is the section that matters most, so it is the most specific. When your sending tool connects to the Infrabox SMTP relay and hands over a message, two separate things happen to it.

The message itself is passed through and dropped. The relay forwards your bytes to Google exactly as your tool produced them — it does not re-encode the message, because re-serialising it would disturb the tracking, threading and campaign headers your tool put there. The message is held in memory only for as long as the handoff takes. It is not written to disk, not queued to a store, and not logged. The only part of it ever read as text is the header block, and the reader stops at the blank line that ends the headers and never looks past it.

A metadata row is written for every attempt. One row per message, whether it succeeded or not. It contains:

• the mailbox that authenticated, as an address and an internal identifier — that is, who sent it;
• the team and workspace the mailbox belongs to;
• the Message-ID header your sending tool generated, and the message and thread identifiers Google returned, so a specific delivery can be traced later;
• the outcome, the SMTP status code your tool was handed, and the error text where there was one;
• the number of recipients, the size of the message in bytes, and how long the send took;
• the IP address and hostname the connection came from — which is your sending tool, not your recipient;
• the timestamp.

The same log is the quota ledger: the daily send limit is calculated by counting successful rows since midnight UTC rather than from a separate counter, so there is one number and not two that can drift apart. That is also why the log cannot simply be emptied on request mid-period without breaking the rate limiting that protects your mailbox’s reputation. The mechanism is described in full in the relay guide.

None of this changes the fact that your sent mail exists in full in the mailbox it was sent from, which is a Google mailbox. That is the subject of the next section.

6. Access to your mailboxes

Infrabox can technically read the mailboxes it provisions for you. That is stated plainly here because it is true, and a privacy policy that implied otherwise would be contradicted by the FAQ on the same site.

The reason is structural. Your mailboxes are created inside a Google Workspace account that Infrabox holds, not one you hold — that is what makes unattended provisioning possible at all, and it means Infrabox holds the administrative credential for the account they live in. Sending credentials are minted through Google domain-wide delegation, which is impersonation of a user within an authorised list of scopes, and the authorised list includes reading Gmail as well as sending it. Reply detection is why the read scope is on the list.

What Infrabox undertakes about that access is the part that is a choice rather than a consequence:

• the scope list is kept deliberately short — sending and reading Gmail, and the directory operations needed to create and configure users. Every additional scope widens what a leaked key could reach, so scopes are not added speculatively;
• impersonation produces a short-lived access token and nothing else. No refresh token and no long-lived per-mailbox credential is stored, so there is no standing key sitting in a database waiting to be stolen;
• access is used to provision, configure, diagnose and repair your infrastructure, and to respond to abuse — not to read your mail for any purpose of Infrabox’s own, and not for training, analysis, resale or profiling.

Any provider that provisions and operates Google mailboxes on your behalf holds something equivalent. What differs between them is which scopes they took and what they say about using them, which is why both are written down here. The full mechanism is in the delegation guide.

7. Sub-processors and where data goes

Infrabox does not run a mail system of its own; it operates yours on top of other people’s. The categories of provider involved:

The registrar and DNS provider are named to you for your own domain, because more than one is supported and which one is used depends on the domain. Infrabox will name any specific provider in the list above on request.

These providers operate internationally, so operating your infrastructure involves transferring personal data across borders, including to the United States. Where such a transfer is subject to EU, EEA or UK data protection law, it is made under the transfer mechanism in the relevant provider’s own terms — standard contractual clauses in the ordinary case. Infrabox does not claim any certification or adequacy finding of its own, and does not hold one.

8. How long data is kept

Infrabox has not set a fixed number of days for each category, and printing one here that the system does not enforce would be a fiction. What governs retention instead:

• Account and subscription records are kept while your account exists, and afterwards only as long as billing, tax and limitation-period obligations require.
• The send log is kept while it is doing work — it enforces your daily quota, it is the only record that answers “did that message go out?”, and it is the evidence behind any abuse decision. It holds no message content and no recipient addresses, so retaining it does not retain your list.
• Mailbox contents are held by Google, not by Infrabox, and last as long as the mailbox does. When a subscription ends the mailboxes end with it, and their contents go with them. There is no export that moves a mailbox into a Workspace you own — see the FAQ, which does not soften this either.
• Enforcement records under the Acceptable Use Policy are kept because a record of what was done about abuse is the only defence that a network has.

If a defined retention period matters to you, ask for one in writing before you buy rather than assuming it.

9. Security

Described, not certified. Infrabox holds no security audit or compliance certification and claims none. What is actually implemented:

• Stored secrets are encrypted with AES-256-GCM — an authenticated cipher, so tampering with stored ciphertext is detected rather than silently decrypted. Each value carries its own salt and nonce, and the key is derived from a master key held in the environment using PBKDF2-SHA256 at 100,000 iterations.
• Relay passwords are hashed, not encrypted. The SMTP password your sending tool uses is generated from a cryptographic random source, shown to you exactly once, and stored only as a bcrypt hash. It cannot be recovered — not by support, not by an operator, not by anyone who takes the database. Losing it means issuing a new one, and that trade was made deliberately.
• Authentication failures cost the same as successes. An unknown username still runs a full hash comparison, so the relay cannot be used as an oracle to enumerate which Infrabox mailboxes exist. Verdicts are never cached, which makes revoking a credential take effect immediately.
• No standing Google credential per mailbox. As in section 6, access tokens are minted on demand and expire; there is no long-lived per-mailbox secret in storage.
• Transport is encrypted. The relay requires STARTTLS, and the connection onward to Google is HTTPS.
• The log is designed not to hold the sensitive thing. Section 5 is a security measure as much as a privacy one: content that is never written down cannot be breached.

No system is exempt from compromise. If Infrabox becomes aware of a breach affecting your personal data or the recipient data you process through the platform, it will tell you without undue delay, describe what is known and what is not, and say what it is doing — including where the facts are still unclear.

10. Your rights

For your own account data, where Infrabox is the controller, you can ask to:

• see what is held about you, and get a copy;
• have inaccurate details corrected;
• have data deleted, subject to what must be kept for billing, legal obligations, or an unresolved abuse matter;
• receive your data in a portable form;
• object to or restrict processing that rests on legitimate interest.

Depending on where you live, some of these are legal rights and others are simply things Infrabox will do. The practical answer is the same either way: email hello@infrabox.io from the address on the account. You will get a response within a reasonable period and, where the law sets one, within the statutory deadline. There is no fee.

For recipient data, the route runs through you. If one of your recipients contacts Infrabox asking to see, correct or delete their data, Infrabox will not act on it unilaterally — it has no relationship with them and no way to verify them. The request will be passed to you as the controller, and Infrabox will assist you in answering it. If you have a supervisory authority in your jurisdiction, nothing in this policy affects your right to complain to it.

11. This website

The web server keeps ordinary request logs, as every web server does, which include IP addresses and are used to keep the site up and to spot abuse.

The customer dashboard is a different application from this site. It needs a session cookie or token to keep you signed in, which is strictly necessary for it to work at all and is not used to track you across other sites.

12. Children

Infrabox sells business email infrastructure to businesses. The services are not directed at children, and Infrabox does not knowingly collect personal data from anyone under 16. If you believe a child has provided personal data through an Infrabox account, write to hello@infrabox.io and it will be deleted.

13. Changes to this policy

This policy tracks how the product actually works, so it changes when the product does. Material changes — a new category of data, a new sub-processor, a change to what the relay records — will be notified to account holders by email before they take effect, and the date at the top of this page will change with them.

Superseded versions are not published as an archive. If you need to know what this page said on a particular date, ask and you will be told.

14. Contact

Privacy questions, data requests, and corrections to anything stated on this page: hello@infrabox.io. A question about whether Infrabox can do a thing is best asked before you buy, and the get started page is the other way to reach the same inbox.