DMARC email forwarding fails when the visible sender no longer lines up with the domain that authenticated the message. Alignment is that lineup. A forwarder that rewrites Header From breaks it. A forwarder that only rewrites the envelope can keep DKIM aligned and still let SPF pass for the hop. MailerZ does the second job. A pass is not an inbox promise.
Quick answer for dmarc email forwarding
DMARC asks two questions after SPF or DKIM succeeds: does the authenticating domain align with Header From? IETF RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC) defines that check. SPF alignment compares the MAIL FROM organizational domain to Header From. DKIM alignment compares the signature’s d= domain to Header From. A forward changes MAIL FROM more often than it should change From. If it changes From, both paths die.
MailerZ rewrites the envelope with SRS and leaves Header From, Subject, Date, Message-ID, body, and MIME alone. SPF on the destination hop is then the forwarder’s problem, which SRS is built to solve. DKIM on the author domain can still align if the signed fields were not touched. Product path: email forwarding and troubleshooting. Read headers, not a green badge on a marketing page.
SMTP itself is in IETF RFC 5321 — Simple Mail Transfer Protocol. SPF is in IETF RFC 7208 — Sender Policy Framework (SPF). DKIM is in IETF RFC 6376 — DomainKeys Identified Mail (DKIM). None of those documents promise Primary. Gmail and Outlook still file mail after a pass. MailerZ does not publish an inboxing rate. Confirm MailerZ pricing if you also need send-as. Free receives. Solo is $40 per year when send-as is the job.
If leftover MX is still published, stop. Alignment talk is theater until exclusive MX exists. Some senders never reach the forwarder. Their DMARC result is whatever the old host produced, which you will never see in MailerZ history.
The user problem and the decision criteria
The ticket says forwarded mail fails DMARC. The evidence is a red shield in Gmail or a reject at a bank. The hidden cause is usually a From rewrite, a broken DKIM body hash, or an operator treating SPF fail on the hop as a domain emergency. The decision is whether you keep the original sender visible and accept SPF misalignment, or you stamp your own From and accept that DMARC will treat you as a new author.
| Question | If yes | If no |
|---|---|---|
| Does Header From still show the original person? | DKIM alignment can still work. | The forwarder rewrote From. Fix that first. |
| Does Authentication-Results show dkim=pass aligned? | DMARC can pass on the DKIM path. | Check body edits, From edits, or missing signatures. |
| Is SPF fail or softfail on the hop? | Expected without SRS. Not automatically fatal. | The hop authorized MAIL FROM. Still check alignment. |
| Did you add the destination to the author’s SPF? | Wrong lever. You do not control every sender. | Good. Use SRS on the envelope instead. |
| Is this outbound send-as from your domain? | Different job. Publish your SPF, DKIM, DMARC. | This article is inbound forward alignment. |
People paste the author’s SPF include for MailerZ hoping Gmail will forgive a naive forward. That only helps mail that already used your domain as MAIL FROM. A customer at a bank sending to hello@you.com has the bank’s envelope, not yours. You cannot put every bank in your SPF. SRS exists because that idea does not scale.
People also tighten DMARC to reject on their own domain and then forward other people’s mail to Gmail. Those are different domains. Your p=reject policy does not authorize you to rewrite a vendor’s From. It also does not force Gmail to file your forwarded copies in Primary. Policy on your zone is for mail that claims to be from you.
Technical mail flow
A sender delivers to MailerZ MX. MailerZ matches the envelope recipient to an alias, then forwards to Gmail or Outlook. The destination sees a new SMTP hop. SPF at that hop evaluates MAIL FROM against the connecting host. If MAIL FROM is still the original sender, the hop is not in that sender’s SPF and the result is fail or softfail. If MAIL FROM is rewritten with SRS to a MailerZ-controlled domain, SPF can pass for the hop. That pass aligns with Header From only if the SRS domain and the visible From share an organizational domain, which they usually do not.
DKIM signs selected headers and a body hash. If Header From and the body are untouched, the destination can verify the original signature. Alignment then compares d= to Header From. Same organization, or a strict match if the author asked for strict. That is the usual DMARC pass after an honest forward. IETF RFC 6376 — DomainKeys Identified Mail (DKIM) is the signature. IETF RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC) is the lineup.
A forwarder that adds a footer, re-encodes MIME, or stamps its own From invalidates the body hash or the signed From. DKIM fails. SPF may pass on the hop and still fail alignment. DMARC then fails unless some other signature remains. That is why “we added a brand footer on the way through” shows up as a DMARC incident a week later.
ARC exists to carry authentication results across hops. Destinations may use it. MailerZ does not ask you to treat ARC as a product promise. If a destination ignores ARC, you are back to surviving DKIM plus an honest From. Do not buy a plan because a blog said ARC fixes forwarding. Confirm what the product actually does on features.
Self-send from Gmail to the same Gmail account can skip the public hop and invent a local result. Probe from another provider. Unique subject. Open original. Read Authentication-Results. That is the only alignment test that matches production.
Exclusive MX still matters. If leftover Google MX accepts the first hop, MailerZ never forwards, SRS never runs, and the DMARC conversation you are having is about a different product. Clean MX first. Alignment second. Tools help you list hosts. They do not interpret shields.
Step-by-step setup and decision path
Prove exclusive MX
Two public resolvers. Only MailerZ hosts. Leftovers make alignment tickets fictional for the half of senders who never arrived.
Map the printed alias
HOLD on an unknown local-part is not a DMARC fail. Create the name you printed. Then forward.
Send from a third mailbox
Not the destination. Unique subject. Confirm the hop in history. Empty history is not a shield problem.
Open original and read Authentication-Results
Note spf=, dkim=, and dmarc=. Note whether dkim is aligned. Note whether Header From is still the original person.
Do not rewrite From to “fix” SPF
Stamping your domain as From makes you the author. DKIM and DMARC then need your keys. That is send-as, not forwarding.
Publish your own DMARC only for mail that claims you
p=none, then quarantine, then reject is a send-as path. It does not repair other people’s signatures on inbound forwards.
Failure modes and proof
| What you see | Likely cause | Proof |
|---|---|---|
| dkim=fail and From changed | Forwarder rewrote Header From | Compare From to the original sender |
| dkim=fail and From intact | Body or signed headers mutated | Footer, encoding, or Subject rewrite |
| spf=fail, dkim=pass aligned | Naive envelope, surviving signature | DMARC can still pass. Read dmarc= |
| spf=pass, dmarc=fail | SPF used an unaligned MAIL FROM | SRS domain ≠ Header From org |
| No Authentication-Results | Wrong copy or a filtered hop | Open original. Confirm history 250 |
| Pass and still in spam | Destination policy, not alignment | Not an inbox SLA. Check sender reputation |
Proof is the header block plus the history row. A screenshot of a red Gmail icon without Authentication-Results is not a diagnosis. A green public checker against your domain’s published DMARC is not a diagnosis of a forwarded bank message. The bank’s domain authenticated that message, or it did not, after your hop.
Agencies: each client zone has its own outbound DMARC. Inbound forwards of other people’s mail share the same From-preservation rule. Do not publish a client p=reject and then rewrite vendor From lines on the way to Gmail. Those are opposite jobs.
MailerZ workflow and product boundary
MailerZ is inbound MX plus authenticated SMTP. Envelope SRS only. Header From is never rewritten. That is the alignment-preserving choice. It is not a mailbox, not IMAP, not Workspace, not an open relay. Unhosted or unauthorized SMTP is 550 / 550 5.7.1.
History shows hops MailerZ accepted. It does not show Gmail’s folder. A 250 plus a spam copy is a destination event. HOLD stores unknown local-parts on Free. It does not store a DMARC reject that happened at a destination after the hop.
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, or HIPAA claim lives here.
Send-as is the other DMARC story. When you send as hello@yourdomain.com, you need SPF, DKIM, and DMARC on your domain, and a paid plan. Do not mix that ticket with inbound forwarding alignment. The first is you as author. The second is you as a hop.
Cost, alternatives, and trade-offs
| Choice | What you get | What you give up |
|---|---|---|
| Preserve Header From plus SRS | A chance at aligned DKIM | SPF alignment on the hop |
| Rewrite From to your domain | A hop that looks like you | The original author and their DKIM |
| Add every sender to your SPF | A false sense of control | A record that cannot list the internet |
| Buy a suite mailbox | A store. Quote live | The Gmail archive you already have |
Time is a line item. One third-mailbox probe with headers costs less than another week of SPF folklore. A From-rewriting forwarder costs more than Solo when banks start rejecting. A Free-plan send-as argument still costs more than the upgrade.
If every teammate needs a hosted mailbox, a suite is the honest product. A forwarder will look incomplete because it is incomplete for stored humans. Pretty alignment will not become IMAP. Quote vendors the day you debug. Gmail shield UI changes. The alignment rule does not.
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 DKIM private keys to support. The artifacts that close a dmarc email forwarding ticket are exclusive MX, history 250, Header From intact, and Authentication-Results you can read out loud.
Why SPF alignment often fails after a forward
SPF authorizes a host to use a MAIL FROM domain. After a forward, the connecting host is the forwarder. The original MAIL FROM domain did not list that host. Fail or softfail is the honest result. Softfail is not automatically a DMARC fail. DMARC uses the SPF result only if that MAIL FROM domain also aligns with Header From. A failed SPF result simply does not contribute a pass.
SRS changes MAIL FROM to a domain the forwarder controls so the hop can pass SPF. Useful for bounce handling and for destinations that treat a hard SPF fail as suspicious even when DMARC still has a DKIM path. The new MAIL FROM domain rarely aligns with the original Header From. So SPF can pass and still be useless for DMARC. That is not a bug. That is the split between hop authorization and author identity.
Operators see spf=pass with a MailerZ-looking MAIL FROM and assume DMARC should pass. Then they see dmarc=fail because only the unaligned SPF path succeeded and DKIM was already broken by a footer. The fix is to stop mutating the body, not to add more includes to SPF.
IETF RFC 7208 — Sender Policy Framework (SPF) also caps DNS lookups. Stuffing the author’s SPF with every tool you use is a send-as problem. It does not rescue forwarded third-party mail. Keep those fights in the SPF lookup-limit article. This article stays on alignment.
Destination filters can still discard a message that passed DMARC. Reputation, user marks, and unsolicited volume live at Gmail and Outlook. MailerZ history 250 means the hop was accepted. It does not mean Primary. Do not quote an inbox percentage you invented.
What a From rewrite actually breaks
Some forwarders stamp From as the destination owner so “it looks professional” or so SPF “matches.” The human no longer sees who wrote the mail. The DKIM signature over the original From fails. DMARC alignment, if any, is now to your domain, which did not sign the body. Banks that require aligned DMARC reject. Helpdesks that key tickets on From open cases as you instead of the customer.
The via label in Gmail is a different complaint. It can appear when the hop and the From disagree. Removing via by rewriting From is how you trade a cosmetic label for a reject. Leave the label. Keep the author. If via bothers a founder, explain the hop. Do not break alignment to hide it.
Subject rewrites and disclaimer banners have the same family of failure when those fields were signed. If you must add a legal footer, do it at compose time as the author, not in the forward path. Inbound forwarding is a copy, not a brand studio.
Reply-To games are not From rewrites, but they confuse operators reading the wrong header. Alignment uses Header From. A clever Reply-To does not repair a broken signature. Read the field DMARC actually names.
If you want the long form of envelope versus header, stay with docs and the Received chain until you can name which domain authenticated which identifier. Then decide whether you are debugging a hop or an author.
Aggregate reports and noise
DMARC aggregate reports tell the domain owner who sent mail claiming their From. If you own example.com and publish rua, you see your send-as traffic and any spoofing. You do not get a clean report of every message forwarded through MailerZ from other brands. Those reports go to the other brands. Do not wait on a report to debug a single Gmail copy. Read that copy’s headers.
Forensic reports are rarer and more sensitive. Do not paste them into a public ticket. They can contain message content. The cheap evidence is still Authentication-Results on the copy you already received.
Tightening your own policy because a forwarded vendor message looked red is a category error. Your p=reject does not govern a vendor From. It governs claims of your domain. If spoofing of your domain is the real fear, that is a send-as and monitoring job. If a vendor’s mail looks red after your hop, that is a From-preservation and DKIM-survival job.
Google’s people-first guidance is about pages, not SMTP; see creating helpful, reliable, people-first content. A DMARC article that only says “set p=reject” without naming alignment is how founders break inbound copies they still need to read.
Legal hold is not the 14-day Free store. If counsel needs years, Gmail Vault or Microsoft retention is the archive. Do not treat a DMARC fail as a retention strategy. Two-factor on the destination Gmail is still required after headers look clean.
Paid plans do not change the alignment rule. Solo, Starter, Business, and Agency still must not rewrite Header From. The upgrade changes send-as and limits. It does not make an unaligned SPF path count as an aligned DMARC pass.
Do not mix send-as DMARC into this ticket
Founders paste a red shield from a forwarded vendor invoice and then publish a stricter DMARC record on their own zone the same afternoon. Those events are cousins, not twins. The invoice claimed the vendor’s domain. Your new p=quarantine record will not change that copy. It will change the next message you send as hello@yourdomain.com from Gmail send-as. If that send-as path is still on Free, it will fail for a simpler reason: Free has no send-as.
When you are ready to send as the domain, publish one SPF string, one DKIM selector from the dashboard, and a DMARC record that starts at p=none. Probe from a third mailbox. Read alignment on that outbound copy. That ticket owns your identifiers. The forwarding ticket owns other people’s identifiers that merely passed through your MX. Keep the threads separate so nobody “fixes” inbound by breaking outbound.
Shared inboxes make the mix-up worse. A teammate sees via and tightens DMARC. Another teammate adds a second SPF record from a wizard. You now have a permerror on send-as and the original forwarded invoice still looks the same. Merge SPF. Leave From intact on the hop. Confirm pricing only if the real job is outbound identity.
Outlook and Gmail both show authentication in different UIs. The field names move. The rule does not: Header From versus the domain that passed SPF or DKIM. If you cannot say those two names, you are not done. If you can say them and they match through DKIM, stop adding DNS. The remaining complaint is a folder, a filter, or leftover MX.
Helpdesks that ingest the alias are destinations. If they reject on DMARC, history will show the far-side error. Remap or ask the helpdesk what they require. Do not rewrite From to please a helpdesk parser unless you are willing to become the author and sign as yourself. That is a product change, not a checkbox.
If a second operator needs the same order without a call, send this page plus the MX checklist. Exclusive hosts first. Intact From second. Authentication-Results third. Folder last. That order prevents the most expensive wrong fix: publishing reject on the wrong domain the day a customer invoice looks red.
Subdomains complicate alignment when a vendor signs as mail.vendor.com and displays From as vendor.com. That can still be organizationally aligned. Strict mode on the vendor’s DMARC record can fail the same copy. You do not control their aspf or adkim flags. You control whether your hop mutated From or the body. If the vendor chose strict and their own signature does not match, your forward is not the first broken piece. Say that on the ticket so nobody republishes MX to chase a vendor policy.
IPv6 hops, TLS versions, and STARTTLS banners do not change alignment. They change whether the destination accepted the connection. If history is 250, the SMTP conversation finished. The remaining argument is identifiers and folders. If history is empty, stop talking about DMARC and return to MX. Mixing those layers is how this topic stays expensive.
FAQ
What is the safest way to handle dmarc email forwarding?
Keep Header From intact so the original DKIM signature can stay aligned. Use envelope SRS so the forwarding hop can pass SPF as itself. Do not rewrite the visible sender. Then read Authentication-Results at the destination. A DMARC pass is not Primary.
Does this require a new mailbox?
No. DMARC alignment is a header and envelope problem. 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 evaluate DMARC on the message they receive after the forward. If Header From was rewritten, alignment usually fails. If Header From and DKIM survive, Gmail and Outlook can still pass DMARC and still file the copy in spam. Free has no send-as.
What DNS records are involved?
The author’s SPF, DKIM, and DMARC on the Header From domain. The forwarder’s SPF for the SRS envelope. Exclusive MX so the hop actually happens. Verification TXT is ownership, not alignment. See RFC 7489 for the alignment rules.
What should I test before production?
Send a uniquely titled message from a third mailbox through exclusive MX. Confirm Header From is the original sender. Open original on the destination and read Authentication-Results. Expect SPF on the hop and DKIM on the author. Do not use self-send as the only test.
Key takeaways
- DMARC email forwarding: alignment is Header From versus the authenticating domain.
- One aligned pass is enough. SPF after SRS is often unaligned. DKIM can still pass.
- Never rewrite Header From on the forward. That kills DKIM and the author.
- You cannot SPF-include the entire internet. SRS is the hop. DKIM is the author.
- A pass is not Primary. History 250 is not a folder.
- Exclusive MX first. Empty history is not a shield problem.
- 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 forwarded mail fails DMARC, read alignment before you add SPF includes. Keep the visible sender. Let the envelope carry SRS. Prove the hop from a third mailbox. Open original. Name spf, dkim, and dmarc out loud. MailerZ can preserve From. It cannot file Primary or invent a signature a footer already broke. Start free on one domain and run the headers.
Ready to keep the real sender
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 destination Authentication-Results labels change. Author: MailerZ editorial, Secuno LLC.