How to validate every alias after an email migration

Quick answer for validate aliases after migration

Start with the old export, not memory. Spreadsheet, ImprovMX dump, Workspace alias list, registrar forwards — whatever you had. Sort it. Diff against MailerZ named aliases. The leftover names are the risk.

Probe from another provider. Gmail-to-Gmail can skip public MX. Each subject should include the local-part and a nonce. When the destination thread is a mess of identical “test,” you cannot map failures.

Open history per probe. Empty row: leftover MX or the name never arrived. HOLD: Free unknown or you did not create the alias. Accept 550: recipient policy. 250 then destination 5xx: Gmail or Outlook. Copy the line.

Do not enable paid catch-all FORWARD to “finish validation.” FORWARD will deliver typos and skip the lesson. Validate named aliases first. FORWARD is a later product choice.

Send-as is not validation of inbound aliases. An identity that can send may still have been missing inbound. Do inbound first. Free cannot send anyway.

Transport is still IETF RFC 5321 — Simple Mail Transfer Protocol. Aliases and catch-all. Migration planner. Troubleshooting.

The real decision

Teams validate the logo address and ship. The addresses on invoices, job posts, and Apple Developer accounts were never created. Those failures arrive as “customers say they emailed us” weeks later.

The other trap is treating plus addressing as an alias. MailerZ does not claim to strip plus tags on custom domains. If you printed founder+stripe@, create that local-part or stop printing it.

Shared destinations make people lazy. Three aliases to one Gmail is fine. You still need three probes. History is per recipient, not per destination.

Agencies validating “the client domain” as one checkbox will miss the ten role names on the printed letterhead.

When this path is enough

• You have an export to diff.
• You will probe every critical name from another mailbox.
• You will read HOLD as a missing name.
• You will keep catch-all off until the map is proven.

When this is the wrong ticket

• You will only test hello@.
• You will use self-send.
• You will turn on FORWARD to hide gaps.
• You need IMAP search as proof. The destination inbox is the store; history is the hop.

Technical mail flow

Each probe is its own SMTP conversation to the MX. MailerZ accepts or holds or refuses that recipient. Then it forwards to the destination if policy allows. Header From stays the probe sender. Envelope is SRS.

A missing alias on Free is a hold row. That is success for validation — you found the gap. Create the name. Re-probe.

Leftover MX makes every probe empty. Stop validating aliases until MX is exclusive. You would be validating the old hop.

Destination filters can drop a probe after 250. That alias’s inbound hop worked. Fix Gmail, not MX.

Retention: 14 days Free, 90 paid. Export the pass packet if the audit will last longer.

Step-by-step decision path

1. Collect the old export Every local-part, destination, and printed variant.
2. Diff against MailerZ aliases Create missing names. Do not FORWARD yet.
3. Confirm exclusive MX Two resolvers. No leftovers. Else stop.
4. Build the probe list Critical first: billing, legal, jobs, registrar, IdP.
5. Send unique subjects from another mailbox One nonce per name.
6. Record history and destination for each Pass requires both.
7. Create and re-probe holds Until the diff is empty for critical names.
8. Only then consider paid FORWARD Optional. Not a validator.

Worked examples

A shop had twelve printed names and three MailerZ aliases. Nine HOLDs. They created the nine. Re-probes passed. Catch-all stayed off.

Jobs@ was a leftover Google group. Exclusive MailerZ MX made it empty history. They created jobs and pointed it at the hiring Gmail. The group was not a hop.

An agency used one “client test” address for five domains. They learned nothing. They switched to per-domain probe lists.

A founder probed from the same Gmail destination. Everything “worked.” A customer on Outlook never arrived because leftover MX remained. They fixed MX, then re-validated.

Plus-looking tags on receipts were never aliases. They printed a real billing@ and updated Stripe.

Failure modes and proof

MailerZ workflow and product boundary

Secuno LLC operates MailerZ. Site: mailerz.net. App: mail.mailerz.net. Envelope SRS only. Header From, Subject, Date, Message-ID, body, and MIME are never rewritten. Not IMAP. Not an open relay.

