ARC explained: how forwarders preserve authentication evidence

Quick answer for arc email forwarding

IETF RFC 8617 defines ARC. A participating hop can add an ARC-Authentication-Results header, sign it, and later hops can add their own seals. A destination that trusts that chain may treat a broken conventional authentication path more kindly than a naive forward. Destinations that do not trust the sealer, or that never look at ARC, behave as they always did.

Forwarding still changes the SMTP session. IETF RFC 7208 — Sender Policy Framework (SPF) SPF on hop two evaluates the forwarder’s connecting IP against MAIL FROM. That is why MailerZ uses Sender Rewriting Scheme on the envelope and leaves Header From, Subject, Date, Message-ID, body, and MIME alone. DKIM (IETF RFC 6376 — DomainKeys Identified Mail (DKIM)) can survive when the signed parts are not rewritten. DMARC (IETF RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC)) still asks whether Header From aligns. ARC sits beside that stack as evidence, not as a substitute From.

Operators mix three jobs. Job one: inbound routing. Exclusive MX, named aliases, leftover hosts gone. Job two: hop honesty. Envelope may change. Visible sender must not. Job three: outbound send-as. That needs paid SMTP, one SPF TXT, DKIM, and DMARC on your domain. ARC on a forward does not publish those outbound records for you. Product path: email forwarding.

The real decision behind ARC and forwards

People search this after Gmail quarantines a forwarded invoice, or after a mailing-list style hop strips DKIM. They ask the forwarder to “turn on ARC” the way they turn on a checkbox. That framing hides the actual decision: will you keep the original Header From and accept that some destinations will still filter, or will you rewrite From to chase a cheap SPF pass and destroy the evidence ARC was meant to preserve?

Decision one: are you debugging inbound (someone emailed your domain) or outbound (you sent as the domain)? Inbound wants a clean MX set, SRS, and a forwarder that does not mutilate MIME. Outbound wants your own DKIM. Decision two: does the destination even consume ARC? Many filters still score content, volume, and the original Header From domain. Decision three: can you staff exclusive MX? Two products in MX means some messages never reach the hop that would have sealed anything.

When forwarding-safe evidence is enough

• You only receive at the domain and reply from Gmail as Gmail.
• MailerZ MX is exclusive. Leftover Google or Microsoft MX is gone.
• You can live with destination filters scoring the original sender.
• You will not rewrite Header From to “help” ARC.

When ARC talk is the wrong ticket

• History is empty and public MX still lists aspmx. That is leftover MX.
• Unknowns never arrive on Free. That is HOLD, not missing ARC.
• Send-as returns 550. That is unauthorized From or the Free plan, not ARC.
• You need Calendar and a hosted mailbox. That is a suite, not a seal.

Agencies should split the ticket the same way they split SPF. “Gmail said unauthenticated” without a received copy is not a ticket. Capture Authentication-Results. If Header From was rewritten, you are on the wrong product. MailerZ does not rewrite Header From. If hop-two SPF fails on the original envelope, the forwarder is naive. If MX is mixed, fix DNS first. ARC cannot seal a hop that never happened.

Do not buy a Workspace seat to “get ARC.” Google Workspace — product overview is a suite. It can own MX and skip a second hop entirely. That is a different architecture, not a better seal on a forward you still want to run.

Security: ARC is not encryption. A valid chain does not mean the body is safe. A missing chain does not mean you should forge From. Treat seals like Authentication-Results: useful evidence, not a privacy product and not a SOC 2 badge.

Technical mail flow: observe, seal, forward

Hop one: sender to MailerZ MX. The session can be evaluated with the usual tools—envelope, perhaps DKIM on the incoming message. Hop two: MailerZ to Gmail or Outlook. SRS changes MAIL FROM so hop-two SPF can pass against a domain the forwarder controls. Header From remains alice@vendor.test. If the hop participates in ARC, it may record what it saw and sign that record. The destination may chain-validate those signatures.

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

DKIM breaks when a hop changes signed headers or the body. Rewriting Header From is the common way to do that on purpose. A “fix” that changes From to the forwarder’s domain can make hop-two SPF look pretty and make DMARC on the real sender die. ARC cannot resurrect a signature you destroyed. That is why this cluster treats visible From rewrites as a deliverability anti-pattern.

