How to replace a forwarding + SMTP patchwork with one service

Quick answer for email forwarding SMTP one service

The safest way to replace a forwarding plus SMTP patchwork is sequential, not simultaneous. Write down who answers MX today. Write down who is allowed to send as the domain. If those names differ, you have a patchwork even if the website looks fine. Pick one delivery layer that can do both hops, or pick a suite that hosts the mailbox. Do not keep the old forwarder “just in case” beside the new MX.

MailerZ is one product in the one-service class: inbound MX plus authenticated SMTP on paid plans, around the inbox you already use. Envelope MAIL FROM can use Sender Rewriting Scheme. Header From, Subject, Date, Message-ID, body, and MIME are never rewritten. It is not Google Workspace, not IMAP, and not an open relay. Unhosted or unauthorized send gets SMTP 550 / 550 5.7.1.

Internet mail does not glue those hops for you. IETF RFC 5321 — Simple Mail Transfer Protocol is the transport standard. A sender looks up MX, offers MAIL FROM, names RCPT TO, and transfers content. Outbound is a later SMTP session with different credentials. A forwarder that never offered SMTP leaves replies as @gmail.com. An SMTP vendor that never answered MX leaves inbound at the old host. That is the patchwork.

Free cannot finish the outbound half. MailerZ Free is one domain, three 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 SLA.

Positioning for this row: avoid buying full mailbox seats for addresses that only need routing. If every teammate needs Calendar and a hosted archive, buy a suite instead. The comparison page is MailerZ versus Google Workspace. Role addresses belong on aliases, not extra seats; see aliases and catch-all.

The user problem and the decision criteria

Patchwork usually starts as thrift. Someone enabled registrar forwarding. Gmail still sent as gmail.com. A forum thread suggested a cheap SMTP host. SPF grew a third include. DKIM never matched the visible From. Support tickets became “works for me” because each vendor could only see half the path.

The other origin is a half-finished suite trial. Google or Microsoft MX stayed published. A forwarder was added for “the addresses Workspace does not need.” Senders split. The founder bought more tools instead of deleting records.

Decide with jobs you can test.

A one-service cut is a poor fit when legal hold requires a vendor mailbox you control, when every user needs admin-managed seats, or when you want someone else to promise the Primary tab. No forwarder controls that last part.

It is a good fit when the public addresses are roles, the people already live in Gmail, and you are tired of explaining a missing hop with two dashboards open.

Contractors make patchwork worse. One person added ImprovMX. Another added a transactional SMTP user for invoices. A third left a registrar “email forwarding” toggle on. None of them documented the password. When you finally cut, you will find a login email you no longer control. Inventory includes who can still authenticate, not just which hostname answers MX.

Plus addressing is not a patchwork escape hatch. A Gmail plus tag lives inside one mailbox. It does not replace billing@yourdomain.com, and it does not retire a leftover SMTP include. If the printed address is a domain role, map a named alias. If the tag is only for personal filters, leave it on Gmail and keep it out of DNS.

Technical mail flow

Patchwork fails because people treat email as one pipe. It is not. Inbound acceptance, forwarding, mailbox storage, and outbound submission are separate conversations. One service does not merge them into magic. It puts the first and last hops under one set of credentials and one history.

Inbound on one service

A customer sends to hello@yourdomain.com. Their server asks DNS for MX. If MailerZ MX is the only published answer, the message arrives at MailerZ. The edge checks verification and whether the recipient matches an alias, a route, or an intentional catch-all rule. Unknown addresses on Free are held. Paid plans can forward unknown recipients when you enable that behavior.

MailerZ stores required content and metadata before SMTP 250. Then it forwards to the verified destination. Visible From stays the original sender. Envelope return path may use SRS so bounces do not impersonate that sender. Delivery history records the destination response. Gmail can still file the copy in spam. That is Gmail’s decision.

Outbound on one service

When you reply, Gmail needs an outgoing server allowed to use the domain identity. You add MailerZ SMTP: host, secure port, username, generated password, approved From. MailerZ authenticates, checks the identity, applies plan limits, and submits. Invalid credentials stop here. Publish SPF, DKIM, and DMARC from the dashboard. IETF RFC 7208 — Sender Policy Framework (SPF), IETF RFC 6376 — DomainKeys Identified Mail (DKIM), and IETF RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC) are the protocol texts. They authorize. They do not inbox.

What patchwork does instead

