5.7.367 means a message that passed through a forwarding or relaying system failed SPF or DKIM when Microsoft evaluated it, and the intermediary did not preserve enough evidence for Microsoft to trust the original authentication. Forwarding is the cause, not the original sender.
Most common causes
- Forwarding changed the delivery IP so SPF no longer represents the original sender
- A gateway modified signed content and invalidated DKIM
- The intermediary path does not preserve enough authentication context
- A non-Microsoft gateway changed the message or routing identity
What to verify next
- Analyze the forwarded message with ARC Forwarding Analyzer
- Compare authentication before and after the intermediary hop
- Inspect whether DKIM broke because message content was modified
- Review the forwarding or gateway design instead of changing the original sender blindly
Forwarding breaks authentication by design
When a message is forwarded, the forwarder connects to Microsoft from its own IP with its own envelope sender. SPF for the original domain no longer applies. If the forwarder also modified the message — a footer, a subject tag, a rewritten link — the original DKIM signature no longer verifies either. Both paths are gone.
ARC exists to carry the original authentication results across such hops so a receiver can consider them. When the intermediary does not implement ARC, or Microsoft does not trust that intermediary, the message is judged on its current state and fails.
Find the intermediary
Use the ARC Forwarding Analyzer on the rejected message’s headers. It reconstructs ARC sets if any exist, shows where the chain breaks, and identifies which hop modified the content. Compare authentication results before and after that hop.
Common intermediaries are mailbox forwarding rules, mailing lists, ticketing systems that re-send inbound mail, and security gateways that rewrite links.
- The forwarder’s IP and envelope sender replace the original.
- Content modification invalidates DKIM.
- ARC preserves the original result only if the forwarder implements it and the receiver trusts it.
Fix the path, not the sender
Configure the forwarder to use SRS so the envelope sender belongs to the forwarding domain and passes SPF there, and ensure it does not modify signed content — or that it adds ARC seals. Mailing lists should sign with their own DKIM after modification.
If the forwarder is your own Microsoft 365 tenant, enable SRS and review transport rules that alter messages. The original sender usually has nothing to change.
Best diagnostic path
Mail Failure Doctor
Classify the complete rejection and preserve provider-specific diagnostic context.
Open analysis → Live analysisARC Forwarding Analyzer
Reconstruct authentication continuity across forwarding and intermediary gateways.
Open analysis → Live analysisEmail Infrastructure Digital Twin
Map the domain’s public mail infrastructure and provider relationships before remediation.
Open analysis →Known limits
- Whether Microsoft honours an ARC chain depends on its trust in the sealing intermediary, which is not published.
- Some intermediaries cannot be modified; in that case forwarding to Microsoft mailboxes may need to be replaced by a different mechanism.
Common questions
Should the original sender fix their SPF?
No. Their authentication was correct at origin. The forwarding hop is what broke it.
Does ARC guarantee acceptance?
No. It provides evidence a receiver may use if it trusts the intermediary.
What is SRS?
Sender Rewriting Scheme rewrites the envelope sender to the forwarder’s domain so SPF passes at the next hop. Microsoft 365 supports it for forwarded mail.
Why the exact message matters
The same status family can be triggered by different conditions, and providers frequently add diagnostic text that narrows the issue. Use the complete rejection text rather than treating the numeric code as a complete diagnosis.
Provider reference
For the provider-defined meaning and current requirements, review Microsoft Exchange Online NDR reference.