What MailerZ does

• Accept MX for verified domains.
• Rewrite envelope MAIL FROM with SRS on the forward.
• Leave Header From and MIME intact.
• Hold unknowns on Free. Optional paid FORWARD.
• Paid SMTP from approved identities. Dashboard SPF, DKIM, and DMARC instructions.
• 550 for unauthorized From. Not an open relay.

What MailerZ does not do

• Guarantee Gmail Primary or any inbox placement rate.
• Host IMAP, webmail, or Calendar.
• Send-as on Free.
• SOC 2, ISO 27001, HIPAA, review counts, or an uptime SLA. Controls: Security and Trust Center.

Plans: pricing. Free $0, 1 domain, 3 aliases, 1 seat, 14-day store, send-as disabled, SMTP and API disabled. Solo $40/year, 3 domains, 15 aliases, 90-day, 1,000 outgoing, 5/hour. Starter $8 or $80, 5/50/5, 2,000, 10/hour. Business $19 or $190, 25/200/25, 4,000, 15/hour. Agency $39 or $390, 100/500/50, 8,000, 25/hour. Unlimited is $99/month or $990/year. Annual Starter, Business, and Agency include two months free versus monthly. Solo is yearly only.

Cost, alternatives, and trade-offs

Field notes

Critical means money, identity, and legal — not every historical typo.

Printed PDF invoices from last year still send to those addresses. Diff those PDFs.

Apple, Google, and Microsoft developer accounts are aliases people forget.

Registrar WHOIS/account email is often a role name. Probe it.

Do not validate send-as in the same sitting if inbound is still red.

Solo’s 15 aliases may force you to drop museum names. That is a product decision. Record the drops.

Starter is 50 aliases. Count before you promise “we kept everything.”

Keep the probe mailbox. You will use it again after the next helpful MX restore.

Treat validate aliases after migration as a ticket with artifacts, not a vibe. Ask for public MX from two resolvers, a received copy, and MailerZ history before anyone edits TXT.

Write a one-paragraph policy for How to Validate Every Alias After an Email Migration: inbound versus outbound, what you will not do (dual MX, From rewrite, second SPF), and who owns DNS.

Self-send is invalid for validate aliases after migration. Gmail can short-circuit. Use another mailbox and a unique subject.

Leftover MX masquerades as validate aliases after migration. Empty history means the hop never ran. Delete aspmx, Microsoft, and registrar MX. Wait TTL.

Free HOLD and missing aliases look like outages. History shows the hold. Create the named local-part. Catch-all FORWARD is paid and optional — not a debugger.

Paid send-as is a different hop. Free cannot send. Unauthorized From is 550 / 550 5.7.1. DNS will not authorize a From the product has not approved.

How to Validate Every Alias After an Email Migration does not include an inbox placement SLA, review counts, or Primary. Say that early.

Proof packet for validate aliases after migration: two-resolver MX, inbound copy with Header From, Authentication-Results, outbound copy if they send, plan name, SMTP line if anything refused.

Retention is 14 days on Free and 90 on paid. Export headers while they live. The destination inbox is the archive.

Agencies should not blend clients in one validate aliases after migration thread. Agency limits are 100 domains, 500 aliases, 50 seats, 8,000 outgoing, 25/hour — still not an SLA.

No SMTP passwords in the validate aliases after migration ticket. No invented SOC 2. Controls live on the Security and Trust Center.

If two products share MX, stop adding records. Exclusive MX is a hard stop. validate aliases after migration cannot be correct on a split path.

If Header From is rewritten, stop tuning SPF for validate aliases after migration. Change the hop. MailerZ will not offer a From-replace control.

If the customer wants Calendar, sell a suite. If they want a hop, sell a hop. How to Validate Every Alias After an Email Migration is not Exchange.

Hourly and monthly send-as ceilings (disabled/1,000/2,000/4,000/8,000 outgoing; 5/10/15/25 per hour) produce refuses that look like validate aliases after migration. Read counters.

