Automatic email forwarding can break DMARC authentication because the final mail system sees a different sending server, and an intermediary may change content covered by the original signature. The useful fix depends on what changed: preserve valid signing, correct the mail route, or evaluate a supported trusted-forwarder mechanism. Start with the failed message’s route before changing domain-wide policy.
For an email administrator, a revealing symptom is that a customer’s message arrives when sent directly but fails when sent through an old address. The customer may have configured authentication correctly. The extra delivery step deserves investigation.
Why the forwarding step matters
Sender Policy Framework (SPF) checks whether the connecting server is authorized to send for the domain used in the SMTP transaction, usually the envelope sender. That envelope address is separate from the From address displayed to the reader. The SPF specification defines this server-and-domain authorization check.
DomainKeys Identified Mail (DKIM) uses a domain’s cryptographic signature to validate signed portions of a message. Domain-based Message Authentication, Reporting, and Conformance (DMARC) connects authentication to the visible From domain: at least one valid SPF or DKIM identity must align with it. Both do not have to pass. These are the current DMARC rules in RFC 9989, published in May 2026.
A forwarder can preserve the visible From address while changing the server that delivers the message. If it retains the original envelope sender, that new server may not be authorized by the original domain’s SPF policy. If it rewrites the envelope sender to its own unrelated domain, SPF can pass for that domain while losing the alignment DMARC needs. The IETF’s indirect-email guidance explains both cases.
Follow one customer message through two routes
Consider this hypothetical migration: a company keeps its old support address working by automatically forwarding mail into a new mailbox. A customer sends a message to that old address with a DKIM signature covering its entire body.
Customer → legacy mail service → current mailbox.
Forwarded without changing the signed content: assume the legacy service retains the customer’s envelope sender and that domain’s SPF policy returns a failure for the forwarder’s unlisted server. However, the customer’s DKIM signature still validates and aligns with the visible From domain. DMARC can pass through DKIM. An SPF failure alone is therefore insufficient to diagnose this as a DMARC failure.
Forwarded after adding a footer: suppose the legacy service inserts a disclaimer into the signed body. That modification invalidates this example’s DKIM signature, as the DKIM signature rules explain. With neither an aligned SPF result nor a surviving aligned DKIM signature, DMARC fails. The relevant difference is the processing at the legacy service; asking the customer to resend the same message will repeat it.
Those outcomes assume the stated signing and forwarding behavior. Real systems may apply other checks or reject a message before DMARC evaluation. Preserve the rejection response and message trace so the administrator can identify the actual decision.
Where ARC can help
Authenticated Received Chain (ARC) lets participating intermediaries carry signed authentication assessments forward. A receiving system can use that history when making its delivery decision, even when later processing disrupted the original authentication. RFC 8617, published as an Experimental protocol in July 2019, defines the mechanism.
The receiver still needs a reason to trust the intermediary. A technically valid ARC chain does not establish that every service in it is trustworthy. In Microsoft 365, for example, administrators can configure trusted ARC sealers for legitimate services that modify messages. Microsoft advises trusting only required, legitimate services; ARC handling does not bypass all other filtering.
That is a Microsoft configuration example, not a statement that every forwarding service or Network Box USA deployment supports the same ARC behavior. Confirm support and the exact sealing domain with the involved operators.
Choose the correction at the point of failure
For the hypothetical migration, first compare direct and forwarded test messages with harmless content. If the legacy footer causes the failure, evaluate removing that modification or retiring the forwarding step in favor of a supported delivery arrangement. If a required intermediary must modify messages, evaluate its supported ARC path with the receiving administrator. If aligned DKIM is missing before forwarding, the sender’s signing configuration needs attention.
Network Box USA’s Managed Cloud Email Security provides sender and message filtering, spoofing controls, policy enforcement, reporting, and operational support. Its service-design process includes validating mail flow and resolving exceptions. Bring the affected route and authentication evidence to that discussion so the agreed filtering policy can accommodate legitimate delivery while retaining content checks.
The sending organization controls its domain authorization and signing; the forwarding and mailbox operators control their respective processing. Agree who changes each part. For broader handling of reviewed messages and temporary exceptions, see our guide to reducing security false positives.
Before accepting a correction, send a new harmless message through the intended route and confirm the authentication results and delivery action. If forwarded business mail keeps failing, contact our team with the route, rejection details, and responsible mail operators to discuss the managed email-security scope.