Do I Own My Cold Email Mailboxes and Domains?

If your domains are registered in your name at a registrar you can log into, and your mailboxes live in a Google Workspace or Microsoft 365 tenant where you hold the super admin / global admin account, then yes, you own them, and your provider is a reseller you can walk away from. If all you received was a spreadsheet of SMTP credentials, with no admin console and no registrar login, you own nothing: you are renting access, and the vendor can revoke it at any time.

Most people asking this question have already paid for mailboxes and are now trying to work out, after the fact, what they actually bought. Ownership is verifiable in about fifteen minutes, without asking the vendor. This article shows you exactly how to check, what the answers mean, and what to do if the answer is bad.

What does "ownership" actually mean for cold email infrastructure?

"Ownership" is not one thing. It is four separate control points, and a vendor can honestly claim you own some while quietly holding others. Each one has a specific test.

• The domain. Test: can you log into the registrar account that holds it, and generate a transfer authorization code without asking anyone?
• The DNS zone. Test: can you change an MX, SPF, DKIM or DMARC record yourself, today, in under five minutes?
• The tenant and mailboxes. Test: do you hold a super admin (Google) or global admin (Microsoft) account, and can you create a user, reset a password, or delete the vendor's admin access?
• The data. Test: can you export every mailbox, sent items and replies included, without the vendor's cooperation?

If you can answer yes to all four, you own your infrastructure outright and your provider is a billing relationship. If you can only answer yes to some, you have partial ownership, which is usually fine but worth knowing precisely. If you answer no to the domain test, nothing else matters much. Whoever controls the domain controls where the mail goes.

How do I check right now whether I own my domains?

Run these five checks in order. They take about five minutes per domain and you can do all of them without contacting your provider.

