Best email forwarding service with SMTP send-as

Quick answer for email forwarding service with SMTP

The best email forwarding service with SMTP is the one that owns both hops and shows evidence for each. Inbound is MX plus a recipient table. Outbound is a credential allowed to use an approved From. If those names differ, you have a patchwork. If only inbound works, recipients still see @gmail.com on the reply.

MailerZ is a focused custom-domain forwarding plus authenticated SMTP option operated by Secuno LLC. 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.

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. Later, your client opens a new SMTP session to send. Those conversations do not share fate. A working inbox does not prove send-as. A working SMTP test does not prove MX.

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

Free cannot finish outbound. 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, 5 send-as per hour, 100 outgoing per month. Starter is $8 or $80, 10 per hour, 200 per month. Business is $19 or $190, 15 and 400. Agency is $39 or $390, 25 and 800. Confirm numbers on MailerZ pricing. Limits are capacity, not an inbox-placement promise.

Features and the send path live on MailerZ features and send and reply as your domain. If you are leaving two vendors, use the migration planner.

The user problem and the decision criteria

The usual complaint is a professional inbound address that still replies as Gmail. A free forwarder solved receiving. The founder pasted a cheap SMTP host into Gmail. SPF grew a third include. DKIM never matched the visible From. Each vendor could only see half the ticket.

The opposite complaint is SMTP that works and inbound that does not. Someone bought send-as first, left registrar MX in place, and wondered why customers never arrived. Leftover MX is a hard stop. Senders split.

Decide with jobs you can test.

Workspace is the right buy when every user needs a hosted mailbox, Calendar, and admin. It is optional when you only need the domain identity around Gmail. Do not run Workspace MX beside MailerZ MX.

A campaign SMTP vendor can stay on a newsletter subdomain. Do not merge that include into the same SPF you use for role-mail send-as just to “keep one record.”

Contractors make the two-hop problem personal. If send-as still uses a password the freelancer created on a random relay, they can send as your domain after they leave. Collapse SMTP to one credential you can rotate. Revoke the old host the same day outbound proof passes. Inbound aliases should point at inboxes the company keeps, not a personal Gmail you will lose.

Hourly caps are part of the “best” score. Solo’s 5 send-as messages per hour will stall a month-end invoice burst. That is not a broken service. It is a plan mismatch. Count the burst before you decline Starter or Business. If the burst is a newsletter to a purchased list, no MailerZ plan is the product.

Outlook deserves an explicit check. Incoming mail still lands in the destination mailbox. Outgoing identity is a manual SMTP account if you want the domain From. Version names differ. If Outlook still lists the old relay, you did not finish the cutover even if MailerZ inbound history looks clean.

Technical mail flow

Judge a forwarding-plus-SMTP service as two pipelines that share DNS and a log.

Inbound

A customer sends to hello@yourdomain.com. Their server asks DNS for MX. If MailerZ MX is the answer, MailerZ checks verification and the recipient table. Unknown addresses on Free are held. Paid plans can forward unknown recipients when you enable catch-all. After storage, MailerZ forwards to the verified destination. Visible From stays the original sender. Envelope return path may use SRS. Delivery history records the destination response. Gmail can still file the copy in spam.

Outbound

Gmail or Outlook opens SMTP to MailerZ with a generated password. MailerZ authenticates, checks the From identity, applies plan limits, and submits. 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) authorize sending. They do not place mail in Primary.

Alignment depends on the visible From matching those records. A leftover inbound rewrite from an old forwarder still breaks filters even if the new SMTP is clean. Delete leftover MX.

Why one operator matters

When inbound vendor A and SMTP vendor B disagree, you have no single event. “We forwarded it” and “we never received a send” can both be true. One history with timestamps and remote SMTP responses is the operational reason to collapse the patchwork.

Recovery storage is 14 days on Free and 90 days on paid. That window is hop evidence, not a seven-year archive. The mailbox you search next year is still Gmail or Outlook.

Self-send remains a bad test on both hops. Gmail can short-circuit a message from an account to itself and skip the public MX path. You will think inbound failed, or think outbound worked, when you never left the mailbox. Probe from another provider. Title the message uniquely so history and destination search match.

Loops look like vanishing mail. Do not set a destination to another alias on the same domain that routes back. Destinations are real Gmail or Outlook inboxes. SMTP From identities must be aliases you actually mapped and, on paid plans, approved for send-as.

Catch-all is not a substitute for mapping the From addresses you will send as. An unknown local-part held on Free will not become an approved SMTP identity because someone emailed it once. Create the alias, then create the send-as identity.

Step-by-step setup and decision path

Cut inbound first. Swapping SMTP before MX works is how verification mail never arrives.

1. Name the store

   If you need hosted seats and Calendar, buy the suite. If Gmail is the archive, continue.

2. Add one domain and map aliases

   Publish the verification TXT. Map printed addresses to real inboxes. Free allows three aliases.

3. Publish one MX set and delete leftovers

   Copy MailerZ MX. Remove Google, Microsoft, registrar, or old-forwarder MX. Use DNS diagnostics if the public set looks mixed.

4. Prove inbound from a different mailbox

   Unique subject. Unrelated provider. Confirm Header From and history. Self-send lies.

5. Upgrade and create the SMTP credential

   Free stops here. Copy host, port, username, and generated password. Do not paste your Google password into that form.

6. Add Gmail Send mail as or Outlook SMTP

   Field clicks: Gmail send-as guide. Confirm Google’s verification message after it forwards through MailerZ.

7. Send to a second external inbox

   Check visible From. Check the reply path. Check outbound history. Then revoke the old SMTP password so the patchwork cannot send.

