SPF explained for email forwarding: why forwarders complicate it

Quick answer for spf email forwarding

IETF RFC 7208 — Sender Policy Framework (SPF) defines SPF as a check on the SMTP session identity, typically MAIL FROM (and HELO in some paths). The destination looks up the domain in that envelope and asks whether the connecting IP is listed. After a forward, the connecting IP is the forwarder. The original sender’s SPF will not list that IP. Fail. Softfail. Neutral. The message looks “broken” even though the human From is honest.

Sender Rewriting Scheme changes MAIL FROM to a domain the forwarder controls, so the second hop can pass SPF. MailerZ does that and nothing else to identity: Header From, Subject, Date, Message-ID, body, and MIME stay as the sender wrote them. DMARC alignment for the original sender can still fail at the destination if DKIM broke and SPF no longer aligns to Header From. That is a later article. This page stays on why SPF and forwarding fight.

Two jobs get mixed. Inbound: you do not publish SPF for every customer who emails you. The forwarder handles the hop. Outbound: if you send as hello@yourdomain.com through MailerZ SMTP, your domain’s SPF must include MailerZ as the dashboard states. One TXT. Under ten lookups. No leftover Google includes. Free has no send-as. Product path: email forwarding.

The real decision behind SPF and forwards

Operators search this after Gmail shows “via” or after a destination quarantines a forwarded invoice. They add the destination’s include to the sender’s SPF. That cannot work. You do not control the sender’s zone. They add every ESP they ever used to their own SPF “just in case.” Lookups blow the cap of ten. SPF permerrors. Send-as dies. The forward was never the thing they edited.

Decision one: are you debugging inbound (someone emailed your domain) or outbound (you sent as the domain)? Inbound wants SRS and a clean MX set. Outbound wants your SPF, DKIM, and DMARC. Decision two: will you rewrite Header From to “fix” SPF? Do not. That is the deliverability anti-pattern in this cluster. Decision three: can you staff one SPF record? Two SPF TXT records on the same name are undefined in practice and fail in the field.

When forwarding-safe SPF is enough

• You only receive at the domain and reply from Gmail as Gmail.
• MailerZ MX is exclusive. Leftover Google MX is gone.
• You can live with destination filters scoring the original sender.

When you also need outbound SPF

• Paid send-as must show the domain in Header From.
• WordPress or a form sends through MailerZ SMTP.
• You still have Google or Microsoft includes from a dead suite.

Agencies should split the ticket. “SPF failed” without Authentication-Results is not a ticket. Capture the received header. If spf=fail is on the original MAIL FROM and the hop IP is the forwarder, the forwarder is naive. If MailerZ is in the path and Header From was rewritten, you are on the wrong product. MailerZ does not rewrite Header From.

Do not buy a Workspace seat to “fix SPF” on a forward. Google Workspace — product overview is a suite. It does not make a naive forwarder’s second hop pass. It replaces the forwarder if you want Google to own MX.

Security: SPF is not encryption and not a private alias. It authorizes sending IPs. A pass does not mean the body is safe. A fail does not mean you should rewrite From to sneak past Gmail.

Technical mail flow: two hops, two SPF checks

Hop one: sender to MailerZ MX. MailerZ may evaluate the incoming session. Hop two: MailerZ to Gmail or Outlook. Gmail evaluates MAIL FROM against the connecting IP—the forwarder. SRS makes MAIL FROM a MailerZ-controlled identity so that check can pass. Header From remains alice@vendor.test. Humans see Alice. SPF on hop two does not claim Alice’s servers sent hop two.

DMARC (IETF RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC)) compares Header From to authenticated identifiers. After SRS, SPF no longer aligns to Header From. DKIM (IETF RFC 6376 — DomainKeys Identified Mail (DKIM)) can still align if the original signature survived. MailerZ does not rewrite the body or From, which is how DKIM is supposed to survive. A forwarder that changes From or MIME breaks DKIM on purpose. That is why “fix SPF by changing From” is worse than the SPF fail you started with.

