Email Forwarding Fundamentals

How domain email forwarding works from MX lookup to the final inbox

Five hops. Name the one that died. Public MX is hop one.

MailerZ editorial · Secuno LLC17 min read

How email forwarding works is a sequence, not a toggle. A sender looks up MX. A host accepts RCPT TO. An alias map chooses a destination. A second SMTP session delivers to Gmail or Outlook. The human may reply on a different path. MailerZ runs hops one through three when MX is honest. Gmail runs the store. Leftover MX means hop one never reached you. Self-send can skip the sequence and lie.

MX lookup to Gmail store sequence
Lookup, accept, map, resend, store.

Quick answer for how email forwarding works

Publish one MailerZ MX set so hop one lands here. Create named aliases for hop two. Probe so hop three and four leave a trail. That is how email forwarding works when it works.

Best practice: name the dead hop. Setup: verify, map, cut leftovers, probe. Do not add backup leftover hosts.

SRS may rewrite the envelope on hop three. Header From stays.

Reply is hop five and optional.

MailerZ Free is one domain, ten aliases, one seat, a 14-day store, send-as disabled, SMTP and API disabled, and unrouted mail held or rejected only. Solo is $40 per year only. Starter is $8 monthly or $80 yearly. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99/month or $990/year. Confirm numbers on MailerZ pricing. Limits are not an inbox-placement promise.

Google’s own Send mail as steps live in Google Gmail Help — Send mail from a different address. Workspace as a product is described on Google Workspace — product overview. Transport still follows IETF RFC 5321 — Simple Mail Transfer Protocol.

how email forwarding works guide: the real decision

Dashboards show hop two while hop one still belongs to Google.

People debug Gmail spam (hop four) when the message never left the leftover host.

Self-send skips hops.

Criteria: public MX, alias match, history on this layer, destination delivery, then Reply.

Hops
HopOwnerFirst artifact
MX lookupYour DNSPublic view
Alias mapMailerZNamed list
Second SMTPMailerZHistory / store
InboxGmail/OutlookDelivery / headers

Prove inbound from another mailbox before you print hello@ on a homepage.

Start free — one domain

Technical mail flow for how email forwarding works

Resolver, preference order, TCP, MAIL FROM, RCPT TO, DATA, quit, new session, Gmail accept, classify.

Preference is an order. Leftover better-preference host steals hop one.

Unknown RCPT is hold, reject, or catch-all — hop two policy.

Deferral on hop three is a store or retry question, not a Gmail filter question yet.

MailerZ is inbound MX plus authenticated SMTP from Secuno LLC. Envelope SRS only. Header From, Subject, Date, Message-ID, body, and MIME are never rewritten. Not Google Workspace, not IMAP or POP, not an open relay. Unauthorized send is SMTP 550 / 550 5.7.1. Leftover MX is a hard stop. Self-send from Gmail to the same Gmail account can hide routing errors. Not SOC 2, not ISO 27001, not HIPAA.

Leftover host wins hop one
Better preference leftover. Story over.

how email forwarding works setup

Stand up hops in order. Do not skip leftover deletion.

  1. Check NS, then MX, from a public view.
  2. Verify the domain.
  3. Create aliases.
  4. Publish MailerZ MX. Delete leftovers.
  5. Probe with a unique subject from another mailbox.
  6. Read MailerZ history, then Gmail.
  7. Only then attach send-as.
  8. Use the routing lab to practice lookups.

Failure modes and proof

Edited the wrong nameservers.

Backup leftover MX.

Self-send.

Blamed spam before history.

Expected hop five without paying.

Leftover MX is the usual ghost. Check a public lookup before you blame Gmail.

Open leftover MX troubleshooting

MailerZ workflow and product boundary

History exists for hops this layer saw. Leftover misses do not. Related: email forwarding, features, delivery recovery, email routing lab.

Envelope SRS only. Not IMAP.

Related pages: email forwarding, features, delivery recovery, and email routing lab.

Reply is a new sequence
Forwarding ended at the store. Send-as starts over.

how email forwarding works best practice

Free proves hops one through four on one domain. Paid proves hop five. Confirm pricing.

A VPS makes you the hop-three pager.

