Email forwarding SPF DKIM DMARC is three checks on two hops. A naive forward sends from a server the original author never listed, so SPF on that hop fails or softfails. DKIM can still pass if the forwarder did not rewrite signed headers or the body. DMARC asks whether SPF or DKIM aligned with Header From. MailerZ rewrites envelope MAIL FROM with SRS and never rewrites Header From. That is the authentication design. It is not an inbox-placement promise.
Quick answer for email forwarding spf dkim dmarc
Yes, forwarding affects SPF on the hop Gmail received unless the envelope is rewritten (SRS). DKIM is affected only if someone rewrites signed fields or the body. DMARC follows alignment. MailerZ: envelope SRS only, Header From intact.
Email authentication is hop-specific. Deliverability is Gmail’s next job. Forwarding authentication is not an SLA.
Outbound send-as uses your SPF, DKIM, and DMARC as the dashboard states. That is a different hop.
Two SPF records fail. Ten-lookup limits are real. Leftover MX is a hard stop before you read results.
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. Starter is $8 monthly or $80 yearly. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99/month or $990/year. Confirm numbers on MailerZ pricing. Limits are not an inbox-placement promise.
Google’s own Send mail as steps live in Google Gmail Help — Send mail from a different address. Workspace as a product is described on Google Workspace — product overview. Transport still follows IETF RFC 5321 — Simple Mail Transfer Protocol.
email authentication: the real decision
Teams rewrite Header From to “pass SPF” and fail DMARC.
They paste a customer’s include: into their own SPF.
They treat a green checker on their domain as a test of a forwarded invoice.
Criteria: Header From intact, exclusive MX, Authentication-Results you can read, no invented inbox rate.
| Check | Forward inbound | Your send-as |
|---|---|---|
| SPF | Hop / SRS envelope | Your published SPF |
| DKIM | Original signature if intact | Your domain key |
| DMARC | Alignment vs Header From | Your policy |
| Folder | Destination decision | Destination decision |
Prove inbound from another mailbox before you print hello@ on a homepage.
Start free — one domainTechnical mail flow for email forwarding spf dkim dmarc
Hop one accept, hop two to Gmail with SRS envelope, original Header From, original DKIM if we did not touch the body.
Gmail writes Authentication-Results for the hop it saw.
A leftover registrar rewrite changes this diagram. MailerZ does not.
Reply as the domain is outbound auth, not this inbound story.
MailerZ is inbound MX plus authenticated SMTP from Secuno LLC. Envelope SRS only. Header From, Subject, Date, Message-ID, body, and MIME are never rewritten. Not Google Workspace, not IMAP, not webmail, not an open relay. Unauthorized send is SMTP 550 / 550 5.7.1. Leftover MX is a hard stop. Self-send from Gmail to the same Gmail account can hide routing errors. Not SOC 2, not ISO 27001, not HIPAA.
deliverability
Fix leftovers and Header-From rewrite before you tune SPF.
- Publish exclusive MailerZ MX. Delete leftovers.
- Create named aliases. Do not rewrite From anywhere else.
- Probe from another mailbox.
- Open Authentication-Results. Read spf, dkim, dmarc.
- Confirm Header From is the original author.
- For send-as, publish dashboard SPF/DKIM/DMARC. One SPF record.
- Count SPF lookups if you stacked includes.
- Do not treat a pass as Primary.
Failure modes and proof
Header-From rewrite.
Two SPF TXT records.
Lookup limit blown.
Green checker as the only test.
Self-send.
Leftover MX is the usual ghost. Check a public lookup before you blame Gmail.
Open leftover MX troubleshootingMailerZ workflow and product boundary
Envelope SRS only. Related: email forwarding, features, delivery recovery, email routing lab.
Not an inbox SLA. Not SOC 2.
Related pages: email forwarding, features, delivery recovery, and email routing lab.
forwarding authentication
A rewrite product is cheaper until DMARC fails. Confirm MailerZ pricing for send-as. Do not buy Workspace to fix a hop SPF story.
ARC theater is optional. Intact headers are not.
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. Starter is $8 monthly or $80 yearly. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99/month or $990/year. Confirm numbers on MailerZ pricing. Limits are not an inbox-placement promise.
Field notes you can reuse
Cite RFC 5321 for the envelope.
Softfail after a naive hop can be expected. Read the softfail article if you need that drill.
Hold unknowns. Harvest does not need auth theater.
Agencies: per-domain SPF for send-as.
CRM includes belong on outbound SPF, not as a fix for inbound invoices.
Quarterly leftover review.
A pass is homework, not a folder.
This page is the three checks. Architecture is the hop diagram.
Deeper field notes for email forwarding spf dkim dmarc
Three identifiers, two hops
Email forwarding SPF DKIM DMARC is not one switch. SPF authorizes envelope MAIL FROM for the hop Gmail received. DKIM signs header fields and a body hash. DMARC asks whether SPF or DKIM aligned with Header From. A naive forward keeps Header From as the original author and sends from a server that author never listed. SPF on that hop fails or softfails. DKIM can still pass if the forwarder did not rewrite signed headers or the body. MailerZ does not rewrite Header From, Subject, Date, Message-ID, body, or MIME. Envelope SRS may change MAIL FROM so SPF at Gmail can pass for the hop.
That hop pass is not alignment with the original brand unless SRS and DMARC are doing a specific dance you should not invent from a blog. Alignment for the visible sender usually rides DKIM if the original signature survived. Rewriting Header From to “fix SPF” kills that path. That is why Header-From rewrite is a different, worse product.
Inbound versus outbound
Inbound forward uses the author’s DKIM and the hop’s SPF story. Outbound send-as uses your domain’s SPF, DKIM, and DMARC as the dashboard states. Do not paste the author’s include: into your SPF because a customer invoice softfailed. You do not authorize their bank. You authorize MailerZ when you send.
Two SPF records on your domain fail. Leftover Google include: plus MailerZ plus a CRM plus a help desk blows the ten-lookup limit. Count lookups if you stacked includes. Confirm the live dashboard. Do not copy a random include from a thread.
What a destination shows
Authentication-Results on the received copy describe the hop Gmail saw. A green checker against your domain does not test a forwarded bank invoice. Open the message. Read spf, dkim, dmarc. A pass is not Primary. MailerZ does not publish an inbox-placement rate.
ARC exists so a hop can attach evidence. It is not a promise Gmail will honor it the way you wish. Do not buy ARC theater. Keep Header From intact. Use exclusive MX. Probe from a third mailbox.
When forwarding “breaks DMARC”
Usually someone rewrote From, or leftover MX split the path, or the original message had no DKIM and the hop SPF does not align. Fix the rewrite and the leftover first. Do not widen catch-all. Do not add ~all theater on a domain you do not send from.
Cite RFC 5321 for the envelope and Google’s authentication documentation for how Gmail displays results. Self-hosted threads will argue postfix milters. Fine if you want the pager. MailerZ’s boundary is envelope SRS only.
A complete worked story
A bank invoice and a “failed SPF” panic
Finance saw softfail on a forwarded invoice and added the bank to their SPF. That authorizes nothing useful and risks the lookup limit. The Header From was still the bank. DKIM passed. They deleted the include, kept MailerZ MX exclusive, and stopped treating hop SPF as their domain’s outbound policy. The invoice had been readable the whole time.
Operator brief
A longer operator brief for email forwarding spf dkim dmarc
Teams that bookmark Does Email Forwarding Affect SPF, DKIM or DMARC? usually arrive after a missed invoice, a form that never notified anyone, or a migration that looked clean in one resolver. The useful brief is still boring. Name the store. Name the printed local-parts. Name the nameservers that actually answer. Publish one MailerZ MX set. Delete leftover hosts. Probe from a mailbox that is not the destination. Only then talk about email forwarding spf dkim dmarc as a send-as, catch-all, or comparison problem.
MailerZ remains inbound MX plus authenticated SMTP around Gmail or Outlook. Envelope SRS only. Header From, Subject, Date, Message-ID, body, and MIME stay intact. It is not a hosted mailbox, not IMAP, not webmail, and not an open relay. Unauthorized send is 550 / 550 5.7.1. Free cannot finish send-as: SMTP and API stay off. Solo is $40 per year when the domain From must travel. Starter is $8 or $80. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99/month or $990/year. Confirm the live pricing page. Those numbers are ceilings, not an inbox-placement service-level agreement.
If leftover Google, Microsoft, Cloudflare routing, or registrar MX is still public, stop widening email forwarding spf dkim dmarc. The map you built never saw that copy. Priority numbers are an order, not load balancing. A higher preference host is idle while a leftover host still accepts mail. Save the old MX set before you delete anything. Check more than one public view because TTL lies.
Catch-all forward is not a safety feature for does email forwarding affect spf dkim or dmarc. Hold unknowns on everyday production. Review the store. Promote a leftover only when a real person used it. Paid forward belongs to a dated cutover. Fan-out of unknowns into two inboxes trains two spam buttons. Plus addressing on Gmail is not a custom-domain unknown policy. MailerZ will not strip plus tags on your domain the way Gmail does on @gmail.com.
Send-as is a second hop. Creating an inbound alias does not approve outbound. Catch-all does not mint a From. Copy the dashboard host, port, and TLS pair together. Set From to an identity you created. Do not paste a Gmail password into a CMS, a cron file, or a ticket. Do not mail SMTP secrets to support. Send a 550 line, a timestamp, and a Message-ID. Rotate if a secret already leaked.
Self-send from Gmail to the same Gmail account can short-circuit. That green result is why people swear email forwarding spf dkim dmarc works while customers vanish. Use a second provider. Put a unique subject on the probe so delivery history is searchable. If Header From was rewritten by some other forwarder, authentication stories get noisier. MailerZ does not rewrite Header From on inbound.
Agencies should keep email forwarding spf dkim dmarc per client zone. Separate SMTP credentials. Do not pour every client into one catch-all because the spreadsheet got long. Agency plan capacity exists so you can hold more domains and aliases. It does not replace a named list. Offboard means delete MX you own, revoke SMTP, and stop forwarding leftovers into the agency inbox.
Legal and security questions have published answers on the security, privacy, terms, DPA, and subprocessors pages. MailerZ is not SOC 2, not ISO 27001, and not HIPAA. The 14-day Free store, the 90-day Solo–Agency store, and the 180-day Unlimited store are recovery windows for hops this layer saw. They are not an archive and not legal hold. If counsel wants eDiscovery, buy eDiscovery.
Comparisons only help after the hop is honest. Cloudflare Email Routing is inbound routing. A privacy-mask product hides a destination on a provider domain. A suite hosts mailboxes, Calendar, and admin. Proton-class mailboxes encrypt a store. MailerZ is the delivery layer when you already have Gmail or Outlook and you need a domain route you can prove. Cite the other product’s documentation. Do not invent feature parity.
When Does Email Forwarding Affect SPF, DKIM or DMARC? is closed, the next physical action is a lookup and a probe, not another tab. Start free on one domain you can break. Sign in if the zone already lives here. Review quarterly, or sooner after a nameserver move, a plugin swap, or a staff departure. That is how email forwarding spf dkim dmarc stays a runbook instead of an incident.
A second worked pass for email forwarding spf dkim dmarc: write the last change on a sticky note before you open the dashboard. Nameserver move, leftover MX, new form plugin, contractor laptop, or a registrar forwarding toggle are the usual five. MailerZ history only shows hops that reached this layer. If the sticky note says leftover MX, you do not have a email forwarding spf dkim dmarc mystery. You have a split. Delete the leftover. Wait for TTL. Probe again.
A third worked pass: print the public list. If you cannot print it, you are not ready for production unknowns and you are not ready for a bigger alias ceiling. Unlimited aliases as marketing will not save a missing list. Three named aliases on Free are enough to stop printing a personal Gmail on a homepage. Grow the list when a real person used a leftover, not when a harvest guessed admin@.
More working detail
A worked Authentication-Results reading
Open original. Find Authentication-Results. Read the SPF domain — that is the envelope hop, often an SRS domain after MailerZ, not the bank’s domain. Read DKIM d= — that should still be the bank if we did not touch the body. Read DMARC — pass if DKIM aligned with Header From. Email forwarding SPF DKIM DMARC stops being mystical when you read those three tokens out loud. If SPF is fail and DKIM is pass and Header From is the bank, you are looking at a normal naive-or-SRS hop story, not a broken domain.
If DKIM is fail or missing and Header From was rewritten to your domain, you are in the rewrite product. Stop. Move MX to an operator that leaves Header From alone. MailerZ is built that way. A leftover registrar toy in front of MailerZ can still rewrite. Exclusive MX.
Outbound send-as is the opposite worksheet: SPF should pass for your domain, DKIM should be your selector, DMARC should align with hello@yourdomain. Mixing the inbound invoice worksheet with the outbound newsletter worksheet is how people blow the ten-lookup limit.
Cite RFC 7208 when someone wants to add every customer to SPF. Cite Google’s authentication help when someone treats a pass as Primary. MailerZ will not publish an inbox percentage to win the argument.
Forwarding and ARC in one paragraph
ARC attaches hop evidence. Destinations may use it. They may not. Do not buy a product because the landing page says ARC as if it were a folder guarantee. Intact headers plus exclusive MX plus a real probe are cheaper and more honest.
One more working distinction
What to tell a customer who forwards to you
If a partner forwards their mail into your Gmail through some other product, their hop is not MailerZ’s inbound map. Email forwarding SPF DKIM DMARC on that path is their operator’s rewrite policy. Do not paste their includes into your SPF. Do not promise their DMARC will look like yours. Ask whether they rewrite Header From. If they do, their customers will see via lines and your Gmail will score a noisier message. You cannot fix their hop by buying a bigger MailerZ plan.
Your job is exclusive MX on your domain and intact headers on hops you control. Stay in that lane.
A short operating rule
DMARC p=reject and a naive hop
If the original author publishes p=reject and the hop breaks DKIM and fails SPF, the destination may reject. Email forwarding SPF DKIM DMARC then looks like “forwarding is broken.” The author’s policy is working. Keep Header From and the body intact so DKIM can still align. MailerZ is built for that. A rewrite hop plus p=reject is a bounce machine. Do not fix it by weakening your own DMARC on a domain you do not send as.
Field close
A closer that belongs on the ticket
“Hop SPF used SRS. Header From intact. DKIM aligned. Folder is Gmail’s.” That closer ends most email forwarding SPF DKIM DMARC threads. If you cannot say those four clauses, you are not done reading Authentication-Results.
FAQ
- What is the safest way to handle email forwarding spf dkim dmarc?
- Expect hop SPF to need SRS. Keep Header From intact so DKIM can stay aligned. Read Authentication-Results on a third-mailbox probe. Do not rewrite From. Do not treat a pass as inbox placement.
- Does this require a new mailbox?
- No. MailerZ is not IMAP and not webmail. Gmail or Outlook remains the store unless you separately buy a hosted mailbox product.
- Will it work with Gmail or Outlook?
- Yes for inbound when the destination is a verified mailbox. Branded replies need paid send-as plus Gmail Send mail as or a manual Outlook SMTP identity. Free has no send-as.
- What DNS records are involved?
- A verification TXT, one MailerZ MX set on the authoritative nameservers, leftover host MX removed, and SPF, DKIM, and DMARC if you also send as the domain.
- What should I test before production?
- Send a uniquely titled message from an unrelated provider into each named alias. Confirm Header From and delivery history. Do not email yourself from the same Gmail account.
Key takeaways
- SPF is the hop.
- SRS rewrites envelope.
- Keep Header From.
- DKIM survives intact bodies.
- DMARC is alignment.
- One SPF record.
- Pass ≠ Primary.
- Leftover MX first.
Conclusion and next action
Forwarding affects SPF unless the envelope is honest. It affects DKIM and DMARC when someone rewrites the visible From. MailerZ is built not to do that. Read the results on a real probe.
Start free. Sign in if Authentication-Results look haunted and Google still answers MX.
Keep the header, fix the envelope
Start free, cut leftover MX, prove inbound with Authentication-Results open.
Do not add the world’s senders to your SPF.
Review quarterly, or sooner if Gmail, Workspace, or MailerZ scope changes. Author: MailerZ editorial, Secuno LLC.