SMTP itself is IETF RFC 5321 — Simple Mail Transfer Protocol. Leftover MX splits hop one. Some senders never reach MailerZ. Those messages have no SRS hop and no MailerZ history. Operators call that an SPF problem. It is mixed MX. Delete leftover hosts first. Troubleshooting and tools are for that proof.

The ten-lookup limit is in RFC 7208. Each include, a, mx, and nested include counts. Google plus Microsoft plus an ESP plus MailerZ plus a vanity include will permerror. Permerror is not a soft fail. Receivers may treat it as fail. Flatten or delete leftovers. Do not invent a second SPF record to “add more.”

Step-by-step decision path

1. Name the hop. Inbound forward or outbound send-as? Capture Authentication-Results from a real received copy.
2. Unmix MX. One MX set. No leftover Google or Microsoft. Two public resolvers.
3. Prove inbound from another mailbox. Confirm Header From is still the sender. Confirm a hop exists in history.
4. Do not edit the sender’s SPF. You cannot. If hop-two SPF fails and Header From was rewritten, change forwarder. MailerZ uses SRS only.
5. If you send as the domain: leave Free. Copy dashboard SPF. One TXT. Remove dead includes. Count lookups.
6. Publish DKIM and DMARC as instructed when send-as is in scope. SPF alone is a partial outbound story.
7. Re-prove with a third-party received copy. Composer UI is not SPF.

Worked examples

A studio forwarded to Gmail with a host that kept the original envelope. Gmail failed SPF on hop two. They switched to MailerZ. Header From stayed the vendor. Hop-two SPF passed on the SRS identity. Destination still put one vendor in spam. That remaining spam is sender reputation, not a missing include on the studio’s zone.

A founder added include:_spf.google.com and MailerZ and an old ESP. Twelve lookups. Send-as permerrored. They deleted Google and the ESP. Lookups dropped. Paid SMTP started passing. The inbound forward had been fine the whole time.

An agency “fixed” forwarded mail by rewriting Header From to the client domain. SPF passed. DMARC on the real sender died. Customers learned to distrust the brand. They reverted to Header From intact plus SRS. Support tickets about “fake From” dropped. Spam on a few senders remained. Honest.

A shop published two SPF TXT records—one old, one new. Receivers saw permerror. One record, one string, leftover tokens removed. Proof was a received Authentication-Results line, not the registrar’s green check.

A team blamed SPF because Stripe missed. Public MX still listed aspmx. Stripe hit Workspace. Empty MailerZ history. They deleted leftover MX. SPF was never the bug. Features overview: features.

Failure modes and proof

Proof is a received copy plus public MX plus, for outbound, a second received copy after SPF publish. Registrar UI is not the internet. Composer is not Authentication-Results.

Softfail (~all) is not a free pass. Many receivers still weigh it. -all is stricter. Publish what the dashboard and your DMARC plan agree on. Do not flip -all on a Friday with leftover includes still in the string.

MailerZ workflow and product boundary

Secuno LLC operates MailerZ. Site: mailerz.net. App: mail.mailerz.net. Envelope SRS only. Header From is never rewritten. That is the SPF-forwarding stance.

What MailerZ does

• Accept MX for verified domains.
• Rewrite envelope MAIL FROM with SRS on the forward.
• Leave Header From and MIME intact.
• Hold unknowns on Free. Optional paid FORWARD.
• Paid SMTP from approved identities. Dashboard SPF/DKIM instructions.
• 550 for unauthorized From. Not an open relay.

What MailerZ does not do

• Let you authorize other people’s sending domains.
• Guarantee Gmail Primary.
• Flatten SPF automatically if you stacked includes.
• Send-as on Free. IMAP. Calendar.
• SOC 2, ISO 27001, HIPAA, review counts, uptime SLA. Controls: Security and Trust Center.