MailerZ Free is one domain, ten aliases, one seat, a 14-day store, send-as disabled, SMTP and API disabled, and unrouted mail held or rejected only. Solo is $40 per year only. Starter is $8 monthly or $80 yearly. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99/month or $990/year. Confirm numbers on MailerZ pricing. Limits are not an inbox-placement promise.

Field notes you can reuse

Write hop numbers in tickets.

TTL lies. Check two views.

Hold unknowns at hop two.

Agencies: per-zone hop one.

Forms are hop five if they send as the domain.

Collect Message-ID from hop four.

Quarterly leftover review.

The buy guide is vendor questions. This page is the sequence.

Deeper field notes for how email forwarding works

Hop zero: the sender types an address

How email forwarding works starts before MX. A human or a form produces a string, hello@yourdomain.com. That string is not a server. It is a name. The sending system will ask DNS what to do with the domain part. If you printed the string and never published MX, some senders bounce, some queue, some hit leftover hosts you forgot. The public address and the MX set must describe the same world.

Hop one: MX lookup

The sender’s resolver queries MX. It receives hosts and preference numbers. It sorts by preference and tries the first. TCP to port 25, or whatever the sender uses for outbound submission to the internet — the receiving side is SMTP to the MX. If that host refuses, it may try the next preference. If a leftover host accepts, the message never reaches MailerZ. Priority is an order, not a pool.

Authoritative nameservers are the ones that answer, not the registrar logo. If you edited records on a parked zone while Cloudflare or Route 53 actually answers, the lookup you wanted never published. Check NS, then MX, then wait for TTL.

Hop two: RCPT TO and the alias map

MailerZ accepts the connection for a verified domain. It looks at RCPT TO. A named alias matches and selects a destination. An unknown is held, rejected, or forwarded only if you chose that policy. Free holds unknowns. Creating hello@ does not accept billing@. The map is the product.

Hop three: the second SMTP transaction

MailerZ opens a new SMTP session to Gmail or Outlook for the destination. Envelope recipient is the destination mailbox. Envelope sender may use SRS. Header From stays the original author. If Gmail greets this hop with a deferral, the message sits in retry or the store depending on what this layer saw. The 14-day or 90-day window is for hops that reached MailerZ. A leftover MX miss never appears here.

Hop four: the destination inbox

Gmail classifies the copy. Spam, Promotions, or Primary are Gmail decisions. Authentication results on the received copy describe the hop Gmail saw. A via line can appear when some other product rewrote headers. MailerZ’s inbound path is built so Header From is intact. Self-send from the same Gmail can skip the public path and lie about hops two and three.

Hop five: the human replies

Reply is not forwarding. It is a new message. Without send-as, it leaves as the Gmail address. With paid SMTP and Send mail as, it can leave as the domain From. That outbound path has its own SPF, DKIM, and rate limits. Solo 20 send-as per hour, Starter 40, Business 60, Agency 60. Confirm pricing. Those are ceilings, not inbox SLAs.

Where to look when a hop dies

Public MX: hop one. Alias list: hop two. MailerZ history: hop three if it arrived. Gmail delivery: hop four. The From on the reply: hop five. Do not open all five at once. Name the hop. The routing lab is for practicing lookups. Troubleshooting is for leftover MX. Delivery recovery is for hops this layer stored.

A complete worked story

An empty history and a confident registrar

A retailer showed a MailerZ alias and an empty history. Customers swore they wrote. Public MX still listed the registrar first. Hop one never arrived. They deleted the leftover, waited out TTL in two cities, and the next unique subject appeared in history and in Gmail. They had been about to recreate the alias. The sequence saved the alias.

Operator brief

A longer operator brief for how email forwarding works

Teams that bookmark How Domain Email Forwarding Works From MX Lookup to Final Inbox usually arrive after a missed invoice, a form that never notified anyone, or a migration that looked clean in one resolver. The useful brief is still boring. Name the store. Name the printed local-parts. Name the nameservers that actually answer. Publish one MailerZ MX set. Delete leftover hosts. Probe from a mailbox that is not the destination. Only then talk about how email forwarding works as a send-as, catch-all, or comparison problem.

