Personal Domains

How to make your email provider replaceable with a custom domain

Print the domain. Treat the mailbox as a remappable dest. One MX set. Leftover hosts gone.

MailerZ editorial · Secuno LLC16 min read

Email provider independence on a custom domain starts with a hop you can prove, not with a vendor adjective. Keep the inbox you already trust. Print addresses on a domain you own. Publish one MX set. Hold unknowns unless a dated cutover says otherwise. Pay for send-as only if the From must travel. Leftover MX is a hard stop. The point is to own the public identity so the mailbox vendor can change later.

One exclusive MX set versus leftover hosts that lock you to an old email provider
Prove inbound from another mailbox before you print a new string.

Quick answer

Treat replaceability as a testable hop. Name the store you search, the public local-parts you print, and the single inbound operator. Keep Gmail or Outlook as the mailbox. Point MX at one forwarder. Delete leftover hosts. Prove inbound from a mailbox that is not the destination. When those four facts are true, you can remap a dest or change the forwarder without reprinting the homepage. That is email provider independence on a custom domain.

MailerZ fits that job: inbound MX plus optional authenticated SMTP around an inbox you already use. Envelope SRS only. Header From, Subject, Date, Message-ID, body, and MIME stay intact. It is not Google Workspace, not IMAP, and not an open relay. Unauthorized send is SMTP 550 / 550 5.7.1. It is not a Gmail replacement and not a compliance badge.

MailerZ Free is one domain, ten aliases, one seat, a 14-day store, send-as Off, SMTP Off, API Off, and unrouted mail held or rejected only. Solo is $40 per year only: 5 domains, 25 aliases, 2,500 outgoing per month. Starter is $8 monthly or $80 yearly. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99 monthly or $990 yearly. Confirm live numbers on MailerZ pricing. Those ceilings are capacity, not an inbox-placement promise.

Transport still follows IETF RFC 5321 — Simple Mail Transfer Protocol. Client attach steps live in Google Gmail Help — Send mail from a different address. Domain lookups still follow IETF RFC 1035 — Domain names. Those documents win when a UI label disagrees with a blog screenshot.

The real decision

Lock-in is usually a printed string, not a contract clause. If the homepage says you@gmail.com, leaving Gmail means a reprint, a vendor chase, and a year of “the old address bounced.” If the homepage says hello@yourdomain and MX still sits on Google Workspace, leaving Workspace means a DNS fight you postponed. The replaceable design puts the durable name on your zone and treats the mailbox as a dest you can remap.

Readers usually have one of four jobs: keep a printed role, stop a flood, send as the domain, or migrate without a silent split. If you cannot pick one job, you will buy a suite and a forwarder and still miss mail. The expensive wrong turn is a mailbox seat per printed name when you only needed a named route. The fragile wrong turn is registrar forwarding with no hop history. The noisy wrong turn is catch-all into the same inbox you use for invoices.

Agencies copy one habit across the book of business. One noisy client teaches a house default that floods everyone. Per-domain policy beats a house religion. Capacity on Agency is for more zones and aliases, not for giving up on names.

Developers want the feature live before nameservers are honest. A green plugin or a verified TXT is not delivery. If the authoritative nameservers still publish leftover suite MX, customers never hit your new map.

Decide before you publish MX
QuestionIf yesIf no
Can you list the printed addresses?Create named aliases for that list.Do not enable catch-all to hide the missing list.
Must replies show the domain?Pay for send-as after inbound proof.Stay on Free for receive-only.
Is leftover MX still public?Stop. Delete it. Then continue.Probe from another mailbox.
Can you remap dest without reprinting?The provider is already replaceable.The printed string is still the lock.

Prove one domain before you scale the same pattern to a client book.

Start free — one domain

Technical mail flow

A sender looks up MX on the nameservers that actually answer, offers an envelope recipient, and transfers content. Replaceability does not replace that sequence. Envelope commands are not the header block people see. MailerZ may rewrite only the envelope return path with Sender Rewriting Scheme so the next hop can pass SPF.

Header From on inbound stays the original author so DKIM and DMARC still describe that author. If some other forwarder rewrote From, authentication gets noisier. Do not add a third vendor to compensate. Cut leftover hosts. Then read original headers if you need proof.