Failure modes and proof

Most “SMTP forwarding is broken” reports are leftover MX, Free used for send-as, or a self-send test. Work the evidence.

Proof is a pair: destination copy or sanitized headers, and the MailerZ event with timestamp plus remote response. Do not send SMTP passwords to support. Inbox placement is not proof the setup is correct.

MailerZ workflow and product boundary

MailerZ is a custom-domain email delivery layer. Site: mailerz.net. App: mail.mailerz.net. Point MX at MailerZ. Paid plans add authenticated SMTP so the same domain can send and reply.

What MailerZ does

• Accept inbound mail for verified domains and configured aliases.
• Preserve Header From on the forward.
• Hold unknown recipients on Free; optional paid catch-all forward.
• 14-day store on Free, 90-day store on paid, for recovery and evidence.
• Authenticated SMTP from approved identities on paid plans.
• Delivery history for inbound and outbound hops.

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. Controls: Security and Trust Center.
• Act as an open relay.
• Send newsletters or purchased lists.

Alias ceilings: 3 / 15 / 50 / 200 / 500 across Free, Solo, Starter, Business, Agency. Seats are operators, not mailbox licenses. Free and Solo are one seat. Starter is five. Business is twenty-five. Agency is fifty.

Inbound routing detail: custom-domain email forwarding. This article’s job is the combined inbound-plus-SMTP purchase, not aliases versus plus tags.

Shared mailboxes remain a suite job. If three people must search one legal inbox with vendor retention, forwarding into a founder Gmail plus SMTP send-as is still a hop, not a vault. MailerZ can route legal@ and send as that name on a paid plan. It cannot give you eDiscovery. Do not buy forwarding-plus-SMTP to avoid a store you actually need.

Multi-domain work is a plan-capacity question. Free is one domain. Solo is three domains. Starter, Business, and Agency raise the domain cap along with aliases and send ceilings. An agency that forwards ten client zones needs the domain math first. SMTP send-as then applies per approved identity on those hosted domains.

Plus addressing is not send-as. A Gmail plus tag lives inside one mailbox. It does not publish hello@yourdomain.com on MX, and it does not authorize SMTP From that address. If the printed identity is a domain role, map an alias, then add paid send-as for that exact local-part.

Cost, alternatives, and trade-offs

Inbound-only looks cheaper until replies leave as Gmail. Two vendors look cheaper until the missing hop costs a weekend. A suite looks expensive until you actually needed Calendar.

Annual Starter, Business, and Agency billing includes two months free relative to paying monthly for a year. Solo has no monthly option. Count month-end bursts against the hourly send-as cap before you pick Solo.

Cloudflare Email Routing is inbound routing. It does not become MailerZ leftover-MX handling, stored failed hops, or authenticated send-as because this article named it. ImprovMX is a closer forwarding class; compare live plans. Google’s packaging: Google Workspace — product overview.

Do not score “best” by invented review counts. Score it by an external inbound copy plus an external outbound copy plus two history rows.

Time-box rollback. Keep the previous MX hostnames in a note until two external inbound tests pass. Keep the previous SMTP password until outbound proof passes, then revoke it. If you cancel the old forwarder and the old relay on the same afternoon without tests, you have no inbound and no send-as. That is how a “best service” cutover becomes an outage.

Authentication records follow the sender. If MailerZ sends, publish the SPF, DKIM, and DMARC values MailerZ shows. Mixing includes from a retired relay “just in case” is how receivers see a policy that authorizes everyone and explains nothing. DMARC alignment still depends on the visible From. Neither vendor can promise the Primary tab.

Compare current competitor prices on their live sites. This article is not ImprovMX’s price list and not Google’s. The economic shape that matters is seats versus a delivery layer: you pay per hosted user for a suite, or you pay for MX and SMTP while Gmail remains the seat you already have.

Delivery history is the reason one operator beats two. When a customer says they emailed hello@ and you see nothing, you need the remote response, not a guess. When a reply never appears on the far side, you need the outbound SMTP result. A service that only forwards, or only relays, will always have a blind side.

Leftover MX after a Workspace trial is the most common inbound lie. Google MX still published next to MailerZ MX means some senders never reach the alias you just tested. SMTP send-as can look perfect while half of inbound still dies at the old host. Query two resolvers. Delete obsolete records only after the intended set is live.

Unauthorized send is a 550 class problem, not a missing feature. MailerZ is not an open relay. If the From identity is not approved, or the domain is not hosted, the session fails permanently. That is different from a temporary 4xx at a destination mailbox. Do not “fix” a 550 by adding a second SMTP vendor.

FAQ

Key takeaways

• An email forwarding service with SMTP is two hops, not one toggle.
• Free inbound is not send-as. Paid plans add authenticated SMTP.
• Prove inbound before you attach Gmail Send mail as.
• Publish one MX set. Leftover MX is a hard stop.
• Remove leftover SPF includes when you retire the old relay.
• Header From stays original on MailerZ inbound. Envelope SRS is the allowed rewrite.
• Self-send lies. Test from another mailbox both ways.
• Plan limits are capacity, not an inbox SLA.
• MailerZ is not SOC 2, not IMAP, and not a bulk sender.

Conclusion and next action

If you came here for the best email forwarding service with SMTP send-as, buy the operator that can show both hops. Keep the inbox. Cut MX cleanly. Prove inbound. Then attach paid SMTP and prove outbound. Do not stitch a free forwarder to a random relay and call it a stack.

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

Next action: add one domain, create one alias, send a uniquely titled message from a mailbox that is not the destination. When that lands, upgrade, add SMTP, and repeat outward. The MailerZ documentation has the field maps. The register path is one domain.

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