Deliverability & Spam

Email forwarding deliverability checklist before going live

Routes before MX. Probe before the homepage. Dual MX is not a gate you pass.

MailerZ editorial · Secuno LLC17 min read

An email forwarding deliverability checklist is a go-live gate, not a promise that Gmail will file Primary. Confirm exclusive MX, named aliases, HOLD for unknown, intact Header From, and a third-mailbox probe with readable Authentication-Results. Keep lists off reply SMTP. MailerZ will not print an inboxing percentage. Anyone who sells you one on a forwarder is selling a folder they cannot see.

Email forwarding deliverability checklist gates before MX cutover
Records and a probe come before announcing the alias on a homepage.

Quick answer for email forwarding deliverability checklist

Go-live is when you print the address on a site, invoice, or App Store listing. After that, leftover MX is a customer incident. The checklist exists so you do not learn that in public.

SPF policy lives in RFC 7208. It does not assign a Primary tab. Publish sending records once, correctly, if you send. Do not stuff includes you do not own.

Inbound deliverability starts with who answers MX. Two owners means two stories. Delete the old set. Priority tricks are not deletion.

Named aliases beat catch-all for a launch. You can explain hello@ and billing@. You cannot explain why garbage local-parts arrived and trained junk.

The probe is the last gate. If you cannot open original on a third mailbox, you are not live. You are hoping.

Soft CTA after the gates: start free with one domain and run the same checklist on MailerZ. Do not skip leftover MX because the panel looks pretty.

Authoritative mail transport is defined in IETF RFC 7208 — Sender Policy Framework (SPF). Product path: email forwarding, features, and troubleshooting.

User problem and decision criteria

Teams want to “just point MX” on a Friday. Decision criteria: can you screenshot the old MX, are aliases created first, is HOLD on, is there a third mailbox, is send-as even needed this week.

Criteria that do not belong: dual MX, catch-all FORWARD for leads, a promised inbox rate, or launching send-as on Free.

Agencies should refuse to publish MX until the alias sheet exists. Routes before cutover. That is also the migration rule for larger moves.

If marketing wants a newsletter from the same SMTP, stop the launch. Caps and filters are not a checklist item you waive with optimism.

If legal wants a DPA, send them to the data-processing page. Do not invent SOC 2 on the checklist.

If the domain is new, warn that reputation time is not a MailerZ defect. Still run the checklist. Still do not dual-publish MX to “be safe.”

If someone already printed the address on packaging, you are in incident mode. Run the same gates, but treat leftover MX as a hard stop today, not next sprint.

Shared passwords to an old host are how leftover MX returns. Document who can edit DNS. Authoritative nameservers, not a random registrar bookmark.

Technical mail flow

Deliverability checklist mail flow
One MX owner, SRS envelope, intact From, then a destination folder you record as observation.

Create aliases and destinations first. Mail to an unpublished MX still has nowhere useful to go if the map is empty.

Publish exclusive MailerZ MX. Wait for what public resolvers show, not for a panel checkmark.

Probe from a third mailbox. Read history. Confirm Header From. Note folder as observation.

If you send, copy dashboard SMTP and publish the dashboard trio once. One SPF string.

Only then print the address. The checklist order is the product.

Step-by-step setup / decision path

Checklist order before going live
MX, aliases, HOLD, probe, then publish the address.
  1. Inventory public aliases and destinations in a sheet. No orphans.
  2. Screenshot old MX and NS. Store it for rollback.
  3. Create named aliases in MailerZ. Confirm destinations.
  4. Leave unknown on HOLD. Do not FORWARD to look busy.
  5. Publish exclusive MX. Delete leftovers including null MX if you meant to receive.
  6. Verify TXT ownership. Do not confuse it with SPF.
  7. Probe each public alias from a third mailbox. Save Message-ID and folder.
  8. If sending, copy dashboard SMTP. Stay under plan caps. No lists.

If any probe fails, you are not live. Classify leftover MX, unknown recipient, or destination 5xx. Do not announce.

If probes pass and junk appears, you are live on the hop and negotiating a folder. That is a different ticket. Do not roll back MX for junk alone.

Write the checklist result in the launch notes so the next person does not “improve” DNS on Monday.

Failure modes and proof

MX first, aliases later: 550 on launch day. Proof: history names missing local-parts.

Leftover Google MX: random arrival. Proof: two owners.

Catch-all FORWARD at launch: junk by week two. Proof: random local-parts.

Self-send only: false go-live. Proof: no third mailbox.

Duplicate SPF: permerror. Proof: two v=spf1.

List blast as first send: cap and filters. Proof: volume versus Solo.