Null MX plus a real MX is a lie. Remove the lone-dot refuse if you intend to receive.

After any change for validate aliases after migration, wait TTL, probe from another mailbox, and store the new received source next to the MX screenshot.

Write validate aliases after migration in the subject and the layer in the first sentence: leftover MX, HOLD, destination 550, or TTL. Honest first sentences shrink tickets.

Monthly for validate aliases after migration: leftover MX lookup, one external inbound probe, send-as counters if paid. Five minutes. The outage you avoid is a Friday dual-MX restore.

When two vendors disagree about validate aliases after migration, believe two resolvers, one received copy, and one history row. Registrar dots lie. Composer UIs lie.

Teach the next hire the MailerZ split before they touch validate aliases after migration: envelope may change, Header From must not, Free cannot send, unknowns HOLD, leftover MX is a hard stop.

If validate aliases after migration appears in an RFP, answer with published caps and hop evidence. Decline inbox-rate clauses and fake certifications.

Do not bundle unrelated edits with validate aliases after migration. Rotating SMTP while republishing MX while enabling FORWARD is how you lose the ability to name the failure.

Field story 1 for validate aliases after migration: A shop had twelve printed names and three MailerZ aliases. Nine HOLDs. They created the nine. Re-probes passed. Catch-all stayed off. Keep it in the runbook.

Field story 2 for validate aliases after migration: Jobs@ was a leftover Google group. Exclusive MailerZ MX made it empty history. They created jobs and pointed it at the hiring Gmail. The group was not a hop. Keep it in the runbook.

Field story 3 for validate aliases after migration: An agency used one “client test” address for five domains. They learned nothing. They switched to per-domain probe lists. Keep it in the runbook.

Field story 4 for validate aliases after migration: A founder probed from the same Gmail destination. Everything “worked.” A customer on Outlook never arrived because leftover MX remained. They fixed MX, then re-validated. Keep it in the runbook.

Field story 5 for validate aliases after migration: Plus-looking tags on receipts were never aliases. They printed a real billing@ and updated Stripe. Keep it in the runbook.

For validate aliases after migration, “All probes empty” usually means Leftover MX. Isolate with Stop; fix DNS. One change at a time.

For validate aliases after migration, “Some HOLD rows” usually means Names not created. Isolate with Create; re-probe. One change at a time.

For validate aliases after migration, “250 then Gmail 5xx” usually means Destination refuse. Isolate with Copy SMTP; leave MX. One change at a time.

For validate aliases after migration, “Catch-all “passes” everything” usually means FORWARD hiding gaps. Isolate with Turn it off; diff. One change at a time.

For validate aliases after migration, “Self-send passes” usually means Invalid evidence. Isolate with Other mailbox. One change at a time.

For validate aliases after migration, “Old export lost” usually means You are guessing. Isolate with Scrape letterhead, invoices, DNS TXT SPF includes for clues. One change at a time.

Setup step “Collect the old export” for validate aliases after migration: Every local-part, destination, and printed variant. Skip it and How to Validate Every Alias After an Email Migration becomes next week’s ticket.

Setup step “Diff against MailerZ aliases” for validate aliases after migration: Create missing names. Do not FORWARD yet. Skip it and How to Validate Every Alias After an Email Migration becomes next week’s ticket.

Setup step “Confirm exclusive MX” for validate aliases after migration: Two resolvers. No leftovers. Else stop. Skip it and How to Validate Every Alias After an Email Migration becomes next week’s ticket.

Setup step “Build the probe list” for validate aliases after migration: Critical first: billing, legal, jobs, registrar, IdP. Skip it and How to Validate Every Alias After an Email Migration becomes next week’s ticket.

Setup step “Send unique subjects from another mailbox” for validate aliases after migration: One nonce per name. Skip it and How to Validate Every Alias After an Email Migration becomes next week’s ticket.

Setup step “Record history and destination for each” for validate aliases after migration: Pass requires both. Skip it and How to Validate Every Alias After an Email Migration becomes next week’s ticket.