Inbound vendor A accepts and forwards, sometimes rewriting Header From. Outbound vendor B sends with a different DKIM domain. SPF lists both plus a registrar helper. DMARC reports look noisy because alignment depends on which hop the receiver saw. When a message vanishes, vendor A says it forwarded. Vendor B says it never received a send. You have no single event.

Gmail Send mail as can sit on top of either design. Google documents the client side as sending from a different address; see Google Gmail Help — Send mail from a different address. That help page does not choose your receiving stack. It assumes you already have a working address and an SMTP server allowed to use it.

Outlook is the same split with different labels. Incoming mail still lands in the destination mailbox. Outgoing identity is a manual SMTP account if you want the domain From. Version names differ. The test does not: a message must leave through the new host and land in an inbox you can inspect. If Outlook still lists the old relay, you did not finish the cutover even if MailerZ history looks clean for inbound.

Alignment is easy to break during a half-cut. Receivers evaluate SPF on the envelope and DKIM on the signature, then compare those domains to the visible From for DMARC. If inbound still rewrites From at the leftover forwarder, filters get worse. MailerZ does not rewrite Header From. The old hop might. That is a reason to delete leftover MX, not a reason to add a fourth vendor.

Step-by-step setup and decision path

Cut in this order. Retiring SMTP first is how people lose the ability to reply while inbound is still on the old forwarder.

1. List every MX host and SMTP credential

   Query public MX from two resolvers. Open Gmail Send mail as and Outlook SMTP settings. Write the hostnames. If you cannot list them, you cannot delete leftovers safely.

2. Confirm the store

   If the archive is Gmail or Outlook, continue with a delivery layer. If you need hosted seats and Calendar, stop and buy the suite. Do not build a third patch.

3. Add one domain to MailerZ

   Publish the verification TXT on authoritative nameservers. Verify in the dashboard. Receiving stays off until that check passes.

4. Map aliases you actually print

   Recreate hello@, billing@, and other public strings. Point each at the real inbox. Complete destination verification. Do not invent plus tags as a substitute for named aliases. Free allows three aliases.

5. Publish MailerZ MX and delete leftover MX

   Copy hosts and priorities from the dashboard. Remove the old forwarder, Google trial, Microsoft, or registrar MX. Leftover MX is a hard stop. Use DNS diagnostics if the public set still looks mixed.

6. Prove inbound from a different mailbox

   Send a uniquely titled message from an unrelated provider to each alias. Confirm Header From. Read delivery history. Self-send lies.

7. Move send-as only after inbound is green

   Upgrade off Free. Create the SMTP credential. Replace the old SMTP host in Gmail or Outlook. Publish the new SPF, DKIM, and DMARC values. Remove includes that authorized the retired relay. The product surface is send and reply as your domain.

8. Send to a second external inbox and revoke old secrets

   Check visible From and the reply path. Then rotate or delete the previous SMTP password so the patchwork cannot send after you think it is gone.

Failure modes and proof

Most “one service cutover failed” reports are leftover MX, an old SPF include, or SMTP swapped before inbound was proven. Work the evidence.

Proof is a pair of artifacts: the destination copy or sanitized headers, and the MailerZ event with timestamp plus remote response. Do not send SMTP passwords to support. Do not publish verification tokens. Inbox placement is not proof the cutover is complete.

Recovery storage is 14 days on Free and 90 days on paid plans. That window exists so a failed hop can be inspected. It is not a second archive and not a compliance vault. If you need legal hold, keep it in Gmail or a suite store. MailerZ does not become that store because you collapsed a patchwork.

MailerZ workflow and product boundary

MailerZ is a custom-domain email delivery layer operated by Secuno LLC. Point MX at MailerZ. Mail for a hosted, verified domain can land in Gmail or Outlook. Paid plans add authenticated SMTP so the same domain can send and reply. The live site is mailerz.net. The app is mail.mailerz.net.

What MailerZ does in a patchwork replacement

• Accept inbound mail for verified domains and configured aliases.
• Preserve Header From on the forward into Gmail or Outlook.
• Hold unknown recipients on Free; allow paid catch-all forward when you enable it.
• Store messages for 14 days on Free or 90 days on paid plans for recovery and evidence.
• Send through authenticated SMTP from approved identities on paid plans.
• Record delivery history for inbound and outbound hops in one place.

What MailerZ does not do

• Replace Gmail or Outlook with IMAP or webmail.
• Rewrite header From, Subject, Date, Message-ID, body, or MIME.
• Offer send-as on Free.
• Promise inbox placement, uptime SLAs, or review counts.
• Claim SOC 2, ISO 27001, or HIPAA. Those certifications are not held. Controls live on Security and Trust Center.
• Act as an open relay.
• Send newsletters or purchased lists.
• Import your old vendor’s mailboxes. This is a DNS and credential cut, not an IMAP migration.