Header rewrite vendor: users see the wrong From. Proof: original headers. Do not pick that vendor.

Null MX left in place: all inbound rejected. Proof: public MX 0 .

TTL ignored: some regions still hit old hosts. Proof: two resolvers disagree.

Announced URL before probe: public incident. Proof: support tickets before history.

Free send-as attempt: AUTH or product refuse. Proof: plan.

Promised inbox rate on the launch deck: fiction. Remove it.

MailerZ workflow and product boundary

MailerZ is custom-domain aliasing and forwarding with optional paid send-as. Secuno LLC operates mailerz.net. The app is mail.mailerz.net. Not Workspace, not IMAP, not an open relay, not a campaign ESP.

Envelope SRS only. Header From, Subject, Date, Message-ID, body, and MIME stay intact. Exclusive MX. Hold unknown on Free. Copy SMTP host, port, and TLS or STARTTLS from the dashboard when you send. Do not invent 587 or 465 as MailerZ facts.

Free: one domain, three aliases, one seat, fourteen-day store, fifty outgoing a month, no send-as. Solo forty dollars a year, fifteen aliases, ninety-day store, one hundred outgoing, five send-as per hour. Starter eight monthly or eighty yearly. Business nineteen or one hundred ninety. Agency thirty-nine or three hundred ninety. Quote the pricing page. No SOC 2, ISO, HIPAA, SLA, or inboxing percentage.

The checklist is how MailerZ expects you to cut over: routes, exclusive MX, HOLD, probe, optional send-as. Features and delivery recovery exist so the probe has artifacts.

Cost, alternatives, and trade-offs

A delayed launch costs less than leftover MX on a printed box.

Workspace is the right spend if you need a suite. It is the wrong spend if you only needed this checklist.

A second forwarder for backup violates the exclusive MX gate. You pay for outages.

Agencies should bill the checklist as a named deliverable. It prevents the unpaid weekend.

Seed lists are optional and still not a guarantee. Do not put their folder on a slide as the market.

Catch-all off is free deliverability hygiene for the destination.

If you skip history because Free aged out, you skipped evidence. Probe again inside the window.

Honest copy on the site beats a fake inbox number that sales will have to walk back.

Operational depth for the go-live checklist

Print the checklist as a gate in the project plan, not as a blog you skim. The person who can edit NS must be in the meeting. If they are on holiday, you are not going live. A pretty MailerZ map with leftover Google MX is a split-brain launch.

Name every public alias that will appear on the website, invoices, App Store, job posts, and packaging. If a string will be printed, it is in the sheet. If it is not in the sheet, it is not live. HOLD will catch the rest and that is correct.

Screenshot old MX and NS into the ticket before you type a new record. Rollback is a picture, not a memory. Agencies that skip the picture invent dual MX under pressure.

Verification TXT is ownership. It is not SPF. It is not deliverability. Check it so the domain is yours, then forget it as a placement lever.

One SPF string if you send. Merge includes. Do not let a wizard add a second v=spf1. Permerror on launch day looks like “deliverability failed” when you actually published two policies.

Copy SMTP from the dashboard only if send-as is in scope this week. Free cannot send-as. Launching inbound and outbound the same hour is how AUTH tickets contaminate MX tickets.

The third mailbox should not be the founder’s other Gmail tab. Use an account at a different provider. Self-send and same-provider tricks are why checklists lie.

Record folder as observation. If the probe is in junk, you still completed the hop gate. You did not fail MX. Open a filter ticket. Do not roll back exclusive MX because Promotions exists.

Tell marketing they cannot paste the address on ads until you paste the probe Message-ID in the launch channel. That single social rule prevents most public incidents.

After go-live, raise TTL when the new MX has been boring for a day. Low TTL forever is extra query noise, not extra safety.

If you must launch a new domain with no reputation, say so. Green records are necessary. They are not Primary. Do not buy a seed-list slide for a five-message operational stream.

Catch-all stays HOLD on launch. Revisit FORWARD only after a month of held-list review. Most teams never need it.

Go-live is hop proof, not a placement promise

A forwarding deliverability checklist is exclusive MX, named aliases, a stranger probe, hop history, intact Header From, and destination copy. It is not a guarantee of Gmail Primary. MailerZ does not publish an inbox-placement rate. Anyone who adds that line to the checklist is selling fiction. Destination filters still apply after a 250.

Item one: two public resolvers show only MailerZ MX. Leftover aspmx, Microsoft, registrar, or a second forwarder is a hard stop. Do not go live on a split path. Empty history for some senders is leftover MX, not “deliverability.”

Item two: every printed local-part exists. Free HOLD will catch the ones you skipped. Do not enable paid FORWARD to pass the checklist. FORWARD hides gaps and is a later product choice.

