How to migrate from HEY to a shared inbox on your own domain
Leaving HEY for Domains without losing mail: what the export does and does not carry, the records to swap, the internal-delivery trap, and why you export before cancelling rather than after.
Yowl gives the domain a working shared inbox the moment the MX lands, sorts the mail on arrival, and takes the MBOX you exported — so this is one of the few provider exits that is not a cutover with your old mail stranded behind it.
What you are actually moving to
HEY’s real product is not the mailbox, it is the structure: the Imbox, the Feed, the Paper Trail, the Screener. That is the part the export does not carry, and the part you will miss. So it is worth being specific about what replaces it.
The sorting happens by itself. Every message is read on arrival — body and attachments — classified and filed under its category, with anything unrecognised waiting under one Needs a look heading. The Screener’s approve-or-block decision, which you made by hand for every new sender, is a judgement made at ingest. You do not train it and you do not maintain a list.
Your old mail comes with you. Upload the MBOX HEY gives you and it is read into the inbox message
by message, dated by each message’s own Date: header rather than by when you uploaded it, so the
archive interleaves with new mail in the right order instead of arriving as a lump at the top. The
received half can be run through the same AI pass as new mail, so an inbox you have had for six years
arrives already classified and searchable rather than as a pile you have to grep.
Every address resolves from day one. HEY’s extensions are the sharp edge of a cutover — each one has to exist at the new provider before the MX moves, or mail to it bounces. A Yowl organisation is a catch-all with no setting to switch on, so there is no list of addresses to recreate and nothing to forget.
And an AI reads all of it. Connect Claude to the organisation over MCP and it works the same inbox your team does — reads attachments, drafts the replies you send, flags what needs you. That is the thing HEY does not have an answer to, and it is worth doing the move for on its own.
One structural note before you start: HEY for Domains is one domain per account, and a Yowl organisation is the same — but a Yowl agent can be shared across several of your organisations, so a second domain does not mean teaching your AI everything twice.
The move itself
HEY for Domains hosts a whole domain’s mail. This guide is for that case — a personal @hey.com address
is a different problem, because you do not own the domain.
Four steps, two of which are tests rather than clicks. The generic cutover mechanics — why the MX is not really the switch — are the same for any provider and live on moving your mail; this page is the HEY-specific half.
1. Export first, and before cancelling
In a desktop browser: app.hey.com/accounts → Export Your Data. HEY emails you when it is ready — one
MBOX per account with all mail and attachments, contacts as a vCard, calendars as ICS. Do it for every
user on the domain, and open the MBOX in Thunderbird or Apple Mail to confirm it is complete before going
further.
⛔ Do this while the account is live, not after you cancel. You will find claims that HEY keeps your data for thirty days after cancellation. We could not find that anywhere in HEY’s documentation — the 30-day figures HEY does publish are a free trial of basic HEY, and a 30-day window to complete the for-Domains setup. Those are not a retention guarantee. Treat post-cancellation access as unavailable unless HEY support tells you otherwise in writing.
⚠ Often misread: HEY’s “we’ll never lock you in” promise is written around @hey.com personal
addresses — keeping the address, forwarding it onward. It says nothing about data on your own domain.
What the export does not carry: the Imbox, the Feed and the Paper Trail, Set Aside, Reply Later, labels, and the Screener’s approved and screened-out lists. None of that lives in the messages — it is HEY’s structure around them. If you rely on the Screener, write its blocked senders down now.
2. Stand up the new home before touching DNS
Every address that exists in HEY — users and extensions alike — has to resolve somewhere at the new provider before the MX moves, or mail to it bounces. A catch-all covers the long tail (how).
Publish the new provider’s DKIM record now. It sits under its own selector beside HEY’s and breaks nothing, which is what makes DKIM the safe record to add early (why).
⚠ While you are in the zone, check whether the domain is DNSSEC-signed — dig +short DS example.com. If
it is and you are also changing nameservers as part of this, the DS has to be withdrawn first or
the whole domain goes dark. A nameserver change is not part
of a HEY exit by default, but people often do both at once.
3. Read what HEY put in your zone
HEY’s wizard adds a verification TXT, DKIM, DMARC and the MX, with the MX last. The hostnames it used are only shown inside the wizard, so read your own zone rather than trusting a screenshot:
dig +short MX example.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT heymail._domainkey.example.com # or whichever selector the wizard gave youOnly the MX is the switch. Leave HEY’s DKIM record in place for a week after cutover — mail already queued at HEY still carries its signature. The verification TXT can go whenever.
4. Two things to test before you cancel
These are the two questions HEY’s documentation does not answer, which is exactly why you test them rather than assume.
Internal delivery. After changing the MX, send from one HEY user to another on the same domain. Google and Microsoft both keep delivering mail between their own users without consulting the MX while the domain is still on their books; whether HEY does the same is undocumented. If the test lands in HEY rather than the new inbox, remove the users — or the domain — from HEY to break it.
The domain claim. HEY’s help pages do not say whether a cancelled domain stays associated with the old
account. If the new provider ever refuses to verify the domain, that is the first thing to ask
support@hey.com to release.
5. Cut over, wait, cancel
Change the MX, then send to the domain from an outside account and watch it arrive. Keep HEY paid for at least a week afterwards: resolvers and gateways cache MX records for a day or two regardless of what you publish, and mail already queued to HEY keeps retrying there.
Cancel at app.hey.com/accounts → Billing & Invoices. Forward email out of HEY is a feature for
@hey.com addresses; on your own domain it has no use once the MX points elsewhere.
6. Bring the old mail across
New mail arrives at the new provider from the moment the MX changes. The archive is a separate act, and at most providers it is the act that never happens — which is why “export first” is step 1 and why so many people end up with a folder of MBOX files they never open again.
Upload each MBOX to Yowl and it is read in message by message, each one dated by its own Date:
header so the archive lands in order beside your new mail rather than as a block at the top. Sent and
received are told apart by the domain, not by which mailbox the file came from. Run the AI pass over
the received half and six years of mail arrives classified.
Worth knowing HEY never imported your old mail into itself when you arrived, so if you have been there a while, this is the first time that archive has actually followed you.