Alias ceilings stay finite: 3 on Free, 15 on Solo, 50 on Starter, 200 on Business, 500 on Agency. Seats are operators of the delivery layer, not mailbox licenses. Free and Solo are one seat. Starter is five. Business is twenty-five. Agency is fifty. If you need fifty hosted inboxes, you are back in suite math.

Catch-all is still a policy, not a way to avoid recreating aliases during cutover. Recreate the printed addresses first. Leave unknown recipients held until you have a reason to forward them. Enabling catch-all so you can skip the alias list will replay the same harvested guesses the old forwarder was already eating.

Delivery history is the reason to collapse vendors. When inbound and outbound share one log, a missing message is an event with a remote SMTP response, not a he-said between two support forms. That is operational evidence. It is not a guarantee the far side placed the copy in Primary.

Cost, alternatives, and trade-offs

Patchwork looks cheap until you count hours. Two invoices plus a weekend of SPF debugging is still a cost. One service is not automatically cheaper than a suite. It is cheaper when you were about to buy seats for addresses that only need routing.

MailerZ Free is the right first purchase when you only need to prove inbound on clean MX. It is the wrong plan if the acceptance test includes a domain From on the reply. Solo is 5 send-as messages per hour and 100 outgoing per month. Starter is 10 and 200. Business is 15 and 400. Agency is 25 and 800. Annual Starter, Business, and Agency billing includes two months free relative to paying monthly for a year. Solo has no monthly option.

Cloudflare Email Routing and other inbound routers can replace half a patchwork. They do not become MailerZ leftover-MX handling, stored failed hops, or authenticated send-as because this article named them. ImprovMX is a closer commercial forwarding class; compare live plans rather than memory. A campaign SMTP vendor can stay in place for newsletters if you keep that From identity separate from the support alias.

Do not merge a bulk sender’s include into the same SPF you use for MailerZ just to “keep one record.” If the newsletter uses another domain or a dedicated subdomain, keep it there. One service for role mail is not one include for the entire company internet.

Count the burst, not the brochure. If month-end invoices exceed Solo’s 5 send-as messages per hour, Starter or Business may be the fit, or a dedicated invoice sender on a subdomain. If the burst is a newsletter to a purchased list, that traffic does not belong on MailerZ at any plan. Keep the campaign platform. Collapse only the role-mail patchwork.

Time-box the rollback. Leave the old MX hostnames in a note, not in the live zone. If the external inbound test fails twice, you can republish the previous MX while you fix aliases. If you deleted the old account before the test, you have no rollback. That is how patchwork becomes an outage.

FAQ

Key takeaways

• Email forwarding SMTP one service means one operator for MX and authenticated send, not a new mailbox.
• A patchwork is two vendors and two logs. Collapse it only after you can list both.
• Publish one MX set. Leftover MX is a hard stop.
• Remove leftover SPF includes when you retire the old relay.
• Prove inbound from another mailbox before you swap SMTP.
• Free has no send-as. Paid plans add SMTP within published hourly and monthly limits.
• Header From stays original on MailerZ inbound. Envelope SRS is the rewrite that is allowed.
• Do not buy suite seats for addresses that only need routing.
• MailerZ is not SOC 2, not IMAP, and not a bulk sender.

Conclusion and next action

If you came here to replace a forwarding plus SMTP patchwork with one service, the work is inventory, then DNS, then proof. Keep the inbox. Take the domain through verification, one MX set, leftover cleanup, and an external inbound probe. Only then attach Gmail Send mail as or Outlook SMTP to the new credential and revoke the old one. That order prevents the two classic failures: a verification email that never arrives, and a From address that still leaves through a relay you thought you deleted.

MailerZ fits when you want that split with delivery history and a recovery window you can inspect. It does not fit when you need a hosted mailbox for every user, a certified compliance report, or campaign-scale sending. Start on Free if you only need to watch inbound on clean MX. Move to Solo or another paid plan when the From identity has to travel.

Next action: list today’s MX and SMTP hosts. Add one domain, create the aliases you print, and send a uniquely titled message from a mailbox that is not the destination. The MailerZ documentation has the field maps. The register path is one domain.

Review quarterly, or sooner if provider SMTP behavior, MailerZ plan limits, or DNS guidance changes. Author: MailerZ editorial, Secuno LLC.