DKIM email forwarding works when the hop leaves the signed headers and body alone. IETF RFC 6376 — DomainKeys Identified Mail (DKIM) signs Header From and other fields the author chose. A forwarder may change envelope MAIL FROM with SRS so the next hop can accept the bounce path. It must never rewrite the visible From to the brand or the forwarder. That rewrite is the break. MailerZ uses envelope SRS only. Header From stays the original sender.
Quick answer for dkim email forwarding
DKIM is a cryptographic signature over selected headers and the body. The destination looks up the author’s selector TXT and checks the signature. If a forwarder changes a signed header, the check fails. Most authors sign From. Changing From to via yourdomain or to a role address is how “helpful” forwarding becomes a DMARC fail. IETF RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC) then compares the authenticated domain to Header From. A broken DKIM plus a rewritten From is a double miss.
SPF is a different check on the envelope. IETF RFC 7208 — Sender Policy Framework (SPF) often fails on a naive forward because the connecting IP is no longer the author’s. SRS rewrites MAIL FROM so SPF can pass on the forwarder’s domain. That is allowed. It is not a license to touch Header From. See SRS explained and DMARC and forwarding.
A green DKIM badge is not inbox placement. Gmail and Outlook still filter. MailerZ does not publish an inboxing rate. See green checks are not Primary.
MailerZ Free is one domain, three aliases, 14-day store, unknown held, no send-as. Paid adds 90-day store, more aliases, optional catch-all forward, and send-as. Solo is $40 per year. Starter is $8 or $80. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99/month or $990/year. Confirm pricing. None of those cards rewrite From to “improve” DKIM.
Outbound DKIM for mail you send as the domain is a later job on Solo or higher. This page is inbound forwarding: what the hop must not break on other people’s signatures. Publishing your own selector is publish DKIM for SMTP.
The user problem and the decision criteria
Founders see “via” or a replaced From and think Gmail is broken. The hop rewrote identity. Recipients lose the real sender. DKIM fails. DMARC fails. Support says “forwarding always breaks auth.” That sentence is false for envelope-only SRS and true for From rewrites. The decision is which forwarder you keep.
| What you see | Likely cause | Action |
|---|---|---|
| Header From is now your domain or the forwarder | From rewrite | Leave that product. MailerZ does not do this. |
| Header From intact, DKIM fail, body altered | MIME or footer mutation | Stop adding disclaimers on the hop. |
| Header From intact, DKIM pass, still spam | Filters and reputation | Not a DKIM break. No inbox SLA. |
| Some senders fail, exclusive MX missing | Leftover host | Delete leftovers. Auth never ran on MailerZ. |
| Self-send looks fine | Gmail short-circuit | Third mailbox. Open original. |
| You send as the domain, DKIM missing | Outbound not inbound | Paid SMTP plus dashboard DKIM. Different ticket. |
Competitor marketing that “fixes DMARC by rewriting From” is the anti-pattern. You become the author. Newsletter reputation becomes yours. Customers see the wrong name. That is not dkim email forwarding. That is a new send.
Leftover MX can look like intermittent DKIM failure because half the mail never took your hop. Fix exclusive MX before you debug signatures. Leftover MX.
Technical mail flow
The author submits a message. Their server adds DKIM-Signature over From, often Date, Subject, Message-ID, and the body hash. They send to your MX. IETF RFC 5321 — Simple Mail Transfer Protocol delivery is envelope-level. MailerZ accepts a named alias, stores required content, returns 250, rewrites MAIL FROM with SRS, and forwards to Gmail or Outlook. Header From, Subject, Date, Message-ID, body, and MIME stay as received. The destination verifies DKIM against the author’s domain, then applies filters.
ARC can seal what a hop observed. Destinations may ignore ARC. It is not a substitute for leaving From alone. It is not an inbox promise. See the ARC article already on the site if you need that layer named.
Alignment for DMARC is Header From versus the DKIM d= domain or the SPF envelope domain. SRS can make SPF pass on the forwarder without aligning to the author’s From. DKIM is the usual alignment path after an honest forward. Break DKIM and you often break DMARC even if SPF is green on the hop.
Recovery storage is 14 days on Free and 90 on paid. It is failed-hop evidence, not a place to re-sign mail. MailerZ will not mint a new author signature for a customer newsletter. That would be impersonation.
What forwarding should never break
Header From
The visible author. Signed almost always. Rewriting it is the classic DKIM kill. MailerZ never does this.
The signed header list
If the signature covers Subject or Date, do not “clean” those fields. Do not re-thread Subject. Do not stamp a new Date.
Body and MIME bytes
Footers, tracking pixels, and charset conversions change the body hash. A hop that adds a legal disclaimer breaks DKIM for every sender.
Message-ID when it was signed
New IDs make conversations look new and fail the signature. Leave the identifier alone.
What forwarding may change: envelope MAIL FROM via SRS, Received headers the hop is supposed to add, and the next-hop destination. Those are transport. They are not identity.
What forwarding is not: encryption. DKIM is not TLS and not a vault. See the later security-boundaries article in this series when it ships. Do not tell a customer DKIM hides content.
Step-by-step: prove DKIM survived the hop
Finish exclusive MX and named aliases
Leftovers mean you are not testing MailerZ. Create the alias. Probe from another mailbox. Email forwarding.
Send a message that already has DKIM
A bank, a SaaS receipt, or a colleague’s Workspace. Not a self-send from the same Gmail.
Open original on the destination
Header From must be the author. If it is you or the forwarder, the hop rewrote. Stop and change products.
Read Authentication-Results
DKIM pass or fail with the author’s d=. SPF may show the SRS domain. That mix is expected. Do not “fix” SPF by rewriting From.
Do not treat pass as Primary
Filters remain. No percentage. If you also send as the domain, attach paid SMTP and publish your own DKIM later.
WordPress and campaign tools are outbound. They need approved From and paid SMTP. They are not this inbound proof. Mixing them is how founders rotate DKIM selectors during a leftover-MX outage.
Failure modes and proof
From rewrite. Proof: received From ≠ author. Fix: leave that forwarder. MailerZ boundary is no rewrite.
Footer mutation. Proof: body hash fail, From intact. Fix: disable hop footers.
Leftover MX. Proof: no MailerZ hop, intermittent fails. Fix: delete old hosts.
Author never signed. Proof: no DKIM-Signature on the received original. Fix: that sender’s problem. You cannot invent their key.
Expired or wrong selector at the author. Proof: DNS for their selector fails. Fix: not your zone. Do not publish their selector on your domain.
Outbound confusion. Proof: you are debugging inbound with your SMTP DKIM missing. Fix: split tickets. Free has no send-as.
Self-send. Proof: Gmail never forwarded. Fix: third mailbox. Self-send tests.
Green checker on your domain only. Proof: inbound author signatures never evaluated. Fix: read a real received message, not a marketing scanner on your SPF.
Catch-all spam with broken signatures. Proof: guessed local-parts. Fix: hold unknown on Free; audit before forward. Broken DKIM on spam is normal.
Destination reject after DKIM pass. Proof: hop 250 then destination 5xx. Fix: that is Gmail or Outlook policy, not a From rewrite. Read the status. See troubleshooting.
MailerZ workflow and the product boundary
Add domain, verify TXT, named aliases, exclusive MX, prove inbound. Header From untouched. Envelope SRS only. Not Workspace, not IMAP, not webmail, not an open relay, not SOC 2. Security. Features.
Seats operate the dashboard. They do not re-sign customer mail. Agency at $39 or $390 still does not rewrite From for a client “to pass DMARC.”
Paid send-as signs with MailerZ DKIM for identities you are allowed to send. That is your outbound. It does not replace inbound author signatures. Copy selectors from the dashboard. Do not invent them.
Cloudflare Email Routing and ImprovMX are inbound competitors. Judge them on whether they keep Header From. Compare: Cloudflare Email Routing, ImprovMX. Research, not a promise they match MailerZ.
Failed hops store 14 or 90 days. Use them to see destination SMTP, not to claim a DKIM SLA.
Cost of an honest hop versus a rewrite
Honest SRS is included in receiving. The expensive path is a rewrite that trains Gmail to treat your domain as a newsletter mill. You then buy more tools to “warm” a reputation you created by stealing From.
Free can prove inbound DKIM survival on one domain and three aliases. Solo at $40 per year adds send-as when you need to sign your own From. Starter, Business, and Agency scale domains and send ceilings. Annual paid cards except Solo include two months free versus monthly. Confirm pricing.
Do not buy Workspace to fix a From rewrite. Google Workspace — product overview is a suite. It does not excuse a forwarder that mutates headers. If you need hosted mailboxes, buy the suite for that reason.
Time spent on a green checker during leftover MX is wasted. Exclusive MX, then a received original, then Authentication-Results. That order is cheaper than a week of selector folklore.
Related: Header From vs envelope, does forwarding affect SPF/DKIM/DMARC, Gmail via.
If a vendor offers to “align DMARC by changing From,” treat that as a disqualifier. Alignment by impersonation is how you inherit the sender’s enemies.
Newsletter mail and personal mail fail differently after a rewrite. A rewritten newsletter makes your domain look like a bulk sender. A rewritten invoice makes you look like a collection desk. Intact From keeps those reputations on the authors. That is the operational reason dkim email forwarding must not “help.” See the later newsletter-versus-personal article when you need that split named. This page is the signature rule those cases share.
Display names are not DKIM. Changing “Jane Doe” to “Jane via Billing” can still break a signature if the From header bytes changed, even when the address looks similar. Do not tidy display names on the hop. Recipients can filter. The hop should not redecorate.
Unicode and encoding “fixes” also change bytes. A hop that re-encodes Subject to be “prettier” fails the signed Subject. Leave charset alone. If a destination cannot render a name, that is their client. It is not your excuse to mutate a signed field.
Multiple DKIM signatures can exist on one message. Breaking one signed From still matters if that was the author’s aligned signature. Do not assume a remaining list-unsubscribe signature saves DMARC. Read which d= aligned to Header From. If none do, you failed the useful check.
Agencies document the rule for clients: we will not rewrite From to force a pass. Clients who insist on a vanity From for other people’s mail are asking for a send, not a forward. Refuse or move them to a suite. MailerZ will 550 unauthorized outbound From values. That refusal is the same philosophy as inbound: identity is not decorative.
Proof cadence: after any hop change, after a leftover MX cleanup, and after a vendor migration, repeat one signed third-party message. Keep the .eml. The next auditor who asks “do you rewrite From?” gets a file, not a slogan.
Internal links for the rest of the auth cluster already on disk: SPF and forwarders, authentication diagram, sender reputation. Use them after From is proven intact. They do not replace this rule.
List-ID and mailing-list headers are often added by lists, not by MailerZ. If a list broke DKIM before your hop, you will still see a fail with intact From. Your job is not to “fix” that by rewriting identity. Your job is to keep the hop honest so personal mail that arrived signed stays signed. Lists that mutate bodies will fail at every honest forwarder. That is the list’s problem.
Calendar invites and bounce messages are special MIME. A hop that flattens calendar parts to plain text will fail body hashes and lose the invite. MailerZ does not flatten MIME. If a destination still drops invites, look at the destination, leftover MX, or the author’s own forward. Do not enable a “simplify HTML” feature on a hop you control. If a security appliance in front of Gmail rewrites MIME after MailerZ, that appliance is now the hop that broke DKIM. Name it in the ticket. Do not republish MX to punish the forwarder for a scanner you installed. Copy the appliance vendor and the Authentication-Results line into the same note. The next similar ticket should not restart at leftover MX.
More working detail
A DKIM reading you can do without a lab
Open original. Find Authentication-Results. Read dkim= and the d= domain. If d= matches Header From’s domain and the result is pass, forwarding did not break the signature. DKIM email forwarding is then doing its job even if SPF on the hop is messy. If dkim=fail and Header From was rewritten, you are in the rewrite article. If history is empty, you are in leftover MX, not DKIM.
Do not paste the author’s public key into your zone. You are not them. Your outbound send-as has its own selector from the dashboard. Two worksheets. Mixing them is how people blow SPF lookups and still fail DKIM.
Subject tagging on a hop — “[EXTERNAL]” added by a gateway in front — can break the signed Subject. If your corporate gateway sits after Gmail, that is hop four-plus. If it sits on MX, you left this architecture. MailerZ will not add those tags.
What “never break” does not mean
It does not mean Gmail will show Primary. It does not mean the author’s DKIM was valid to begin with. Unsigned mail can still forward. DMARC may fail. That is the author’s gap, not a MailerZ rewrite. Preserve the bytes anyway. Do not “fix” unsigned mail by changing From.
One more working distinction
Selectors, leftovers, and curiosity
You may see multiple DKIM selector names in reports. Some are the author’s. Some are leftover suite send. DKIM email forwarding inbound does not require you to host their selectors. Curiosity that adds their CNAME to your zone is how you confuse outbound send-as. Leave inbound keys where they are. Publish only the dashboard records for Froms you send.
If your own send-as DKIM fails, that is hop five, not inbound forwarding. Different ticket. Different records. Do not rotate inbound aliases to fix an outbound selector.
A short operating rule
Body hashes and footer injection
Some hops append “forwarded by” footers. That changes the body hash. DKIM email forwarding should never do that. MailerZ does not. If you see a footer you did not write, you have another hop in front or a destination feature. Name it. Do not blame DKIM for a mutate you asked a gateway to do.
Legal disclaimers added by a suite on the way out are outbound. Different hop. Keep inbound MIME boring so inbound DKIM can live.
Field close
What to send support
Timestamp, Message-ID, Authentication-Results screenshot, public MX. Not a password. DKIM email forwarding tickets that include a 550 from send-as are the wrong hop. Say inbound or outbound in the first line. Intact From on inbound is the proof this layer did not break the signature.
Last operating note
If dkim=none, the author never signed. Forwarding did not break what was not there. DKIM email forwarding still must not rewrite From. DMARC may fail. That is their gap. Your job is exclusive MX and intact bytes. Say that in the ticket so nobody rotates your selector.
FAQ
What must dkim email forwarding never break?
Header From, the signed header set, and the body bytes the author signed. A forwarder may rewrite envelope MAIL FROM with SRS. It must not rewrite the visible From to “help” you. That rewrite is how DKIM and DMARC die on the hop.
Does this require a new mailbox?
No. DKIM is a signature on a message. Destinations stay Gmail or Outlook. MailerZ is not IMAP. Buying a suite seat does not repair a From rewrite.
Will it work with Gmail or Outlook?
Yes as destinations when the hop keeps Header From intact. Those providers still apply their own filters after DKIM. A pass is not Primary. Open the original on a third mailbox. Self-send can hide the hop.
What DNS records are involved?
The author’s DKIM TXT at the selector they published. Your inbound MX is a different object. Your outbound DKIM matters when you send as the domain on a paid plan. Do not merge those three.
What should I test before production?
Forward a message that already has DKIM. Confirm Header From is still the author. Read Authentication-Results on a third mailbox. Exclusive MX first. A green checker is homework, not a folder.
Key takeaways
- DKIM signs headers and body. From is usually on that list.
- Forwarding must not rewrite Header From.
- SRS may rewrite envelope MAIL FROM only.
- MailerZ never rewrites Header From, Subject, Date, Message-ID, body, or MIME.
- A From rewrite is a new send, not a forward.
- DKIM pass is not Primary. No inbox percentage.
- Leftover MX is not a DKIM bug.
- Outbound DKIM is a paid send-as ticket.
- Footers on the hop break body hashes.
- Prove with a third mailbox and Open original.
- Free has no send-as. Inbound proof still works.
- MailerZ is not IMAP, not a suite, and not SOC 2.
Conclusion and next action
DKIM email forwarding survives when the hop refuses to edit the signed identity. Envelope SRS is the allowed rewrite. Header From is not. If your current product changes From, you are not forwarding. You are sending as yourself with someone else’s content.
Next action: exclusive MX, named alias, a signed message from a third party, Open original. If From moved, change hop. If From held and DKIM passed, stop chasing a folder. If you need to send as the domain, upgrade and publish dashboard DKIM. Do not rewrite From to force a pass.
Keep one received original in the runbook. The next “forwarding broke DKIM” ticket should take five minutes. Compare From. That is the test. If From moved, you do not need a selector debate. If From held and the body hash failed, hunt hop footers. If both held and the folder is still spam, you are in filter territory and MailerZ will not sell you a percentage. Split those three before you publish a second DKIM key you do not own.
Ready to forward without rewriting From
Start free, map one alias, prove the received copy.
Free receives one domain. Sign in if it is already there.
Review quarterly, or sooner if dashboard auth copy changes. Author: MailerZ editorial, Secuno LLC.