Setup step “Create and re-probe holds” for validate aliases after migration: Until the diff is empty for critical names. Skip it and How to Validate Every Alias After an Email Migration becomes next week’s ticket.

Setup step “Only then consider paid FORWARD” for validate aliases after migration: Optional. Not a validator. Skip it and How to Validate Every Alias After an Email Migration becomes next week’s ticket.

Trade-off on validate aliases after migration: Probe every critical name gets Known map and gives up An hour. Write that on the quote.

Trade-off on validate aliases after migration: Hello@ only gets Speed and gives up Silent role addresses. Write that on the quote.

Trade-off on validate aliases after migration: Catch-all as validator gets Comfort and gives up Hidden misses. Write that on the quote.

Trade-off on validate aliases after migration: Buy seats per alias gets IMAP per name and gives up Cost; leftover MX if you also forward. Write that on the quote.

Building a probe list that survives an audit

Critical names are money, identity, and legal. Billing, invoices, receipts, registrar, IdP, Apple and Google developer, jobs, legal, security, and the address on the printed letterhead. Historical newsletter typos are not critical unless they still print. Write the drop list on purpose so FORWARD cannot sneak them back.

Each probe subject should be ugly and unique: local-part, date, and a nonce. “test” is how five people collide in one Gmail thread and nobody can map a HOLD. The destination copy and the hop row must share that nonce. If either is missing, that name is not validated.

Scan PDFs. Last year’s invoice footer still sends. So do contract signature blocks and the WHOIS abuse contact. Those strings are aliases whether they are in the export or not. If you cannot find an export, scrape those surfaces first. Guessing from memory is how legal@ stays on the old hop.

Shared destinations do not reduce probes. Three names to one Gmail still need three hop rows. MailerZ policy is per recipient. A pass on hello@ does not create billing@. People skip this because the inbox “already got a test.” The inbox is not the policy engine.

HOLD is a gift on Free. It is the validator. Paid FORWARD as a shortcut turns every typo into a pass and every missing printed name into a silent success. Validate named aliases with HOLD visible. Decide FORWARD later as a product choice, not as a way to finish Friday.

Destination 5xx after 250 is a pass for the alias and a fail for Gmail or Outlook. Do not recreate the alias. Do not republish MX. Copy the SMTP line into the ticket and work the destination. Validation dies when you treat every miss as a missing name.

Plan math: twenty critical names will not fit Free. They will not fit Solo’s fifteen. Starter is fifty aliases. Count before you schedule the probe afternoon. Dropping museum names is valid. Pretending Solo holds twenty is not.

Keep the probe mailbox. After the next helpful MX restore you will run the same list in twenty minutes. Recreating the list from Slack is how the second validation is worse than the first.

Send-as identities are a second list. An address that can send on a paid plan can still have failed inbound validation. Do not check Gmail Send mail as until HOLD rows are gone and leftover MX is gone. Free cannot send, so a Free proof week should not include outbound rows at all. When you do send, target a second external inbox, not the destination Gmail you already used as the inbound store.

Write a one-line policy for plus-looking local-parts. MailerZ does not claim to strip plus tags on custom domains. If receipts still print founder+stripe@, either create that exact local-part or change the printed address to a named alias you actually created. Validation that ignores printed strings is theater.

FAQ

Key takeaways

• Diff the export first.
• Probe every critical name.
• History plus inbox is a pass.
• HOLD means create the alias.
• FORWARD hides gaps.
• Self-send is invalid.
• Fix leftover MX before validating.
• Send-as is a later test.

Conclusion and next action

A migration is not done when MX is exclusive. It is done when the printed names have hop rows. Until then you have a logo address and a rumor.

Keep the probe list next to the rollback card. The next hire will thank you when someone restores Google MX.

If the diff is huge, drop museum names on purpose. Do not FORWARD your way past the decision.

Review quarterly, or sooner if DNS hosts or dashboard instructions change. Author: MailerZ editorial, Secuno LLC.