Plans: pricing. Free $0, 1 domain, 3 aliases, 1 seat, 14-day store, send-as disabled, SMTP and API disabled. Solo $40/year, 3 domains, 15 aliases, 90-day, 1,000 outgoing, 5/hour. Starter $8 or $80, 5/50/5, 2,000, 10/hour. Business $19 or $190, 25/200/25, 4,000, 15/hour. Agency $39 or $390, 100/500/50, 8,000, 25/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

Best practice for spf email forwarding: exclusive MX, SRS, Header From intact, one outbound SPF if you send, ten-lookup diet, received-copy proof. Do not invent review counts. Inbox placement is not a MailerZ promise.

If you need a legal archive, SPF will not create one. Hop store is 14 days on Free and 90 on paid. Put holds in the mailbox you already pay for.

Transactional volume belongs on an ESP if you outgrow hourly caps. SPF includes for an ESP and MailerZ on the same domain need a lookup budget. Prefer separate sending domains if both must stay.

More field notes

+all is not a workaround for forwarding. It authorizes the world. Receivers distrust it. Do not publish it to “make forwards work.”

Redirect versus include: redirect= replaces the record. include: adds a mechanism. Copy the dashboard. Do not mix a leftover redirect to Google with a MailerZ include. The leftover wins and MailerZ send-as fails.

IPv6: if you list only v4 mechanisms and MailerZ or an ESP presents v6, SPF can fail. Use the include the dashboard publishes rather than hand-copied ip4 lines from a blog post dated 2019.

Proof packet you can hand a customer: public MX (one set), received inbound copy with Header From original and Authentication-Results, outbound copy if they send, SPF TXT as published, lookup count, plan name. That packet ends “just add include:gmail” advice.

After a domain transfer, SPF often stays on the old nameserver. MX moves. Send-as dies. Edit the zone NS actually points at. Same leftover-panel bug as MX, different record type.

How to read Authentication-Results without guessing

Open the received copy at the destination, not the copy in Sent. Search for Authentication-Results. You want three facts in one glance: which domain SPF evaluated, what the result was, and which IP connected. If the evaluated domain is still the original sender and the connecting IP is the forwarder, you are looking at a naive hop. If the evaluated domain is a MailerZ-controlled SRS identity and the result is pass, hop-two SPF did its job. Do not stop there. Read Header From on the same message. If Header From is no longer the vendor, someone rewrote identity. That is not an SPF win.

Gmail sometimes shows a “via” label. That label is a UI hint about the hop, not a verdict that you must rewrite From. Outlook has its own banners. Treat banners as prompts to open headers. A banner plus empty MailerZ history usually means leftover MX, not a missing include. A banner plus a stored hop plus original Header From is the expected forwarding picture. Destination filters can still quarantine. That remaining decision is not an SPF record you can publish on your zone.

Agencies waste hours because the customer pastes composer screenshots. Composer never shows MAIL FROM. Ask for “show original” or “view source” and a public MX lookup from two resolvers. If those two artifacts disagree, DNS is the ticket. If they agree and hop-two SPF still names the original sender, the forwarder is the ticket. If they agree, SRS passed, and the message is still in spam, the ticket is sender reputation or a user filter. Three tickets. One word “SPF” does not cover them.

Nested includes and the ten-lookup budget

RFC 7208 counts DNS mechanisms, not characters. A short-looking record can still permerror. include:_spf.google.com is not one lookup. It expands. Microsoft’s include expands. An ESP include expands. Add MailerZ and a vanity “security” include from a vendor who parked three more includes underneath, and you are over ten before anyone notices. The registrar UI still shows a green TXT. Receivers return permerror. Paid send-as looks “broken” even though the string is syntactically pretty.

The fix is deletion, not a second record. Remove the suite include if Google or Microsoft no longer sends as the domain. Remove the dead ESP. Keep the include the MailerZ dashboard publishes for outbound. Recheck the count after each delete. If both an ESP and MailerZ must send as the same domain, prefer a dedicated sending subdomain for the ESP so the apex SPF stays short. Shared apex with two heavy includes is how small teams inherit permerror from a “temporary” marketing tool.