Mail flow: exclusive MX, envelope SRS, unchanged Header From, remappable destination inbox
Envelope SRS is the allowed rewrite. Header From stays original on inbound.

Three objects you can swap independently

The destination inbox is where humans search next year. You can change it by remapping an alias. The inbound operator is who answers MX. You can change it by publishing a new exclusive set after a save-and-cut. The send identity is who may leave as From. You can change it by rotating SMTP on a paid plan. Mixing those three into “the email provider” is how people think they must move Calendar to change hello@.

Outbound is a second hop. Authenticated SMTP proves a credential may send as an approved identity. Creating an inbound alias does not grant send-as. Catch-all does not mint outbound identities. Unauthorized or unhosted send is 550.

DNS starts at NS, not at the prettiest registrar panel. If nameservers are at Cloudflare, the registrar zone editor is a copy nobody queries. A replaceability plan that ignores NS will keep reproducing leftover MX tickets. TTL and resolver cache lie for a while. Check more than one public view. Then probe. Self-send from Gmail to the same Gmail account can short-circuit and hide the path you are trying to prove.

Step-by-step setup

Do this as a list you can fail in public. Save the old MX set. Look up NS. Open that vendor. Add verification TXT. Recreate named aliases. Publish only the MX MailerZ shows. Delete leftovers. Probe from another mailbox.

  1. Write the job in one sentence

    Example: “Keep Gmail. Print hello@ and billing@. Change dest later without a reprint.” That sentence excludes a suite if nobody needs Calendar as the system of record.

  2. Look up NS and name the live DNS vendor

    Edit only that panel. A responsible-looking registrar screenshot is worthless if Cloudflare answers the internet.

  3. Add and verify the domain

    Recreate printed aliases. Map destinations you already read. Do not start with catch-all.

  4. Publish one MailerZ MX set

    Delete leftover suite, routing, and registrar MX. Save the old set first. Help lives on troubleshooting.

  5. Probe each named alias

    Unrelated mailbox. Unique subject. Confirm Header From and delivery history. Empty history is leftover MX or an unnamed local-part.

  6. Prove you can remap dest

    Point one lab alias at a second inbox you control. Probe again. Put it back. That remap is the replaceability test. If you cannot do it, you still locked the store to the printed name.

  7. Decide send-as separately

    Pay if the From must travel. Free has none. Copy host, port, and TLS together. Set From to an identity you created. Gmail’s labels are in Google Gmail Help — Send mail from a different address.

  8. Leave unknowns held

    Review the store. Promote a real leftover. Enable paid catch-all only with a written end date. Schedule a review after any registrar, nameserver, plugin, or staff change.

Related hubs: email forwarding, aliases and catch-all, send and reply. Field maps live in the docs. If a doc and pricing disagree on limits, pricing wins.

Failure modes and proof

How replaceability fails
SymptomLikely causeWhat to check
Map is perfect, customers vanishLeftover MX.Public lookup from two resolvers.
Screenshots look responsibleWrong DNS panel.NS, then that vendor’s zone.
Gmail stays greenSelf-send theater.Second provider. Unique subject.
AUTH works, From is 550Local-part never approved.Named identity. Catch-all is not send-as.
Cannot leave Gmail laterHomepage still prints @gmail.com.Print the domain. Remap dest.
Client harvest in agency inboxOne catch-all for the book.Per-zone maps. Revoke at offboard.

Use a public MX view before you cut. Leftover hosts split mail even when one resolver looks clean.

Open leftover MX troubleshooting

Secret hygiene is part of replaceability. A Gmail password in WordPress, or one SMTP credential across every client, is how a swap becomes an incident. Rotate. Do not mail the password to support. Send a 550 line, a timestamp, and a Message-ID.

Scope theater is asking MailerZ to be an archive, a suite, or 100 percent inbox placement because this title sounded like a guarantee. It is not. The 14-day Free store, 90-day Solo through Agency store, and 180-day Unlimited store are recovery windows for hops this layer saw.

MailerZ workflow and product boundary