MailerZ remains inbound MX plus authenticated SMTP around Gmail or Outlook. Envelope SRS only. Header From, Subject, Date, Message-ID, body, and MIME stay intact. It is Mail Box portal webmail, not IMAP, not POP, and not an open relay. Unauthorized send is 550 / 550 5.7.1. Free cannot finish send-as: SMTP and API stay off. Solo is $40 per year when the domain From must travel. Starter is $8 or $80. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99/month or $990/year. Confirm the live pricing page. Those numbers are ceilings, not an inbox-placement service-level agreement.

If leftover Google, Microsoft, Cloudflare routing, or registrar MX is still public, stop widening how email forwarding works. The map you built never saw that copy. Priority numbers are an order, not load balancing. A higher preference host is idle while a leftover host still accepts mail. Save the old MX set before you delete anything. Check more than one public view because TTL lies.

Catch-all forward is not a safety feature for how domain email forwarding works from mx lookup to final inbox. Hold unknowns on everyday production. Review the store. Promote a leftover only when a real person used it. Paid forward belongs to a dated cutover. Fan-out of unknowns into two inboxes trains two spam buttons. Plus addressing on Gmail is not a custom-domain unknown policy. MailerZ will not strip plus tags on your domain the way Gmail does on @gmail.com.

Send-as is a second hop. Creating an inbound alias does not approve outbound. Catch-all does not mint a From. Copy the dashboard host, port, and TLS pair together. Set From to an identity you created. Do not paste a Gmail password into a CMS, a cron file, or a ticket. Do not mail SMTP secrets to support. Send a 550 line, a timestamp, and a Message-ID. Rotate if a secret already leaked.

Self-send from Gmail to the same Gmail account can short-circuit. That green result is why people swear how email forwarding works works while customers vanish. Use a second provider. Put a unique subject on the probe so delivery history is searchable. If Header From was rewritten by some other forwarder, authentication stories get noisier. MailerZ does not rewrite Header From on inbound.

Agencies should keep how email forwarding works per client zone. Separate SMTP credentials. Do not pour every client into one catch-all because the spreadsheet got long. Agency plan capacity exists so you can hold more domains and aliases. It does not replace a named list. Offboard means delete MX you own, revoke SMTP, and stop forwarding leftovers into the agency inbox.

Legal and security questions have published answers on the security, privacy, terms, DPA, and subprocessors pages. MailerZ is not SOC 2, not ISO 27001, and not HIPAA. The 14-day Free store, the 90-day Solo–Agency store, and the 180-day Unlimited store are recovery windows for hops this layer saw. They are not an archive and not legal hold. If counsel wants eDiscovery, buy eDiscovery.

Comparisons only help after the hop is honest. Cloudflare Email Routing is inbound routing. A privacy-mask product hides a destination on a provider domain. A suite hosts mailboxes, Calendar, and admin. Proton-class mailboxes encrypt a store. MailerZ is the delivery layer when you already have Gmail or Outlook and you need a domain route you can prove. Cite the other product’s documentation. Do not invent feature parity.

When How Domain Email Forwarding Works From MX Lookup to Final Inbox is closed, the next physical action is a lookup and a probe, not another tab. Start free on one domain you can break. Sign in if the zone already lives here. Review quarterly, or sooner after a nameserver move, a plugin swap, or a staff departure. That is how how email forwarding works stays a runbook instead of an incident.

A second worked pass for how email forwarding works: 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 how email forwarding works mystery. You have a split. Delete the leftover. Wait for TTL. Probe again.

A third worked pass: 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. Ten 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@.

More working detail

What a unique subject is doing in this sequence

A unique subject is a correlation ID you can type into Gmail search and into MailerZ history. “Test” is not a correlation ID. “probe-2026-04-12-outlook” is. How email forwarding works in an incident is matching hop three to hop four. If history has the subject and Gmail does not, you are in Gmail classification or a destination reject. If neither has it, you are still on hop one or hop two. That split is the whole reason to name hops.

Put the same subject in the ticket. Do not send a screenshot of an empty inbox with no subject. Support cannot grep an empty pane. The evidence page in the docs mindset is the same: timestamp, Message-ID if you have it, public MX, unique subject.

