Email forwarding deliverability is two questions glued together. Did the hop keep the original sender intact, and did the destination file the copy where a human looks? A sloppy forwarder that rewrites From or shares leftover MX will hurt. An honest hop with envelope SRS and exclusive MX can still land in spam because Gmail and Outlook decide folders. Nobody who is careful quotes a percentage.
Quick answer for email forwarding deliverability
Forwarding hurts when it mutates identity or splits inbound hosts. It does not, by itself, doom a message that still has aligned DKIM and a clean author. IETF RFC 5321 — Simple Mail Transfer Protocol defines acceptance at a hop. IETF RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC) defines alignment. Neither defines Primary. Product path: email forwarding and delivery recovery. Read history, then open original.
MailerZ rewrites MAIL FROM with SRS and leaves Header From, Subject, Date, Message-ID, body, and MIME alone. That is the least harmful hop you can operate. It is still not an inbox SLA. Confirm MailerZ pricing if you also need send-as. Free receives. Solo is $40 per year when the name must go out. Leftover MX remains a hard stop before anyone talks about spam folders.
Community threads often collapse “forwarding” into one villain. A typical example is the Hacker News thread on forwarding and inboxing (nofollow). Quote opinions live if you cite them. This article stays on mechanisms: MX, From, reputation, filters. Google’s people-first guidance is about pages; see creating helpful, reliable, people-first content. A deliverability post that invents a 99% inbox rate is marketing, not operations.
The user problem and the decision criteria
The ticket says forwarding ruined deliverability. The evidence is one customer in spam and one founder probe in Primary. The decision is which of four jobs you are in: leftover MX, a From rewrite, a bad author, or a destination filter. Treating all four as “forwarding” is how you buy a new vendor and keep the same folder.
| Question | If yes | If no |
|---|---|---|
| Does public MX list a second owner? | Leftover MX. Delete it. | The hop can exist. Continue. |
| Was Header From rewritten? | The hop hurt identity. Fix the product. | DKIM can still align. |
| Is the author already junk at Gmail? | Reputation followed the person. Forwarding copied it. | Look at filters and user marks. |
| Is history 250 and the inbox empty? | Destination or HOLD. Not MX. | If history is empty, the hop never happened. |
| Was the only test a self-send? | Invalid. Use another mailbox. | Good. Still check spam and Updates. |
Technical mail flow
The sender delivers to MailerZ MX. MailerZ matches the alias and forwards to Gmail or Outlook. The destination evaluates SPF on the hop, DKIM on the author, and DMARC alignment on Header From. Then a separate system files the copy. That filing uses reputation, user history, content, and volume. A perfect hop can still lose the folder. A broken hop makes the folder worse and can cause a reject.
IETF RFC 7208 — Sender Policy Framework (SPF) and IETF RFC 6376 — DomainKeys Identified Mail (DKIM) run before the folder. Softfail on a naive hop is often noise when DKIM aligns. A From rewrite fails DKIM and then DMARC. That is forwarding hurting deliverability in the strict sense. SRS plus intact From is forwarding trying not to.
Self-send from Gmail to Gmail can skip MX and invent a local win. Bulk test tools can look like campaigns. Probe one unique message from a mailbox you do not own. Open original. Read tokens. Then look in every folder. Troubleshooting and features do not publish an inbox rate.
Step-by-step setup and decision path
Prove exclusive MX
Two resolvers. Leftovers mean some senders never used your hop. Their “spam” is another product’s folder.
Map the printed alias
HOLD is not spam. A missing name is not deliverability. Create the local-part you printed.
Probe from a third mailbox
Unique subject. History 250. Header From intact. If history is empty, stop talking about folders.
Read Authentication-Results
Note spf, dkim, dmarc. Pair with the DMARC and softfail articles if tokens are the argument.
Search the destination, not just Primary
Updates, Promotions, spam, and the helpdesk junk folder. A found copy is a filter. A missing copy after 250 is recovery.
Do not rewrite From to “improve” placement
You become the author with no signature. Banks reject. via may vanish. Alignment dies.
Failure modes and proof
| What you see | Likely cause | Proof |
|---|---|---|
| Some senders never arrive | Leftover MX | Second host on a public resolver |
| All copies show you as From | Forwarder rewrite | Compare to the original author |
| 250 and spam | Destination filter or author reputation | Tokens plus the folder name |
| 250 and nowhere | HOLD, filter, or far-side drop | History plus destination search |
| Green checker, junk copy | Auth is not a folder | Do not quote the checker as placement |
| Self-send in Primary only | Invalid test | Third mailbox |
Proof is MX listings, a history row, headers, and a folder name. “It feels worse since we forwarded” is not proof. Agencies run this per destination product. Client Gmail can file Primary while Client Outlook junks the same author.
MailerZ workflow and product boundary
MailerZ is inbound MX plus authenticated SMTP. Envelope SRS only. Header From is never rewritten. History shows hops MailerZ accepted. It does not show Gmail’s folder. HOLD stores unknown local-parts on Free. It is not a mailbox, not IMAP, not Workspace, not an open relay. Unhosted SMTP is 550 / 550 5.7.1.
Free is one domain, three aliases, 14-day store, send-as disabled, SMTP and API disabled. Solo is $40 per year: 3 domains, 15 aliases, 90-day store, 1,000 outgoing, five send-as per hour, unknowns forwarded. Starter is $8 or $80. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99/month or $990/year. Confirm pricing. Limits are not an inbox-placement SLA. No SOC 2, ISO, HIPAA, review counts, or customer quotes live here.
Cost, alternatives, and trade-offs
| Choice | What you get | What you give up |
|---|---|---|
| Honest hop plus folder search | A real diagnosis | A single villain named forwarding |
| Rewrite From for via | A cosmetic hop | DKIM and the author |
| Buy a suite to “fix spam” | A store. Quote live | The archive you already have |
| Quote an inbox rate | A number you cannot defend | Trust when the next copy junks |
Time is a line item. One third-mailbox probe costs less than a vendor swap. Leftover MX costs more than Solo. A Free-plan send-as argument still costs more than the upgrade. If every teammate needs IMAP on the domain, a suite is the honest product. Pretty hops will not become mailboxes.
When forwarding actually hurts
A hop that stamps its own From destroys DKIM and alignment. Destinations that require DMARC then reject or junk. Helpdesks open tickets as you. That is forwarding hurting deliverability. Choose a product that does not do it. MailerZ is built not to.
A hop that adds footers or re-encodes HTML breaks body hashes. The author still displays. The signature dies. Softfail then has no partner pass. That is also forwarding hurting, even if From looks right.
Shared outbound reputation on a sloppy forwarder can taint the connecting host. Destinations that weight the last hop more than the author will junk more copies. SRS and a clean connecting identity reduce that. They do not erase a spammy author. Reputation still follows the person in Header From at Gmail more often than founders expect.
Dual MX hurts in a different way. Half the senders never reach you. Their copies sit on the old host or bounce. You call that deliverability. It is leftover MX. Delete the old names. Do not buy a warmer IP.
When forwarding is blamed for something else
A newsletter the founder forwarded through a personal alias will look like a campaign. Gmail files Promotions. That is content and list history, not MailerZ. Stop using a role alias as a blast tool. Authenticated send-as on a paid plan is a different product path and still not a blast ESP.
User “Report spam” on a vendor trains the destination. The next invoice junks. The hop did not change. The user did. Ask whether anyone marked the sender. Do not republish MX.
Catch-all FORWARD invites harvested noise. The destination then treats the whole alias set as messy. That is a policy choice. HOLD on unknowns is the quieter inbound default on Free. Do not open the fire hose to chase one typo and then blame forwarding for the junk.
Self-send success followed by customer failure is leftover MX or a sender-specific filter. It is the oldest lie in this cluster. Use another mailbox. Then read public MX again.
What you can promise a client
You can promise exclusive MX, a named map, intact Header From, SRS on the envelope, and a history row you can read. You can promise 550 on unhosted SMTP. You cannot promise Primary, a percentage, or that a bank will honor DKIM after their own policy. Write those sentences in the SOW. The next junk copy will not become a breach of contract.
You can promise to classify. Leftover MX, rewrite, author, filter. Four tickets. If a second operator needs the same order, send this page plus the MX checklist and the DMARC alignment article. Hosts first. From second. Tokens third. Folder last.
Legal hold is not the 14-day Free store. Two-factor on the destination Gmail is still required after a clean hop. Open a held body for break-glass recovery and expect an audit row. That is a control, not a SOC 2 badge. Do not send SMTP passwords to support.
Paid plans do not buy a folder. Solo, Starter, Business, and Agency change limits and send-as. They do not publish an inboxing rate. Do not sell an upgrade as spam insurance. Sell it as identity and capacity.
Agencies: one classification per zone and per destination. A shared screenshot of one Primary copy does not certify the book. Quote vendor UI labels the day you debug. They change. The four-ticket split does not.
If the destination rejects after 250, paste the SMTP text. That is a far-side policy. Remap, ask them to honor DMARC’s DKIM path, or accept a bad pair. MailerZ will not invent a success rate to paper over that pair.
Outbound send-as is a different deliverability job
Founders mix inbound forwarding complaints with Gmail send-as landing in spam. Those are different authors. Inbound copies claim the vendor or the customer. Outbound copies claim you. Your SPF, DKIM, and DMARC, a paid plan, and a matching From identity own the second job. Free has no send-as. Painting inbound tokens will not warm an outbound domain you have not authenticated.
Bulk is a third job. MailerZ outgoing ceilings are operational, not campaign. If you need a newsletter, use a list tool and its own authentication. Forwarding a blast through an alias trains Gmail to hate that alias. That is deliverability damage you chose. It is not a defect in MX.
Reply is closer to inbound than to blast. A human hits reply on a forwarded message. The destination client uses Reply-To or From. Alignment on that reply is the human’s provider, not MailerZ, unless they send-as through your SMTP. Do not promise that every reply will look like the domain. Promise that the inbound copy still showed the original person.
Shared SMTP passwords across clients hurt outbound reputation when one client is abused. That is an agency operations article. Mentioned here because a shared hopper gets blamed on “forwarding” when the leaked credential is outbound. Rotate. Do not share. Confirm pricing for seats and domains rather than one password on a napkin.
IPv6, TLS, and STARTTLS banners do not file folders. They change whether the destination accepted the connection. If history is 250, the SMTP conversation finished. The remaining argument is identifiers and filters. If history is empty, return to MX. Mixing layers is how this topic stays expensive.
How to talk about this without lying
Sales scripts that say “we improve deliverability” need a footnote the same day. The honest line is: we keep the author intact and we show the hop. Destinations still file. If a prospect requires an inbox SLA, they need a different vendor category and you should not win that deal by inventing a number.
Support macros should ask for two-resolver MX, message-id, UTC time, and whether the tester used self-send. A macro that asks “did you check spam?” first trains people to skip leftovers. Spam last. Hosts first.
Status pages should not imply an inbox percentage during an incident. If MailerZ MX is down, say receive is delayed. If Gmail is junking a popular vendor, say the hop is up and the destination is filing. Those sentences keep trust when the next invoice looks red.
Documentation should link recovery when 250 meets an empty inbox, leftover MX when some senders vanish, and DMARC when tokens are the argument. This page is the map. It is not a warmer, not a seed list, and not a promise.
Night operators sometimes disable SRS because via looks ugly. That brings hop softfail back and can break bounces. Explain via. Keep SRS. Cosmetic deliverability is how real deliverability dies.
If a second operator needs the same order without a call, send this page, the MX checklist, and the DMARC alignment article. Exclusive hosts. Intact From. Tokens. Folder. That order prevents the most expensive wrong fix: rewriting From so a yellow icon turns green while banks start rejecting.
Legal hold is not the 14-day Free store. Two-factor on the destination Gmail is still required after a clean hop. Quote live prices the day you debug. Gmail folder names change. The hop-versus-folder split does not.
Plus-addressing and role aliases do not change physics. hello+stripe@ still needs a matching alias policy. A flood of harvested role names is a catch-all problem. Do not call that forwarding hurt. Call it an open door you chose.
Registrar included forwarding often rewrites From and dual-publishes MX. Migrating that product to MailerZ is how both wounds close. Do not keep both MX owners while you A/B “deliverability.” You are A/B two different products.
Mobile screenshots hide Authentication-Results. Ask for original. If the reporter cannot open original, they do not have a deliverability ticket yet. Support cannot classify a crop of a red shield. The cheap artifacts stay the same: two-resolver MX, history row, Header From, tokens, folder name.
Subdomains complicate the story when invoices print billing@pay.example.com and you only cleaned the apex. Those copies never used your honest hop. You will call that forwarding hurt. It is an uncleaned name. Query the printed hostname. Give it exclusive MX if it should hit MailerZ. Each name is its own deliverability domain.
Corporate secure email gateways after Gmail can junk a copy MailerZ already delivered. History still shows 250. The gateway is a destination you do not operate. Say that on the ticket. Do not republish SPF to please a gateway that re-encrypts and breaks DKIM on the way to a journal archive.
Seed lists and inbox-placement vendors sell a number. That number is not MailerZ’s. If a client arrives with last month’s 97%, do not match it. Show them hop evidence and a classification. If they need the number to close a board deck, they are buying a different category of tool. Decline the SLA. Keep the hop.
Night CTA belongs after classification, not in the lede. If the domain only receives, start free and prove inbound. If the name must go out, Solo is the first paid rung. Do not sell Agency as a spam insurance tier. Capacity is not placement.
Helpdesks that ingest the alias are destinations. If they reject on DMARC, history will show the far-side error. Remap or ask what they require. Do not rewrite From to please a parser unless you are willing to become the author and sign as yourself. That is a product change, not a checkbox, and it usually hurts the next bank copy.
FAQ
What is the safest way to handle email forwarding deliverability?
Keep Header From intact, use exclusive MX, and treat history 250 as hop proof, not Primary. Classify leftover MX, From rewrites, sender reputation, and destination filters as four different tickets. Do not quote an inbox percentage. Probe from a third mailbox.
Does this require a new mailbox?
No. Deliverability after a forward is a hop and a destination folder. Gmail or Outlook can stay the store. MailerZ is not IMAP. Buy hosting only if you need folders on the domain instead of Gmail.
Will it work with Gmail or Outlook?
Both can accept a forwarded copy and still file it in spam. A honest hop with surviving DKIM helps. It does not guarantee Primary. Self-send hides leftover MX. Free has no send-as.
What DNS records are involved?
Exclusive MX so the hop exists. The author’s SPF, DKIM, and DMARC on inbound copies. Your SPF, DKIM, and DMARC when you send as the domain. Verification TXT is ownership. None of those records file a folder.
What should I test before production?
Two-resolver MX, named alias, uniquely titled third-mailbox probe, Header From intact, history 250, Authentication-Results, then look in Primary, Updates, and spam. A green public checker is not a folder test.
Key takeaways
- Email forwarding deliverability is hop integrity plus a destination folder. They are not the same.
- From rewrites and leftover MX actually hurt. Honest SRS plus intact From still is not Primary.
- History 250 is acceptance. Search every folder before you change vendors.
- Author reputation and user marks travel with Header From.
- Do not quote an inbox percentage. Do not rewrite From to hide via.
- Self-send is invalid. Probe from another mailbox.
- Free receives. Solo $40/yr starts send-as. Confirm /pricing.
- Envelope SRS only. Not IMAP, not an inbox SLA, not SOC 2.
Conclusion and next action
If someone asks whether forwarding hurts deliverability, split the ticket. Clean MX. Keep the visible sender. Read history. Read tokens. Name the folder. MailerZ can run an honest hop. It cannot file Primary or erase a sender Gmail already hates. Start free on one domain and prove a third-mailbox copy.
Ready to prove an honest hop
Start free with one domain and intact Header From.
Inbound on Free. Solo when send-as is the job. Sign in if the domain is already there.
Review quarterly, or sooner if Gmail folder names or MailerZ history labels change. Author: MailerZ editorial, Secuno LLC.