A custom From address that reverts to Gmail or Outlook is almost never “DNS randomly failing.” The composer showed hello@yourdomain.com. The received copy shows you@gmail.com or a Microsoft account. The client sent through the mailbox it actually owns. Display names, “send through Gmail,” unbound Outlook identities, and Free (no send-as) all produce that revert. Proof is Header From on a third-party copy.
Quick answer for custom from address not working
The mailbox provider will always prefer its own identity unless you attach authenticated SMTP and the client uses it. Gmail documents Send mail as in Google Gmail Help — Send mail from a different address. If you choose send through Gmail, recipients still see Google’s story. Outlook on the web often cannot store third-party SMTP at all. MailerZ Free has no send-as. Paid SMTP plus an approved From is the durable path. Unauthorized From gets 550 / 550 5.7.1. Some clients then silently fall back to Gmail or Microsoft instead of showing the 550. That fallback is the revert.
Forwarding does not set From on replies. Inbound Header From stays the original sender. Your reply is a new message. Product path: send and reply. Outlook field map: the previous article in this cluster. This page is the diagnosis when the From line lies.
Do not enable catch-all to fix a revert. Catch-all is inbound. Do not add leftover MX. Do not buy a Workspace seat only to get a From you can get from SMTP. Decision: fix the client path, or accept that this profile replies as Gmail or Outlook.
Prove inbound, then attach paid SMTP. The composer is not evidence.
Start free — one domainThe real decision when From keeps snapping back
Operators treat the revert as a MailerZ outage. History shows no send, or a 550 they never saw. The customer saw Gmail. Three different stories. The shared fact is the client did not submit SMTP as the domain, or the server refused and the client hid the refuse.
Decision criteria. Can you open a received copy? If no, stop guessing. If Header From is the domain, you do not have a revert. You have a destination filter or a human looking at the wrong message. If Header From is Gmail or Microsoft, you have a client path problem. If there is no received copy and history is 550, you have authorization or Free plan, not a cosmetic revert.
Gmail revert patterns
- Send mail as added, “send through Gmail” selected.
- SMTP saved, then Gmail reset the account after a password change.
- User picks the Gmail identity from the From picker by habit.
- Confirmation of the alias succeeded (inbound works) and nobody tested SMTP.
Outlook revert patterns
- Display name set to the domain. Outgoing server still Microsoft.
- New Outlook or OWA cannot store the SMTP user.
- Domain added as Exchange. Autodiscover fails. Profile falls back.
- App update hides the outgoing server. AUTH disappears.
Agencies should reproduce on the same build the client uses. Reproducing on classic Outlook and shipping new Outlook is how the revert “comes back on Monday.”
Security: a revert is better than a successful send as a domain you do not control. Do not ask MailerZ to accept any From so the client stops falling back. That would be an open relay. 550 is correct. Teach the client to show errors instead of hiding them.
Plus tags and lookalikes: sending as hello+tag@ or helo@ when only hello@ is approved will 550 or revert. MailerZ does not strip plus tags on custom domains. Create the exact string or stop using it.
Shared mailboxes in Microsoft 365 that already send as the domain are not a revert. They are a different product. Leave them. MailerZ SMTP is for people who kept Gmail or a personal Outlook as the store.
Technical mail flow when From reverts
Intended path: client → MailerZ SMTP AUTH → approved From → SPF/DKIM as published → recipient. Revert path: client → Gmail or Microsoft submission → their From. SMTP in IETF RFC 5321 — Simple Mail Transfer Protocol does not care what the composer painted. Receivers care about Header From versus authentication. Specs: IETF RFC 7208 — Sender Policy Framework (SPF), IETF RFC 6376 — DomainKeys Identified Mail (DKIM), IETF RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC).
MailerZ inbound still preserves Header From and uses SRS on the envelope. That inbound success is why people think send-as “was working.” Receiving as the domain never configured sending as the domain.
Caps can look like a revert if Outlook retries through Microsoft after a hourly 550. History will show the 550 cluster. Solo is 20/hour and 2,500/month. Starter 40/5,000. Business 60/12,000. Agency 60/20,000. Space the sends.
Leftover MX does not revert From. It splits inbound. Still delete it. Mixed MX is a hard stop for receiving. Troubleshooting for public resolvers.
Step-by-step fix
- Capture a received copy of the “reverted” message. Save Header From and Authentication-Results. This is the baseline.
- Check the plan. Free cannot send-as. Upgrade. Confirm the alias exists exactly.
- Gmail: Send mail as → send through MailerZ SMTP, not through Gmail. Copy host, port, encryption from the dashboard. Guide: Gmail send-as.
- Outlook: Manual outgoing server on a client that can store AUTH. Classic over web. Do not add Exchange autodiscover for MailerZ.
- Pick the domain From on send. A correct identity still loses if the picker is on Gmail.
- Send to a third mailbox. Compare Header From to baseline. Then send again after an hour and after a client restart.
- If 550 appears, read history. Unauthorized From and unhosted domains are working as designed. Fix the identity, not the error text.
Docs: docs. Features: features. Pricing: pricing.
Worked examples
A founder added hello@ in Gmail, left “send through Gmail,” and printed business cards. Recipients saw maya@gmail.com on behalf of hello@. She switched to MailerZ SMTP on Solo. The next received copy showed hello@ in Header From. Old threads did not rewrite. She emailed vendors once.
A bookkeeper used Outlook on the web. From kept snapping to the Microsoft account. Desktop classic Outlook held SMTP. Web stayed inbound-only. The handoff said so. No more “it broke again” tickets after she used the phone’s Outlook app.
An intern sent as support@ from a picker that still had their Gmail selected. SMTP was fine. Training was not. Three misses in a week. They pinned a note. Software will not save a habit.
A shop hit Solo’s hourly cap. Outlook retried via Microsoft. Recipients saw a mix of domain and Outlook From. History showed 550s. They moved bursts to Starter and stopped desktop rules that sprayed notices.
An agency “fixed” a revert by enabling catch-all FORWARD. Spam rose. From still reverted. They undid FORWARD and configured SMTP. Two problems had been collapsed into one Friday.
A team had leftover Google MX. Inbound was random. They thought From was reverting because some tests never arrived. Tests from Gmail to Gmail were short-circuits. Unrelated mailbox plus leftover MX deletion ended the ghost story.
If some tests never arrive, check leftover MX before you rotate SMTP passwords.
Open DNS troubleshootingFailure modes and proof
| Symptom | Likely cause | Proof |
|---|---|---|
| On behalf of Gmail | Send through Gmail. | Received headers. Gmail send-as setting. |
| Microsoft From | Unbound Outlook or web client. | Account list. Desktop SMTP present? |
| Composer domain, headers Gmail | Display name only. | Raw Header From. |
| Silent revert after 550 | Free, unauthorized From, or cap. Client hid the error. | History SMTP text. |
| Works then dies after app update | Outgoing server wiped. | Re-open identity. Re-paste pair. |
| Self-send looks fine | Gmail short-circuit. | Third mailbox. |
| Some people see domain, some Gmail | Two operators, two client paths. | Each person’s received copy. |
| Inbound missing | Leftover MX. Not a From revert. | Two public resolvers. |
Proof is always a received message plus history. Sent folders lie. Destination spam can hide a successful send-as. Inbox placement is not an SLA.
MailerZ workflow and product boundary
Secuno LLC operates MailerZ. Site: mailerz.net. App: mail.mailerz.net. MailerZ cannot force Gmail or Outlook to keep a From picker selected. It can accept paid SMTP from approved identities and 550 the rest.
What MailerZ does
- Inbound forward with Header From preserved. Envelope SRS only.
- Paid SMTP from approved aliases.
- 550 for unauthorized From and unhosted domains.
- Hourly and monthly caps.
- Hop history 14 days Free, 90 paid.
What MailerZ does not do
- Send-as on Free.
- Control Microsoft or Google composer UI.
- IMAP, Exchange autodiscover, or Calendar.
- Open relay so every From succeeds.
- Inbox SLAs, review counts, SOC 2, ISO 27001, HIPAA. Controls: Security and Trust Center.
Plans: pricing. Free $0, 1 domain, 10 aliases, 1 seat, 14-day store, send-as disabled, SMTP and API disabled. Solo $40/year, 5 domains, 25 aliases, 90-day, 2,500 outgoing, 20/hour. Starter $8 or $80, 8/50/5, 5,000, 40/hour. Business $19 or $190, 25/200/25, 12,000, 60/hour. Agency $39 or $390, 100/500/50, 20,000, 60/hour. Unlimited is $99/month or $990/year. Annual Starter, Business, and Agency include two months free versus monthly. Solo is yearly only.
Cost, alternatives, and trade-offs
| Approach | You get | You give up |
|---|---|---|
| Paid SMTP + client that stores AUTH | Stable Header From when the picker is right. | Manual setup. Caps. |
| Accept Gmail or Outlook From | No SMTP work. | Brand. Thread forks. |
| Workspace or Microsoft 365 mailbox | Native From in that suite. | Per-user price. Google Workspace — product overview |
| Display name cosmetics | Composer looks branded. | Receivers still see the mailbox. |
Best practice for custom from address not working: received copy first, paid SMTP, exact approved From, a client that stores AUTH, picker discipline. Forwarding alone will always revert replies to Gmail or Outlook. That is the product boundary, not a bug.
If legal mail must live in a vendor archive, the revert conversation is separate from retention. MailerZ hops last 14 or 90 days. Put holds in the mailbox you already pay for.
After every Outlook “new experience” toggle or Gmail account recovery, re-prove Header From. The SMTP pair does not change. The menu does. Re-paste before you rotate secrets or file a panic ticket.
Two operators need two proofs. One person’s Gmail SMTP success does not cover the bookkeeper on OWA. Write both client names in the handoff. The revert that “only happens for Sarah” is Sarah’s client path.
Do not combine a From-revert fix with a registrar transfer or an MX cutover. One moving part per window. Finish leftover MX. Wait. Then attach SMTP. Mixed changes produce war rooms that solve nothing.
The client rewrites From when SMTP is missing or rejected
Why your custom From address reverts to Gmail or Outlook is usually the mail client falling back to the mailbox identity. Gmail Send mail as without a working MailerZ SMTP pair, or Outlook without the manual SMTP identity, will send as @gmail.com or the Outlook address. Free cannot finish send-as. A 550 on the pair makes many clients silently revert. Copy host, port, and TLS together. Set From to an identity you created. Catch-all does not mint a From. Creating inbound hello@ does not approve outbound.
Confirm /pricing. Solo is forty dollars per year when the domain From must travel. Hourly and monthly ceilings are on the cards. Unauthorized send is 550 5.7.1. MailerZ is not an open relay. Do not paste the Gmail password into a CMS as a workaround. Do not mail the secret to support.
SPF, DKIM, and DMARC must align with the From you want. Two SPF records permerror. A green checker is not Primary. Dest still classifies. We do not rewrite Header From on inbound. Envelope SRS only. If you send through Gmail’s servers, Gmail may show the mailbox From. That is the client, not MailerZ rewriting a stored message.
Prove inbound separately. Leftover MX is a hard stop for replies, not the usual cause of a revert. Self-send is a bad gate. Probe send-as to a third mailbox. Open original. Read the Header From. If it is still @gmail.com, the client did not use the pair.
A Send-mail-as that never saved SMTP
An operator checked Send mail as, skipped SMTP, and watched every reply revert. They added the dashboard pair, sent one probe, Header From stayed on the domain. Related: send and reply, docs, features. Google’s Send mail as help. Not SOC 2. Not an inbox SLA.
Close
Paid plan, identity created, pair in the client, one foreign probe, Header From intact on original. If it reverts, the client did not submit through MailerZ. Start free only for inbound. Sign in if the zone already lives here. That is why your custom From address reverts to Gmail or Outlook.
Agencies keep pair-per-client in the dest client settings. Shared SMTP is how the wrong From appears. Rotate on offboard.
Outlook versions and Gmail aliases
Outlook labels for SMTP identities vary by version. If the identity is not the MailerZ pair, Outlook sends as the mailbox. Gmail Send mail as that is “treated as an alias” without SMTP also reverts. Open original. If Return-Path and Header From disagree in a way that shows the mailbox, the client did not submit through MailerZ. Copy the pair again. Paid plan. Identity created. Confirm /pricing.
Inbound leftover MX does not usually rewrite outbound From. Do not delete MX to fix a revert. Fix the client SMTP. Self-send still lies for inbound proof. Related: send and reply, docs. Google Send mail as help.
Close
Original shows domain From after one foreign send, or the client still owns From. Start free for inbound only. Sign in if the zone already lives here. That is why your custom From address reverts to Gmail or Outlook.
Agencies: do not share one pair across Outlook profiles. Rotate on offboard. Unauthorized send is 550. Not an open relay. Not SOC 2.
Phone clients
iOS and Android mail apps often send as the mailbox unless you add the SMTP identity separately. A desktop Gmail setting does not travel to the phone. Open original from a phone-sent test. If Header From is @gmail.com, the phone did not use the pair. Add SMTP on the phone or stop sending role mail from the phone. Confirm /pricing. Related: send and reply, docs.
Start free for inbound only. Sign in if the zone already lives here. That is why your custom From address reverts to Gmail or Outlook on mobile after desktop looked fixed.
Sign-off
Paid pair in every client that sends, identity created, original shows domain From from desktop and phone, inbound leftover not used as the “fix.” Confirm /pricing. That is why your custom From address reverts to Gmail or Outlook — and how you prove it stopped.
Delegates and send-as
A Gmail delegate may not inherit your SMTP identity. They send as the mailbox. Train delegates or add the pair on their side if they must show the domain. Open original on a delegate-sent test. Confirm /pricing. That extra fact is why your custom From address reverts to Gmail or Outlook after you “fixed it” on one user only.
A second profile on the same laptop can also omit SMTP. Test the profile that actually sends customer mail, not the one you used for the screenshot.
Free MailerZ cannot supply the pair. If the identity was created on a trial of paid send-as and the workspace dropped back to Free, the client will revert to Gmail the next time it cannot AUTH. That is a plan problem, not a “Gmail is broken” problem. Solo is $40 per year when one person needs the pair. Starter and above raise outgoing caps. Confirm pricing before you tell a client the identity is permanent. Copy host, port, and TLS from the dashboard again after any plan change. Folklore 587 from a forum is how the identity looks saved and still reverts.
Phone mail apps cache the old password and the old From. After you paste a new pair, send a unique subject from the phone, then open the raw message on a third mailbox. Desktop success plus phone revert is two profiles, not two products. Leftover MX can also swallow the Gmail confirmation message that finishes Send mail as. Exclusive MX first, then the pair, then the phone test. If the raw From is still the Gmail address, the identity never attached on that profile.
Read the raw From, not the composer
Composer chrome can show the domain while the hop still sends as the Gmail or Outlook mailbox. Open the original on a third mailbox. If Header From is still the consumer address, the SMTP identity never attached on that profile, the plan is Free, or leftover MX ate the confirmation. Fix the pair and the MX, then send again from the phone and the desktop. The composer is not proof.
FAQ
What is the safest way to handle custom from address not working?
Ignore the composer. Read Header From on a message received in an unrelated mailbox. If it shows Gmail or Microsoft, you are not using paid SMTP or the identity is unbound. Copy the MailerZ dashboard pair into Gmail Send mail as or Outlook manual SMTP. Free has no send-as.
Does this require a new mailbox?
No. The revert happens because the client owns a Gmail or Outlook mailbox and falls back to it. MailerZ is not IMAP. Keep that store. Attach SMTP so Header From can be the domain.
Will it work with Gmail or Outlook?
Yes on paid plans when SMTP is actually selected. Gmail’s “send through Gmail” and Outlook web often revert. Classic Outlook and Gmail SMTP through MailerZ hold the identity. Prove a received copy after every client update.
What DNS records are involved?
Inbound MX must be one set. Outbound SPF, DKIM, and DMARC must authorize MailerZ. A revert is usually a client path, not leftover MX. Leftover MX still breaks inbound and should be deleted anyway.
What should I test before production?
Send from the client you will use to a third mailbox. Open the raw headers. Header From must be the domain. If you see on-behalf-of or a Gmail From, fix SMTP before you print more stationery.
Key takeaways
- Composer From is not Header From.
- Forwarding never sets reply identity.
- Free has no send-as. Clients may hide the 550 as a revert.
- Gmail “send through Gmail” produces on-behalf-of.
- Outlook web often cannot store SMTP.
- Prove a third-party received copy after every client update.
- Catch-all does not fix From.
- Caps and unauthorized From are not cosmetic bugs.
- Inbound Header From stays original. Envelope SRS only.
- MailerZ is not IMAP, not a suite, and not SOC 2.
Conclusion and next action
If you came here because a custom From address reverts to Gmail or Outlook, open a received copy and believe that header. Then attach paid SMTP on a client that stores AUTH, pick the approved From, and prove again. The mailbox you already use will always win until you give it a real submission path.
MailerZ receives on Free and sends on paid plans from approved identities. It cannot lock Microsoft’s picker. Next action: save one reverted header, upgrade if needed, paste the dashboard pair, and send a test to an unrelated mailbox.
Ready to stop the From revert
Start free to prove inbound. Pay when SMTP must carry From.
Free receives. Paid send-as uses the dashboard host, port, and encryption pair.
Review quarterly, or sooner if Gmail or Outlook send-as labels change. Author: MailerZ editorial, Secuno LLC.