Add a domain, map names, cut leftover MX, read mail in Gmail or Outlook, inspect hops, recover inside the published window. That is the workflow. It is not a hosted login on the domain.

MailerZ as a delivery layer around an inbox you already use
Delivery layer around an inbox you already use. Not a suite.

Compare pages exist when the other product is inbound-only routing, a privacy mask, or a full suite. Cloudflare Email Routing is inbound routing. A privacy-mask product hides a destination on a provider domain. A suite hosts mailboxes, Calendar, and admin. Cite their docs. Do not invent feature parity. MailerZ is the delivery layer when you already have Gmail or Outlook and you need a domain route you can prove.

Tools on this site help you see leftover MX and practice routing. They do not write your DNS. Support will ask for lookups and Message-IDs, not passwords. Legal questions have published answers on security, privacy, terms, DPA, and subprocessors. If counsel wants eDiscovery, buy eDiscovery.

Cost and alternatives

The usual cost of a locked provider is time on leftover MX and reprinting, not the invoice. An afternoon of split mail costs more than Solo. Confirm pricing before you promise a client volume.

Suite seats are correct when every person needs a hosted login, Calendar, and admin. They are the wrong buy when you needed three roles into one inbox. Privacy-mask subscriptions are correct for per-site random addresses on a provider domain. They are the wrong buy when customers must write hello@ on a domain you own. Transactional vendors are correct for receipts at volume. A contact form on Solo is a different job. Bulk marketing tools are out of scope.

Stay on Free while inbound is the question. Upgrade when send-as, a longer store, more domains, or paid unknown-mail forward is the question. Solo at $40 per year is the first paid ceiling. Agency pricing buys capacity across many zones. It does not buy a wildcard culture or an inbox SLA.

If you are mid-migration, overlap in time with a saved old MX set, not overlap as two live primaries. Priority numbers are an order, not load balancing. Plus addressing on Gmail is not a custom-domain alias. Two personal zones still need two MX cuts and two short lists.

Worked examples

Two founders answering from personal Gmail

The homepage printed founder names. Customers wrote whichever they remembered. Leaving Gmail later meant two reprints. They created hello@ on the domain, mapped it to both dests after they named a reply owner, cut leftover registrar MX, and probed from another mailbox. The next dest change was a remap. The homepage did not move.

The agency that treated Workspace as the identity

Every client zone still had Google MX “because Calendar.” Calendar lived on the agency’s own domain. Client mail could have been aliases. They saved MX, published MailerZ on a lab zone, proved inbound, then repeated per client. Offboard now means delete MX they own and revoke SMTP. The client keeps the printed names if they take the zone.

The form that sent before MX was honest

A plugin was green. TXT was verified. Public MX still pointed at Microsoft. They thought the provider was already replaceable. Customers never hit the map. They deleted the leftover, waited for two views, probed, then attached paid SMTP. Send-as was never the first problem.

The leak that proved the design

A vendor dumped shop-west@. They disabled that local-part, held unknowns, created shop-east@ after they would print it, and left hello@ and MX alone. The dest inbox did not change. That is what replaceability is for: kill a prefix without migrating a store.

Write the last change on a sticky note before you open the dashboard. Nameserver move, leftover MX, new form plugin, contractor laptop, or a registrar forwarding toggle are the usual five. MailerZ history only shows hops that reached this layer. If the sticky note says leftover MX, you do not have a replaceability mystery. You have a split. Delete the leftover. Wait. Probe again.

Print the public list. If you cannot print it, you are not ready for production unknowns and you are not ready for a bigger alias ceiling. Unlimited aliases as marketing will not save a missing list. Three named aliases on Free are enough to stop printing a personal Gmail on a homepage. Grow the list when a real person used a leftover, not when a harvest guessed admin@.

What to tell a client: we will print a short list, cut leftover MX, and hold unknowns. We will not promise that every guessed spelling works. We will not invent badges. What belongs in a ticket: public NS, public MX, alias map, probe subject, Message-ID, visible Header From, plan name, and whether send-as is enabled. What does not: passwords, seed lists, or a demand for Primary.