Lists and older ticket systems add their own ARC instances. Instance numbers increment. A destination that walks the chain is looking for a trusted sealer and an unbroken set of signatures. If a hop in the middle rewrote MIME and then sealed “pass,” the seal is only as honest as that hop. Trust is operational, not magical.

DNS does not publish “ARC=on.” You publish MX, and if you send, SPF, DKIM, and DMARC. Confusing those jobs is how teams add a second SPF record “for ARC” and permerror outbound send-as. One SPF TXT. Under ten lookups. Copy the dashboard. ARC headers are on the message, not in the zone.

Step-by-step decision path

1. Name the hop. Inbound forward or outbound send-as? Capture Authentication-Results from a real received copy, not Sent.
2. Unmix MX. One MX set. No leftover Google or Microsoft. Two public resolvers. Wait TTL if you just deleted.
3. Prove inbound from another mailbox. Confirm Header From is still the sender. Confirm a hop exists in history.
4. Read ARC only after those facts. If there is no hop, there is no seal. If Header From changed, change forwarder.
5. Do not edit the sender’s DNS to “help ARC.” You do not control vendor.test. You control your MX and your outbound records.
6. If you send as the domain: leave Free. Publish dashboard SPF, DKIM, and DMARC. ARC on inbound is a different ticket.
7. Re-prove with a third-party received copy after any DNS change. Self-send can lie.

Worked examples

A studio forwarded to Gmail through a host that rewrote Header From to the studio domain. Gmail showed a local From. Customers thought the studio had sent the vendor invoice. DKIM on the vendor died. They switched to MailerZ. Header From returned to the vendor. Hop-two SPF passed on SRS. One vendor still landed in spam. That remaining spam is sender reputation, not a missing ARC checkbox the studio could publish in DNS.

An agency opened a ticket titled “enable ARC.” Public MX listed MailerZ and aspmx. Half of senders never arrived. The arrived half had hop history. They deleted leftover MX. Arrival became consistent. ARC was never the defect. Features overview: features.

A founder added two SPF TXT records after reading that ARC needs SPF. Send-as permerrored. They deleted the extra record, kept the dashboard include, counted lookups, and paid SMTP started passing. Inbound forwards had been fine. The ARC article they skimmed was about headers, not a second TXT.

A shop blamed ARC because Stripe missed. History was empty. Self-send from Gmail looked fine. They probed from a mailbox outside Google. The probe also missed until leftover MX was gone. Proof was two resolvers plus an external send, not an ARC header screenshot from a message that never took the path.

A team forwarded a newsletter that already carried ARC from a list hop. The destination ignored the chain and filtered on content. Honest outcome. ARC is optional evidence. Content and sender reputation still win most days.

Failure modes and proof

Proof is a received copy plus public MX plus, for outbound, a second received copy after you publish DKIM. Registrar UI is not the internet. A marketing page that says “ARC enabled” is not Authentication-Results.

Broken ARC signatures happen when a later hop mutates a sealed header. Treat that like a broken DKIM: find the rewriter. Do not add a second MX “backup” while you debug. Dual MX creates a second random path and a second set of missing seals.

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 forwarding-safe stance this article is about. ARC is hop evidence in that model, not a reason to change the visible sender.

What MailerZ does

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

What MailerZ does not do

• Guarantee that Gmail or Outlook will honor an ARC chain.
• Guarantee Primary or any inbox placement rate.
• Let you authorize other people’s sending domains.
• 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 arc email forwarding: exclusive MX, SRS, Header From intact, outbound DKIM if you send, received-copy proof. Do not invent review counts. Inbox placement is not a MailerZ promise. A suite is cheaper only if you actually need the suite.

If you need a legal archive, ARC 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. That ESP should DKIM as its sending domain or as a dedicated subdomain. Do not stack every include onto apex SPF and hope ARC saves send-as. Lookups still cap at ten.

More field notes

Mailing lists are the historical reason ARC exists. A list adds a subject tag or a footer, DKIM on the author domain fails, and a list-aware receiver may still trust the list’s seal. Domain forwarding is a cousin, not a clone. You are not a list. You should not add footers. MailerZ does not rewrite the body. If a hop adds a disclaimer banner into the MIME tree, it is doing list-like damage on a forward path.