Do not flatten SPF by copying today’s IP list into ip4 mechanisms unless you own the change process. Provider IPs move. A frozen ip4 list fails next quarter and nobody remembers why. Prefer the official include, then keep the lookup diet by removing leftovers. If a blog post tells you to paste raw IPs from 2019, ignore it. IPv6 paths make those lists worse, not better.

Inbound tickets that look like SPF and are not

Invoice missing. Customer swears DNS is correct. Public MX still lists aspmx plus MailerZ. Half the senders never arrive. Half do. The arrived half shows clean hop-two SPF because those senders hit MailerZ. The missing half has no history. Support is asked to “fix SPF.” The fix is exclusive MX. SPF never saw the missing messages.

Catch-all HOLD on Free also looks like an SPF outage. The unknown local-part never reaches Gmail. History shows a hold. The customer publishes a longer SPF string. Nothing changes. Name the policy first. Free holds unknowns. Paid FORWARD is optional and is a spam trade-off, not an SPF feature.

Unauthorized send-as returns 550 or 550 5.7.1. That is MailerZ refusing an open-relay pattern, not a destination SPF fail. Free has no send-as. A hosted or unauthorized identity fails the same way. Read the SMTP history line before you edit TXT. Editing SPF cannot authorize a From that the product has not approved.

What a durable SPF-and-forwarding policy looks like

Write the policy in one paragraph the team can reuse. Inbound: exclusive MailerZ MX, SRS on the envelope, Header From never rewritten, leftover hosts deleted, inbound proved from another mailbox. Outbound: paid plan if you send, one SPF TXT copied from the dashboard, leftover includes removed, DKIM and DMARC published as instructed, outbound proved with a received copy at a third-party mailbox. Change control: one person owns the TXT string. Pull requests or a ticket required to add an include. Lookup count recorded in the ticket. That paragraph prevents Friday “just add Google” edits.

Refresh cadence should follow the cluster, not a mood. Recheck when you add an ESP, leave a suite, transfer the domain, or the dashboard publishes a new include host. Recheck after a registrar panel change. Recheck when a new teammate gets DNS access. Quarterly is a floor. An include added in a panic is the usual regression.

Related reading on this site stays in the same job family: email forwarding for the product path, troubleshooting when MX and history disagree, and tools when you need a public lookup before you argue with a customer. Do not send people to a fake pillar. If the hop is clean and spam remains, say so. Honesty is cheaper than a second SPF record.

One last operational habit: store the current SPF string in the same ticket as the MX screenshot. When send-as fails six months later, you can diff the live TXT against the last known good string in minutes. Most “SPF mysteries” are an extra include someone added for a trial tool and forgot. The dashboard include is the outbound source of truth. Everything else on that record should have a named owner and a reason to stay.

FAQ

Key takeaways

• SPF authorizes the envelope hop, not the visible From.
• Naive forwards fail SPF at Gmail or Outlook.
• SRS rewrites MAIL FROM. MailerZ does not rewrite Header From.
• You cannot fix inbound by editing a customer’s SPF.
• Outbound send-as needs one SPF TXT and a lookup budget.
• Two SPF records or leftover includes cause permerror.
• Leftover MX masquerades as an SPF outage.
• SPF pass is not an inbox SLA.
• Free has no send-as. 14- or 90-day hop store is not an archive.
• MailerZ is not IMAP, not a suite, and not SOC 2.

Conclusion and next action

If you came here for SPF explained for email forwarding, the fight is the second hop. Keep the visible sender. Rewrite only the envelope. Publish your own SPF only for mail you send. Unmix MX before you touch TXT records.

MailerZ is built for that split: SRS inbound, Header From intact, paid SMTP with dashboard SPF when you need to send. Next action: capture Authentication-Results on one inbound message, confirm one MX set, then edit outbound SPF only if you are on a paid plan and actually send.

Review quarterly, or sooner if SPF includes or dashboard hosts change. Author: MailerZ editorial, Secuno LLC.