IPv6 versus IPv4, corporate egress filters, and a hotel network are hop-three or hop-four noise. They are real. They are not leftover MX. Check hop one first anyway. The cheap ghost is still the leftover host. The expensive ghosts come after hop one is clean.

Catch-all at hop two turns a harvest into many hop-three sessions. That load is how people decide forwarding is slow. The slowness was the policy. Hold unknowns. Review the store. Promote one leftover when a human used it. Do not open hop two all the way because hop four looked quiet.

If you operate many zones, hop one is per zone. A clean lookup on client A does not bless client B. Agencies who skip per-zone MX checks invent a myth that “the service flaps.” The service never saw client B’s leftover Google.

One more working distinction

What “final inbox” hides

The final inbox is a Gmail or Outlook classification, not a guarantee of Primary. How email forwarding works ends at delivery to the destination system. Promotions and spam are that system’s next job. A clean hop-three history plus a spam tab is not a broken forwarder. It is hop four. Move the message, train the destination, and check whether some other product rewrote headers. Do not add a second MX to “improve inboxing.” That second MX is how hop one splits.

Filters on To: hello@yourdomain are hop-four hygiene. They do not change hop one. People who skip MX and build filters first sort mail that never arrives. Build the sequence, then the filter.

If the destination rejects hop three — full mailbox, blocked sender, policy — MailerZ can only show what this layer saw. Delivery recovery is for stored hops, not for a destination that said no. Fix the destination quota or the block. Then probe again with a new unique subject so you do not match the rejected one.

A short operating rule

Why hop numbers belong in the subject line of the ticket

Write “hop1 leftover MX” or “hop4 spam tab” in the first sentence. How email forwarding works for a team is a shared vocabulary. Without it, three people open three dashboards and each think they found the root cause. The sequence is the shared vocabulary. Use it even when you are the only operator. Future you will thank present you.

The four hops in one invoice story

A supplier sends to billing@brand.com. Hop one is their resolver asking for MX. If leftover Google is still published, some of those lookups never reach MailerZ. Hop two is MailerZ accepting a named alias. If billing@ was never created, Free holds or rejects the local-part. Hop three is MailerZ opening a second SMTP session to the verified Outlook. If Outlook returns 5xx, history shows accept plus destination refuse. Hop four is Outlook filing the copy. Promotions is still hop four. Do not add a second MX to “fix Promotions.”

Envelope SRS can rewrite the return path so a destination bounce comes back to a path MailerZ can handle. Header From stays the supplier. That is why a reply still goes to the supplier, not to a MailerZ identity. If some other forwarder rewrote Header From, you are no longer looking at this hop story. Name that product in the ticket and stop blaming MX.

Prove the sequence with a unique subject from a mailbox that is not the destination. If history is empty, stop at hop one. If history has the subject and Outlook does not, stop at hop three or hop four. That split is the whole article. Related diagnosis lives on troubleshooting and email forwarding.

FAQ

What is the safest way to handle how email forwarding works?
A sender looks up MX, a verified host accepts a named alias, a second SMTP session delivers to Gmail or Outlook, and Header From should stay intact. Prove each hop. Leftover MX means hop one never reached the forwarder.
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.
Will it work with Gmail or Outlook?
Yes for inbound when the destination is a verified mailbox. Branded replies need paid 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 authoritative nameservers, leftover host MX removed, and SPF, DKIM, and DMARC if you also send as the domain.
What should I test before production?
Send a uniquely titled message from an unrelated provider into each named alias. Confirm Header From and delivery history. Do not email yourself from the same Gmail account.

Key takeaways

  • Sequence, not toggle.
  • Hop one is MX.
  • Leftover ends the story.
  • Alias is hop two.
  • Store is hop four.
  • Reply is new.
  • No self-send.
  • Name the dead hop.

Conclusion and next action

How email forwarding works is lookup, accept, map, resend, store. MailerZ is hops you can prove. Gmail is the store. Cut leftover MX so hop one is honest.

Start free. Sign in if hop three history is empty and hop one still shows Google.

Watch the hops

Start free and prove hop one through four with an external probe.

If hop one is leftover MX, stop debugging Gmail.

Review quarterly, or sooner if Gmail, Workspace, or MailerZ scope changes. Author: MailerZ editorial, Secuno LLC.