Trust lists for ARC are local to the destination. You cannot publish “trust MailerZ” in your zone the way you publish SPF. If a receiver does not trust the sealer, the chain is decoration. Plan operations as if ARC is absent, then treat a consumed chain as a bonus. That mindset prevents “we enabled ARC so leftover MX is fine” regressions.

Authentication-Results and ARC-Authentication-Results are easy to confuse in a screenshot. The first is what this hop thinks. The second is what a previous hop claimed, now sealed. Teach support to label which one they pasted. Unlabeled screenshots restart the ticket.

After a domain transfer, MX often moves while people still talk about ARC. Seals never appear for mail that still hits the old host. Edit the zone the NS records actually point at. Same leftover-panel bug as SPF, different vocabulary.

Proof packet you can hand a customer: public MX (one set), received inbound copy with Header From original, Authentication-Results, any ARC headers, outbound copy if they send, plan name. That packet ends “just enable ARC” advice.

Related reading 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. If the hop is clean and spam remains, say so.

Quarterly refresh is a floor. Recheck when you add a list, change forwarder, transfer the domain, or a destination changes how it shows forwarded mail. An include added in a panic is still the usual outbound regression. ARC will not un-permerror a second SPF record.

One operational habit: store the last good received source next to the MX screenshot. When a new teammate asks for ARC, you can show what a healthy hop already looks like. Most mysteries are mixed MX, Free HOLD, or a From rewrite on another product.

How to read a seal without inventing a feature

Open the destination copy. Search for ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal. You want to know which instance number you are looking at, which domain signed, and whether the destination’s Authentication-Results mentions arc=pass or ignores the chain. If the destination says nothing about ARC, the headers are still useful to you as an operator. They are not a customer-facing SLA.

Compare Header From on the same message. If it no longer matches the person who wrote the mail, stop talking about seals. You are looking at identity rewrite. MailerZ will not do that. If Header From is honest and hop-two SPF passed on an SRS identity, the forward did the SPF job. Remaining spam is a filter on the original sender or on content. Say that out loud. Customers buy fewer suite seats when the sentence is honest.

Teaching a junior: draw two boxes. Box A is DNS and aliases. Box B is headers on one received message. ARC lives in box B. Leftover MX lives in box A. Mixing the boxes is how “enable ARC” tickets last a week. Unmix the boxes in the first reply. Then, if box B still looks wrong, you have a real authentication conversation.

Do not paste customer message bodies into chat to “check ARC.” You only need headers and the envelope facts. Bodies belong in the mailbox. Hop store windows are 14 days on Free and 90 on paid. If you need longer, the archive is the destination inbox, not a forwarding log and not a seal.

When a vendor’s own DKIM already failed before it reached you, ARC can at most report that failure honestly. It cannot manufacture a pass for a sender who never signed. Operators sometimes want the forwarder to “fix” a vendor. You cannot. You can keep Header From honest and stop adding damage. That is the whole product promise on inbound.

If you also send as the domain, keep ARC out of that change window. Publish one SPF record, the DKIM selector the dashboard shows, and DMARC when you are ready. Prove outbound with a received copy at a mailbox you do not control. Then return to inbound seals if you still care. Mixing the windows is how a Friday DKIM publish gets blamed on “ARC being off.”

Put the last good received source next to the MX screenshot. When someone asks to “just enable ARC,” show them an honest hop first. Most tickets dissolve into leftover MX, Free HOLD, or a From rewrite on another product.

FAQ

Key takeaways

• ARC seals hop evidence. It does not rewrite Header From.
• RFC 8617 is optional for receivers. A seal is not an inbox SLA.
• MailerZ uses SRS on the envelope and leaves MIME intact.
• You do not publish ARC in DNS the way you publish SPF.
• Leftover MX masquerades as a missing seal.
• Rewriting visible From destroys the evidence ARC is meant to keep.
• Free has no send-as. HOLD is not an ARC outage.
• Outbound send-as still needs one SPF TXT, DKIM, and DMARC.
• 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 ARC explained and how forwarders preserve authentication evidence, the useful picture is small. Keep the visible sender. Rewrite only the envelope. Let a hop seal what it saw if it does. Unmix MX before you talk about headers. Publish your own DKIM only for mail you send.

MailerZ is built for that split: SRS inbound, Header From intact, paid SMTP with dashboard records when you need to send. Next action: capture a received copy from another mailbox, confirm one MX set, then read Authentication-Results before you mention ARC in a ticket.

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