• Look up the registration record. Use ICANN Lookup (lookup.icann.org) or any RDAP client. Note the registrar: GoDaddy, Namecheap, Cloudflare, Porkbun, and so on. Since GDPR, the registrant name and email are usually redacted, so public WHOIS data is not proof of ownership either way. It tells you where the domain lives, not who controls it.
• Try to log in. Go to that registrar and attempt a password reset using your own email address. If no account exists, the domain sits in someone else's registrar account, almost certainly your vendor's. This is the single most important check.
• Check the nameservers. If they point at a host you control (Cloudflare, your registrar's default, your own DNS provider), you can edit records. If they point at nameservers branded with your vendor's name, your vendor controls DNS even if you technically own the domain.
• Find out who receives renewal notices. Registrars email the account holder, not the "beneficial owner." If those emails go to the vendor and the vendor goes quiet, the domain expires. Standard gTLDs then enter an auto-renew grace period, then a redemption period where restoring the domain costs far more than the renewal, then pending delete, after which anyone can register it. Expired cold email domains get caught by drop-catchers quickly.
• Check the transfer lock status. A clientTransferProhibited status is normal registrar security and you can toggle it yourself if you own the account. Separately, ICANN's transfer policy imposes a lock of up to 60 days after initial registration and after a change of registrant. A newly bought domain that "can't be transferred yet" may be genuinely locked, or the vendor may be using the policy as cover. The registrar login test settles it.

One nuance worth knowing: a vendor buying domains inside their own registrar account is not automatically malicious. It is often just operationally easier at volume. The problem is that it is indistinguishable from lock-in until you try to leave. Ask for the domains to be pushed into a registrar account in your name, and treat reluctance as your answer.

How do I check whether I own my Google Workspace or Microsoft 365 mailboxes?

Google Workspace

Sign in at admin.google.com with your own account, not a shared one.

• Under Account → Admin roles, confirm that an account you control holds Super Admin. Anything less, such as delegated admin or user management admin, means someone else is above you and can remove you.
• Under Billing → Subscriptions, look for whether the subscription is marked as managed by a reseller. This is normal and legitimate. A reseller holds the billing relationship and has delegated admin access to support you; the tenant itself is still yours.
• To confirm you can leave, check that you can generate a transfer token. Google's model lets a customer move their tenant to a different reseller or to direct billing with Google using a token generated from the customer's own admin console. You do not need the current reseller's permission. This is the mechanism that makes reseller mailboxes genuinely portable.

Microsoft 365

Sign in at admin.microsoft.com.

• Confirm an account you control holds Global Administrator.
• Go to Settings → Partner relationships. You will see any CSP partner and their delegated admin privileges (GDAP). You can review and remove those privileges yourself.
• Understand the billing consequence before you pull the trigger: if the partner resells your licences, removing the relationship without moving to another partner or to direct billing will orphan the subscription. Sequence it. New partner or direct billing first, then remove the old relationship.

The red flags that mean you don't own anything

• Your mailboxes are addresses on a domain the vendor owns, shared with other customers.
• You were given SMTP host, port, username and password, and nothing else. No console URL.
• Logging in to the admin console is "not supported" or "handled by our team."
• Mailboxes are provisioned through the vendor's API only, and don't appear as real users in any tenant you can see.
• The provider is not an authorized Google or Microsoft partner. Bulk Workspace accounts sold outside the authorized partner programme are a recurring source of mass terminations; when that happens, the accounts vanish with no appeal and no export window.

The last one deserves emphasis. Cheap mailboxes are sometimes cheap because they are unauthorized. Authorization is a verifiable property of the provider, not a marketing claim. Ask which partner programme they operate under and whether your tenant will show a reseller relationship in the admin console. If it does, that is evidence of a legitimate channel relationship. If your tenant shows no reseller at all yet you are paying a third party, ask where the licences actually come from.

Is a reseller relationship bad?

No, and conflating "reseller" with "doesn't own" is the most common mistake in this space. Both Google and Microsoft run formal channel programmes precisely so that a partner can handle provisioning, billing and support while the customer keeps the tenant. Under those programmes:

• The tenant, the users, the mail data and the domain association are the customer's.
• The partner's admin access is delegated and can be revoked by the customer.
• The customer can move to a different partner, or to direct billing, using a documented transfer process.

What makes a reseller arrangement dangerous is not the model, it is a vendor that layers extra dependencies on top of it: holding your domains, running your DNS, keeping super admin for themselves, or refusing to name the programme they operate under. Those are contractual and operational choices, and you can inspect every one of them before you pay.

Why does ownership actually matter?

Ownership sounds abstract until one of these happens. Each of these is a routine failure mode in cold email operations, not a hypothetical:

• A billing dispute freezes your pipeline. A failed card, a chargeback, or an argument over a renewal ends with mailboxes suspended. If you hold super admin and the domains, a vendor dispute is a vendor dispute. If you don't, it is a full outage across every sequence you are running.
• The provider shuts down or is acquired. Owned domains at your own registrar survive this trivially. Domains in a defunct vendor's registrar account may be unrecoverable, and every sequence, signature, tracking link and reply thread tied to them dies.
• You need to fix DNS in a hurry. A DMARC policy tightening, a DKIM key rotation, an SPF lookup limit breach, a subdomain suddenly being used for spoofing: these need edits in minutes, not a support ticket queued behind other customers.
• You need your replies. Positive replies in cold email mailboxes are revenue data. If you cannot export mailbox contents yourself, your CRM history is hostage.
• Someone does due diligence on you. Acquirers and enterprise procurement ask who owns the sending domains associated with your brand. "Our vendor does" is an awkward answer, particularly for lookalike domains that carry your trademark.
• Price changes. Portability is the only real negotiating leverage you have. A provider who knows you can move in a day prices differently to one who knows you can't.

What does ownership not protect you from?

This is where most articles on this topic overpromise. Owning your infrastructure is necessary, not sufficient.

• Google and Microsoft can still suspend you. Their terms apply to you directly as the tenant owner. Sending genuinely abusive volume gets accounts disabled regardless of who resold them. Ownership means you get the notice and can appeal. It is not immunity.
• Registrars and registries can suspend domains for abuse. A well-evidenced spam complaint to a registrar can take a domain down whatever the WHOIS says.
• You never own an IP address. Dedicated IPs are allocated to you for the duration of service. Reputation attaches to the IP and stays with the provider when you leave; it does not migrate with you. Treat "dedicated IP" as a way to avoid other people's reputation problems, not as an asset you hold.
• Blocklist entries and domain reputation don't reset. Domain reputation follows the domain, which is an argument for owning it, and also a reason that burning domains you own has a real cost.
• Warmup history isn't a portable asset. It is an emergent property of how a mailbox and domain have behaved, not a file you can move.

What should I ask a provider before I buy?

Paste these into an email. The acceptable answers are listed alongside. A provider who answers all ten cleanly and in writing is selling you infrastructure; one who deflects is selling you access.

• Whose registrar account will my domains live in, and can you push them into an account in my name? Acceptable: yours, or moved to yours on request.
• Will I hold super admin / global admin on the tenant from day one? Acceptable: yes, no qualifications.
• Are you an authorized Google and/or Microsoft partner, and will the reseller relationship be visible in my admin console? Acceptable: yes and yes.
• Can I remove your delegated admin access without losing the mailboxes? Acceptable: yes, with a note about billing sequencing.
• Who controls the nameservers and can I move DNS to Cloudflare or my own provider? Acceptable: you can, any time.
• What is the documented process and timeline if I want to leave? Acceptable: a specific process (transfer token, partner change, domain push), not "contact support."
• Are there contract minimums, setup fees, or exit fees? Acceptable: stated plainly.
• How do I export mailbox data myself? Acceptable: a real answer naming Google's data export tool, Microsoft's export paths, or IMAP.
• What happens to my mailboxes if I stop paying, suspended or deleted, and after how long? Acceptable: a stated grace period before deletion.
• Is there an API, and does it cover provisioning, DNS and credential retrieval? Acceptable: yes, with docs you can read before buying.

What does leaving actually look like?

There are two very different scenarios, and people conflate them constantly.

Scenario A: changing reseller only (hours, no downtime)

Your tenant, domains, mailboxes and DNS all stay exactly where they are. Only the billing and delegated-admin relationship changes: generate a transfer token (Google) or add the new partner and remove the old relationship (Microsoft). Nothing about sending changes. No DNS edits, no password resets, no reconnecting mailboxes in your sending tool, no warmup interruption. This is the entire practical value of owning the tenant: your exit is a billing change, not a migration.

Scenario B: full migration to new domains and mailboxes (weeks)

This is what you are stuck with if you don't own things. You register new domains, stand up a new tenant, configure SPF/DKIM/DMARC from scratch, create mailboxes, connect them to your sending tool, warm them up, and rebuild every sequence, signature and tracking link. Old replies are lost unless you exported them. Budget weeks, not hours, and expect a gap in sending volume.

Whichever scenario applies, one detail catches people out: warmup and sending live in your sequencing tool, Instantly, Smartlead or ReachInbox, not in your infrastructure provider. Those tools connect to each mailbox via OAuth or IMAP/SMTP credentials. In Scenario A nothing changes, because the mailboxes are unchanged. In Scenario B you are reconnecting every mailbox and restarting warmup from zero on brand-new domains with no history.

Where does Inboxlogy fit?

Inboxlogy is a cold email infrastructure provider built specifically around the answer this article argues for: you get 100% ownership and admin access to authorized Google Workspace and Microsoft 365 mailboxes, on dedicated US or EU IPs, with SPF, DKIM and DMARC configured automatically at setup. There is a full API for provisioning and management, pricing starts at $2.80 per mailbox per month with $0 setup, and billing is monthly, so there is no annual lock-in, which is the contractual half of portability.

To be explicit about scope, because it matters when you are comparing providers: Inboxlogy does not run warmup. Warmup happens in whichever sending tool you connect: Instantly, Smartlead or ReachInbox. Inboxlogy provides the mailboxes, domains, DNS authentication and IPs; your sequencer provides warmup and sending.

And the honest framing: everything in the audit above is something you can and should run against Inboxlogy too. If a provider's ownership claims don't survive a look at your own admin console and registrar account, the claims are wrong, including ours.

FAQ

If my provider is a Google Workspace reseller, do I still own my mailboxes?

Yes, provided you hold super admin on the tenant. In the authorized reseller model the tenant and its data belong to the customer; the reseller holds billing and delegated admin access. You can generate a transfer token from your own admin console and move to another reseller or to direct billing with Google without the current reseller's permission.

My vendor registered my cold email domains for me. Are they mine?

Only if they are in a registrar account you can log into. Being described as the "owner" in an invoice or dashboard means nothing operationally, and public WHOIS is usually redacted so it won't confirm it either. Ask for the domains to be pushed to your own registrar account. Note that ICANN's transfer policy can impose a lock of up to 60 days after registration or after a change of registrant, so a short genuine delay is normal. An indefinite one is not.

Can I move my existing cold email mailboxes to a new provider without losing warmup?

If you own the tenant and domains, yes. A reseller or partner change leaves the mailboxes untouched, so warmup in Instantly, Smartlead or ReachInbox continues uninterrupted. If you are being forced onto new domains and a new tenant, warmup starts over; there is no way to transfer reputation to a domain that has no history.

What's the fastest way to tell if I don't own my infrastructure?

Try to do two things right now, without contacting anyone: log into the registrar that holds one of your domains, and open the Google or Microsoft admin console for your tenant. If either fails, you are renting. Fix the domain side first. The domain is the piece that is hardest to recover once a vendor relationship goes bad.