Header From versus Envelope From is the detail that decides whether a forwarded message still looks like the person who wrote it, and whether SPF on the next hop can pass. They are not the same field. Teams that collapse them into “the From address” pick the wrong product, rewrite the wrong layer, and then blame Gmail. MailerZ rewrites the envelope for forwarding and leaves Header From, Subject, Date, Message-ID, body, and MIME as the sender wrote them.
Quick answer for header from vs envelope from
Envelope From is the address in the SMTP MAIL FROM command. Receivers often store it as Return-Path. Bounces go there. SPF, on that hop, is evaluated against the domain of that envelope identity. IETF RFC 5321 — Simple Mail Transfer Protocol is the envelope conversation. Header From is the From: field inside the message. People read it. DKIM often signs it. DMARC’s identifier alignment uses it.
When you receive on a custom domain and forward into Gmail, the second hop is a new SMTP session. If the forwarder keeps the original Envelope From, Gmail may check SPF against a domain that never authorized the forwarder’s IP. That check fails even though the human sender was honest. Sender Rewriting Scheme (SRS) changes the envelope so the forward hop can pass SPF. It should not have to change Header From. If a product rewrites Header From to the forwarder’s address, you lose the sender you needed for support, abuse, and trust. See email forwarding and features.
MailerZ uses SRS on the envelope only. That is the product boundary. When you send as the domain on a paid plan, Header From should be the named alias you intend. Copy SMTP host, port, and TLS or STARTTLS from the dashboard. Do not invent ports. Free has no send-as. Troubleshooting and tools help you read what actually arrived.
Proof is original headers on a third mailbox. Conversation view in Gmail will hide Envelope From and sometimes collapse Header From. Self-send can skip the forward hop. If you cannot name which From failed, you are not debugging yet.
User problem and decision criteria
A founder sees “via mailerz” or a Return-Path they do not recognize and concludes the service rewrote their brand. Often only the envelope changed. The visible From is still the customer. They then demand a product that “doesn’t change From,” meaning they want no SRS, and the next week Gmail fails SPF on the forward hop. The opposite founder wants every message to show the company as From on inbound, so a vendor rewrites Header From. Support can no longer tell who wrote. Both people used the word From. They needed two words.
Decision criteria: can the vendor state in writing that Header From, Subject, Date, Message-ID, and body stay intact; do they rewrite envelope only, and how (SRS); can you open hop history; is leftover MX gone so you are even looking at the right hop; when sending, is Header From a named alias you control.
Criteria that do not belong: inboxing percentages, “we never touch headers” while they rewrite Header From, or treating plus-addressing as envelope theory. you+tag@gmail.com is a Gmail local-part convention, not Envelope From on your domain.
DMARC policy on the sender’s domain is their policy. Your forwarder cannot make their p=reject kinder by lying about Header From. Alignment is on the identifier. Honest Header From plus a rewritten envelope is the forwarding-safe pair. Lying Header From plus a pretty UI is how phishing-looking mail is born from a well-meaning rewrite.
Reply-To is a third field. It is not Envelope From. People set Reply-To to a ticket address and think they changed MAIL FROM. Bounces still go to the envelope. Ticket routing still follows Reply-To or Header From depending on the helpdesk. Name the field in the runbook.
Agencies inherit clients who “fixed SPF” by adding the forwarder’s include to the sender’s domain. You cannot edit a customer’s bank’s SPF. SRS exists because that edit is impossible. If a salesperson says you must add every sender to SPF, they do not understand header versus envelope.
Outbound send-as is the inverse lesson. You want Header From to be billing@yourdomain. Envelope From on that hop should be a domain you authorize in SPF—the sending identity the dashboard documents. If Gmail “Send through Gmail” is left on, Envelope From may be Gmail’s and Header From your domain. DMARC fails. That is still header versus envelope, now on the way out.
Technical mail flow
Hop one: the sender’s server delivers to your MX. Envelope recipient is the alias. Envelope From is the sender’s bounce address. Header From is whoever they put in the message. Your host accepts, holds, or rejects based on local-part policy.
Hop two: the alias service forwards to Gmail or Outlook. New MAIL FROM. MailerZ applies SRS so the envelope domain is one the forward hop can SPF. Header From stays. Receivers that show “via” are often commenting on the envelope or an authentication result, not announcing that the human From changed.
DKIM signatures cover selected header fields. If a forwarder mutates Header From, the signature breaks and DMARC cannot use DKIM alignment. Leaving Header From intact preserves the sender’s signature for receivers that still see it. ARC, when present, is additional authentication chain information. This article does not claim MailerZ is an ARC product beyond what the site documents. Trust the headers you can open.
SPF on hop two without SRS often fails. That failure is not “the sender is a spammer.” It is “this IP was not in the original domain’s SPF.” Teams who then rewrite Header From to pass a naive filter have solved the wrong exam question.
Outbound paid send-as: you authenticate to the dashboard host. Envelope and Header From should both be identities you are allowed to use. Open relay is 550. Disallowed authenticated traffic is 550 5.7.1. Free cannot send-as.
Step-by-step setup / decision path
- Write the two definitions on one page: Header From = visible
From:. Envelope From =MAIL FROM/ Return-Path. - Confirm leftover MX is gone so the hop you inspect is MailerZ, not leftover Google.
- Create a named alias to the Gmail or Outlook you already use. Hold unknown.
- From a mailbox that is not the destination, send a unique subject to the alias.
- In the destination, open original / view source. Record Header From and Return-Path. Header From must be the test sender.
- If Return-Path shows an SRS-looking local-part, that is envelope rewrite. Expected on MailerZ. Not a Header From rewrite.
- If Header From is the forwarder’s brand, the product failed the intact-header rule. Do not go live.
- For paid send-as, send to a third mailbox and confirm Header From is the named alias. Copy dashboard SMTP values. Do not send through Gmail’s servers for that identity.
- Teach the team to say which From they mean in tickets. “From is wrong” is not a bug report.
Filters that match Header From are fine. Filters that match Return-Path will catch SRS strings and confuse people. Document which field the filter uses.
Helpdesks that key off Envelope From will mis-thread forwarded mail. Prefer Header From or Message-ID. That is a destination setting, not an MX setting.
Failure modes and proof
Header rewrite sold as “branding”: you cannot see the customer. Proof: original From is the forwarder.
No SRS, SPF fail on Gmail: proof in Authentication-Results on hop two. The fix is envelope rewrite, not a new mailbox.
Conversation view: you thought Header From changed. Proof: open original.
Self-send: no forward hop. Proof: third mailbox.
Leftover MX: you inspected the wrong host’s rewrite policy. Proof: public MX lookup.
Send through Gmail: Header From custom, envelope Gmail. DMARC fail. Proof: authentication results on a third mailbox.
Token stuffed in SPF to “fix envelope”: duplicate or broken SPF. Wrong layer.
Reply-To mistaken for envelope: bounces still go elsewhere. Proof: Return-Path versus Reply-To in source.
Free send-as: no outbound Header From you control. Proof: plan page.
Open relay after a fail: 550. Do not remove auth to “keep the old envelope.”
Plus-address myths: not your domain’s envelope. Proof: the address is still @gmail.com.
MailerZ workflow and product boundary
MailerZ is custom-domain aliasing and forwarding with optional paid send-as. Secuno LLC operates mailerz.net. The app is mail.mailerz.net. Not Workspace, not IMAP, not an open relay.
Envelope SRS only. Header From, Subject, Date, Message-ID, body, MIME intact. Exclusive MX. Named aliases. Hold unknown on Free. Recovery fourteen days Free, ninety paid. Copy SMTP from the dashboard on paid send-as. Solo: forty dollars a year, twenty-five aliases, 2,500 outgoing per month, 20 send-as per hour. Starter eight or eighty. Business nineteen or one hundred ninety. Agency thirty-nine or three hundred ninety. Quote live pricing.
This page does not invent SOC 2, ISO, HIPAA, SLAs, inboxing rates, or ARC guarantees beyond what you can read in a received message. “Via” in a UI is not a MailerZ feature name.
Cost, alternatives, and trade-offs
A mailbox suite does not remove header versus envelope. It only changes which product’s hop you are on. Buying seats because Gmail showed “via” is the expensive misread.
A privacy-mask app hides Header From on purpose. That is a different job from durable brand aliases. Do not use a mask to “fix SPF.”
Bulk ESPs rewrite tracking and sometimes From for campaigns. Operational replies should keep an honest Header From. Split those streams.
Doing nothing leaves you unable to explain a DMARC failure. The ten-minute original-header test is cheaper than a week of vendor blame.
Agencies should paste Header From and Return-Path into the ticket, not a screenshot of the conversation list. That paste is the deliverable.
If a client demands Header From rewrite so “everything looks like support@,” refuse or use a helpdesk that sets From on outbound only. Do not rewrite inbound customer mail.
Legal holds and abuse mailboxes need the original Header From. A rewrite turns a harassment report into “the forwarder sent this.” If you operate a role address that receives threats or invoices, intact headers are an operational control, not a nicety. Envelope SRS does not remove that evidence.
Display names are not Header From. Jane Doe <bank@example.com> can still be phishing while the envelope is rewritten. Teach people to open original, not to trust the friendly name. The detail that changes everything is still the two addresses, not the caption.
Mobile Gmail often hides Show original. Proof may need the desktop settings path. Write that in the team wiki so a phone-only founder does not conclude the headers “do not exist.”
What people see versus what SMTP returns
Header From versus envelope From is the email detail that changes everything. Header From is the visible sender. Envelope MAIL FROM is the return path SMTP uses for bounces. MailerZ rewrites only the envelope with SRS. It never rewrites Header From, Subject, Date, Message-ID, body, or MIME. Dest auth and humans see the original Header From. That is why forwarded mail can still align better than a forwarder that stamps its own From.
A privacy-mask product hides a dest on a provider domain. A suite mailbox From is a hosted store. MailerZ is a hop around Gmail or Outlook. Cite the other product. Do not invent parity. Exclusive MX. Leftover MX is a hard stop. Self-send lies.
Outbound send-as sets Header From to an identity you created. The envelope is the authenticated SMTP session. Free cannot finish send-as. 550 on unauthorized From. Confirm /pricing. SPF checks the envelope path. DKIM signs headers including From. DMARC asks alignment. Auth is not encryption. Green checkers are not Primary.
If dest original shows a rewritten Header From, another hop did that. We did not. If envelope after forward is SRS, that is this layer working. Related: features, send and reply, security. RFC 5321, RFC 5322, RFC 7208, RFC 6376, RFC 7489.
A ticket that blamed SRS for a missing name
A user opened the dest list view, saw a rewritten return path, and thought MailerZ changed the From. Open original. Header From was intact. Envelope was SRS. They stopped “fixing” DNS. Related: troubleshooting, docs. Not SOC 2. Not HIPAA.
Close
Teach the team: Header From is the person. Envelope is the path. We rewrite envelope only. Print original before you change MX. Start free to prove inbound. Sign in if the zone already lives here. That is header From versus envelope From, the detail that changes everything.
Agencies put this sentence in the handoff. Mixed MX plus a rewriting forwarder is two bugs. Delete leftovers. Do not enable catch-all to hide them.
Bounces follow the envelope
DSN goes to envelope MAIL FROM. After SRS, bounces return on the SRS path so the dest SPF story can work. Humans still read Header From. Mixing those in a ticket is how people “fix” the wrong record. Open original. Name both. Related: features, troubleshooting, send and reply. RFC 5321, RFC 3464 for DSN context.
Outbound: your send-as From is Header From. The SMTP user is the authenticated submitter. They must be allowed. Free cannot finish send-as. Confirm /pricing. 550 is not a Header From mystery.
Close
Header From is the person. Envelope is the path. We rewrite envelope only. Print original. Exclusive MX. Start free to prove inbound. Sign in if the zone already lives here. That is header From versus envelope From, the detail that changes everything.
Privacy-mask and suite From are other products. Cite them. Do not invent parity. Not HIPAA. Not SOC 2. Auth is not encryption.
List-Unsubscribe and MIME
We do not rewrite MIME. A List-Unsubscribe header you sent outbound stays. We do not add campaign headers for you. This hop is not a list vendor. Header From on outbound is the identity you created. Envelope is the SMTP session. Confirm /pricing. Related: send and reply, features. RFC 5322.
Start free to prove inbound Header From intact. Sign in if the zone already lives here. That is header From versus envelope From when someone asks you to “add unsubscribe in the forwarder.” We will not rewrite the body to add it.
Sign-off
Open original. Name Header From and envelope. SRS on envelope is this hop. Header From rewrite is another hop. Exclusive MX. Confirm /pricing for send-as. That is header From versus envelope From, the detail that changes everything.
Self-send hides both
Gmail to the same Gmail can skip the hop, so you never see envelope SRS or dest classify. Use another mailbox. Open original. Name Header From and envelope. Exclusive MX. Confirm /pricing for send-as. That extra fact is header From versus envelope From when the ticket says “it works when I email myself.”
After the foreign probe, write both values in the ticket before anyone edits DNS. Mixed MX plus a rewriting forwarder is two bugs. Delete leftovers first.
How to read Authentication-Results
Open original and find Authentication-Results. SPF names the envelope domain it checked. If that domain is an SRS string on this hop, you are looking at hop two, not the sender’s own SPF. DKIM names the d= domain that signed Header From and other fields. DMARC pass needs alignment on Header From with one of those two. A fail on SPF after forward plus a pass on DKIM with intact Header From is a common honest pair. It is not a reason to rewrite From.
If Header From in the same source is already the forwarder’s brand, stop. That hop rewrote the identifier. MailerZ does not. Confirm MailerZ pricing only if you need send-as so outbound Header From is a named alias. Authentication-Results is dest evidence. It is not an inbox SLA and not a reason to buy Unlimited.
FAQ
- What is the safest way to handle header from vs envelope from?
- Treat Header From as the visible sender you must keep intact for humans and DMARC. Treat Envelope From (SMTP MAIL FROM / Return-Path) as the hop that may be rewritten so a forwarder can pass SPF. MailerZ uses SRS on the envelope only. Prove both on a third mailbox using original headers. Do not pick a forwarder that rewrites Header From to hide the sender.
- Does this require a new mailbox?
- No. Header versus envelope is a property of the message hop, not a reason to buy IMAP. MailerZ is Mail Box portal webmail, not IMAP. Gmail or Outlook stays the store. A new seat does not fix a Header From rewrite.
- Will it work with Gmail or Outlook?
- Yes as destinations. Those products show Header From in the UI and hide Envelope From unless you open original. Conversation view can lie. Always open raw headers for the proof. Self-send from Gmail to Gmail can skip the forward hop entirely.
- What DNS records are involved?
- SPF is evaluated on the Envelope From domain of the hop being checked. DKIM signs header fields including From. DMARC aligns Identifier From (Header From) with SPF or DKIM. MX still decides who receives. Sending records on your domain matter when you send-as. They do not replace intact Header From on inbound forwards.
- What should I test before production?
- Send a uniquely titled message from an unrelated provider to a named alias. Open original. Confirm Header From is the test sender. Note Return-Path may show SRS. Then send as your domain from paid SMTP if you use it and confirm Header From is the alias. Self-send is not this test.
Key takeaways
- Header From is the visible sender. Envelope From is SMTP MAIL FROM / Return-Path.
- SPF follows the envelope hop. DMARC aligns on Header From.
- Forwarding often needs envelope rewrite (SRS). It should not rewrite Header From.
- MailerZ: envelope SRS only. Headers and body intact.
- Prove both fields on a third mailbox using original headers.
- Conversation view and self-send hide the truth.
- Outbound send-as must not use “Send through Gmail” for a custom Header From.
- Say which From you mean. “From is wrong” is not a diagnosis.
Conclusion
Keep the words separate. Keep Header From honest. Let the envelope do the hop work. If a product cannot state that pair, do not publish MX toward it.
Forward with MailerZ when you want the sender visible and the envelope forwarding-safe. Prove it once on a third mailbox, then print the alias.