Item three: probe from another mailbox. Unique subjects. Self-send is invalid. Gmail-to-Gmail can hide MX. Open original. Header From must still be the probe sender. Envelope may show SRS. If Header From was rewritten, you are not on this hop. Stop. Change hops, not SPF.

Item four: hop rows match. Empty, HOLD, accept 550, or 250 then destination 4xx/5xx. Copy SMTP before anyone edits DNS. Destination refuse is not an MX fail.

Item five: send-as only if paid and required. Free cannot send. Dashboard SPF, DKIM, DMARC. One SPF TXT. Unauthorized From is 550. Caps 50/100/200/400/800 and 5/10/15/25. Not a campaign ESP. Outbound proof is a second external inbox, after inbound is green.

Item six: no leftover website-builder MX, no null MX plus real MX, NS pointing at the zone you edited. Verification TXT is ownership, not mail flow.

Item seven: retention honesty. 14 days Free, 90 paid. The destination is the archive. The hop is evidence. Do not go live promising a year of store.

Item eight: one owner for DNS, one for aliases, one for the watch after go-live. Unowned watch is how leftovers return Monday.

Fail the checklist if any item is a vibe. Screenshots of two resolvers and one hop row beat a registrar “worldwide” badge.

What “spam” on day one usually is

Day-one spam folder plus a 250 hop row is destination policy. Work Gmail. Do not restore Google MX. Do not add a second SPF. Do not rewrite Header From — we will not offer that control.

Day-one empty history is leftovers or self-send. Two resolvers. Other mailbox. Do not wait 48 hours on a leftover zone.

Day-one HOLD is a missing name. Create it. Do not FORWARD the domain to pass marketing’s “all addresses work” slide.

Day-one 550 From is Free or unauthorized identity. Pay Solo or higher and copy dashboard SMTP. Do not republish MX.

Newsletters on MailerZ SMTP fail the checklist on purpose. Buy a bulk sender. Human replies only.

Agencies: one client go-live per window. A blended checklist will restore MX on the wrong zone.

ImprovMX or Cloudflare still published: leftover. Compare pages exist. Dual MX is not a bake-off.

No SOC 2, ISO, HIPAA, or review counts on the go-live email to the CEO. /security for controls. /pricing for caps.

Start free — one domain — to run the inbound checklist on three names. Go live on paid when send-as or more names are real. Sign in when the hop already exists.

Monthly after go-live: leftover MX, one stranger probe, send-as counters. The checklist is a habit, not a ribbon.

Go-live is inbound proof, then sending, never the reverse

A forwarding go-live checklist that starts with a newsletter blast is a checklist for blaming the hop. Inbound exclusive MX, named aliases, and a stranger probe come first. Sending records come second, and only on a plan that can send. Free cannot send. If your launch is “we will announce from hello@ on day one,” you need a paid plan and a green inbound hop before you authenticate SMTP. Reverse that order and you will debug SPF while invoices still hit leftover Google MX.

Deliverability here is two jobs with one word. Inbound deliverability is: did the stranger message reach the destination Gmail with Header From intact and a visible hop. Outbound deliverability is: did paid send-as land in a mailbox you do not own without a 550 from the hop for plan or identity. Mixing the jobs produces a SPF edit during a leftover MX incident. Keep two columns on the card.

Header From must stay the original sender on inbound. Envelope MAIL FROM is rewritten with SRS. If a go-live test “fails” because Gmail shows via or a different return path, that is the mechanism working. Do not rewrite Header From to “look native.” MailerZ does not rewrite Header From. A hop that does is a different product class. Your checklist should reject that rewrite, not request it.

Self-send is still invalid on go-live day. The destination Gmail sending to the alias that returns to the same Gmail will look fine while Outlook users never arrive. The checklist item is a Proton or Outlook.com probe per critical alias. Unique subject. Hop history screenshot. Empty history fails the inbound column. HOLD fails the alias-map column. Destination 5xx fails the mailbox column. Three failures, three owners.

Leftover MX fails the inbound column before you touch DKIM. Two public resolvers must show one owner. aspmx at priority 20 is a fail. Registrar MX beside MailerZ is a fail. Null MX if you intend to receive is a fail. Do not proceed to sending checkboxes while the inbound column is red. People proceed anyway because a campaign calendar is louder than a resolver. The calendar is not the mail system.

SPF for sending is one v=spf1 that includes the hop that submits. Duplicate records fail the outbound column. An include for a hop you do not use is clutter. An include for Free send-as that does not exist is fiction. Publish sending TXT when send-as is enabled. Check the count of v=spf1 after the wizard. Wizards duplicate. Humans forget to look.