If two people must read one role, name the reply owner before you add a second destination. Fan-out of catch-all is how you train two spam buttons. If a form or cron must send, pay first, copy the dashboard pair, rate-limit the app, and revoke at handover. PHP mail() on the web host is a reputation gift to strangers.

Quarterly review is enough when nothing moved. Review sooner after a nameserver change, a plugin swap, or a staff departure. When this page is closed, the next physical action is a lookup and a probe, not another comparison tab.

Switching the destination later is a remap. Switching the inbound operator later is a new exclusive MX set after you save the old one. Do not do both in the same hour unless you enjoy two mysteries. Remap dest first if the human changed. Cut MX first if leftover hosts still answer. Send-as rotate is a third hour if a secret lived on a laptop. That separation is how replaceability stays boring instead of becoming an incident with three owners.

What dest remap does not move

Remapping hello@ from Gmail to Outlook proves the public string is replaceable. It does not move Gmail filters, labels, vacation responders, or the OAuth tokens a CRM already has for that Gmail. Those objects stay on the old store until you recreate them. MailerZ never saw them. The next invoice still recovers to whichever login you left on the vendor portal.

Print a dest-debt list the same hour you remap: filters you still need, vendor recoveries, calendar subscriptions, and any SMTP pair attached only on the old composer. Then probe the new dest from another mailbox. Confirm MailerZ pricing only if send-as must move with the human. The hop is replaceable when MX and the alias stay. The store is replaceable only after that dest-side list is empty or rewritten.

FAQ

What does it mean to make an email provider replaceable?
It means the printed addresses live on a domain you control, MX points at one inbound operator you can change, and the mailbox you search is a destination you can remap. Customers keep writing hello@yourdomain. You can swap Gmail for Outlook, or one forwarder for another, without reprinting the homepage.
Does this require a new mailbox?
No. MailerZ is Mail Box portal webmail (Inbox, Sent, New email). It is not IMAP or POP. Gmail or Outlook remains the store unless you separately buy a hosted mailbox product. Replaceability is about the public identity, not a second reading pane.
Will it work with Gmail or Outlook?
Yes as destinations. Inbound lands there when MX is exclusive and the alias is named. Branded replies need a paid plan with send-as, plus Gmail Send mail as or a manual Outlook SMTP identity. Free has no send-as.
What DNS records are involved?
A verification TXT, one MailerZ MX set on the nameservers that actually answer, leftover host MX removed, and SPF, DKIM, and DMARC if you also send as the domain. Edit the live NS vendor, not a leftover registrar copy.
What should I test before I call the provider replaceable?
Send a uniquely titled message from an unrelated mailbox into each printed alias. Confirm Header From and delivery history. Then remap one alias to a second dest you control and prove it again. Self-send can hide both tests.
Can I keep two MX operators for safety?
No. Priority numbers are an order, not load balancing. A leftover Google or Microsoft host will keep accepting mail the new map never sees. One inbound owner. Save the old set, then delete it.

Key takeaways

  • Print the domain. Treat the mailbox as a remappable dest.
  • One inbound operator. Leftover MX is a hard stop.
  • Gmail or Outlook stays the store. MailerZ is not IMAP.
  • Free proves inbound. Solo $40/year starts send-as.
  • Hold unknowns unless a dated cutover says otherwise.
  • Edit the live NS vendor, not a leftover registrar copy.
  • Prove a dest remap before you call the provider replaceable.
  • Do not send passwords to support. Limits are not an inbox SLA.

Conclusion and next action

Make the provider replaceable by owning the printed names and a single MX operator. Keep the inbox you already search. Cut leftovers. Probe from somewhere else. Pay for send-as only if From must travel. Remap dest when a person or vendor changes. That is the runbook. It is not a suite migration and not a Gmail replacement.

Next action: look up NS, edit that panel, publish one MX set, send a uniquely titled probe from another mailbox. Start free on one domain you can break. Sign in if the zone already lives here.

Prove the hop

Start free with one domain and test inbound first.

Cut leftover MX. Hold unknowns. Pay only if the From must travel.

Review quarterly, or sooner if provider behavior, pricing, or MailerZ scope changes. Author: MailerZ editorial, Secuno LLC.