DKIM selectors belong to the sending hop. Do not copy a Google selector into a MailerZ send and call it done. Do not leave a dead selector in the zone as “backup.” Backup selectors are how you lose track of who can sign. One live selector for the hop you use. Rotate by adding the new, switching the send, then deleting the old after mail that used it has aged out. Same-day delete of a selector still in flight is how you create a week of fails.

DMARC is a policy on the Header From domain. It does not replace exclusive MX. It does not fix leftover aspmx. Start with a reporting policy if you are new, then tighten when the inbound and outbound columns are both boring. Do not jump to reject on go-live morning while leftover MX still exists. You will reject mail that never hit your hop and think DMARC is the villain.

Rate and content are not this hop’s SLA. MailerZ is not an inbox placement vendor. No invented open-rate. No SOC 2 in the checklist. If you send bulk, you are in the wrong article. Transactional and send-as for a person are the paid lane. Port 25 from a VPS is not on this checklist. Paid SMTP submission is.

After go-live, watch one old TTL. Then watch HOLD for names you forgot. Then send one paid test to a stranger mailbox if sending is in scope. Then tell humans the cut happened. Announcing during resolver disagreement trains people to restore leftovers. The checklist ends with a named human who can read hop history the same evening.

Start free to practice inbound on a spare domain: one domain, three aliases, HOLD, fourteen-day store. Sign in on the invoice domain when MX is ready to be exclusive. /pricing for Solo through Agency caps. Envelope SRS. Header From intact. Not IMAP. The go-live card does not grow a mailbox host.

The night-before card a non-engineer can hold

Print seven lines. Domain added. Verification TXT matches two public resolvers. Every printed local-part exists as an alias. Two resolvers show one MX owner and no leftover company names. Stranger probe landed with hop history. HOLD list is empty of invoice names. Sending is off unless the plan can send and one v=spf1 includes only that hop. If any line is blank, the go-live is tomorrow.

Assign initials beside each line. DNS, aliases, proof, comms. A card with no initials is a group chat. Group chats restore aspmx. Initials make the leftover scan a person’s job. If the DNS initial is traveling, move the window. Do not hand the registrar to a contractor at 5 p.m. without the screenshot of the old exclusive set.

Write the stranger mailbox on the card. Not “someone’s Gmail.” The actual address. Prepare unique subjects the night before: brand-hello-UTC, brand-billing-UTC. In the morning you paste, send, screenshot. You do not invent subjects while a customer is on the phone. Panic subjects are how you lose the proof you need for the next incident.

Put the HOLD rule in one sentence the bookkeeper can repeat: unknown name means create or ignore, never dual MX. Put the empty-history rule in one sentence: never arrived here, look at leftovers. Put the 5xx rule in one sentence: destination rejected, copy the SMTP line. Three sentences prevent three wrong restores. That is the whole night-before meeting.

If marketing still wants a blast at noon, move the blast. Inbound green plus sending green is a sequence. A calendar invite is not a fourth resolver. Start free to rehearse the card on a spare domain. Sign in when the invoice domain is the next card. /pricing if three aliases are not enough for the printed map.

FAQ

What is the safest way to handle an email forwarding deliverability checklist?
Treat the list as hard stops. Exclusive MX, named aliases, HOLD unknown, third-mailbox probe, Header From intact. Do not announce a public address until those pass. Do not add a second MX for backup.
Does this require a new mailbox?
No. Keep Gmail or Outlook as the store. MailerZ is not IMAP. A new seat does not replace exclusive MX.
Will it work with Gmail or Outlook?
As destinations, yes. Their filters still apply after 250. The checklist records the folder. It does not command it.
What DNS records are involved?
MX exclusive. Verification TXT for ownership. One SPF if you send-as. DKIM and DMARC from the dashboard when you send. No duplicate v=spf1.
What should I test before production?
A uniquely titled message from an unrelated provider to each public alias. Open original. Confirm From, hop, and folder. Self-send is not the test.

Key takeaways

  • Routes before MX. Exclusive MX. HOLD unknown.
  • Third-mailbox probe is the last gate.
  • Header From intact. Envelope may show SRS.
  • One SPF if you send. No duplicates.
  • No lists on reply SMTP. No inboxing percentage.
  • Leftover MX is a hard stop.
  • Folder after 250 is observation, not rollback.
  • Write the result down so Monday does not undo Friday.

Conclusion

Run the email forwarding deliverability checklist before anyone else sees the address. The gates are boring. The incidents are not.

Start free with one domain and test the inbound path the same way you will run production. Then print the alias.

Start free on MailerZ