A message can pass authentication when it first reaches someone and show a failure, a different result, or no clear result after it is forwarded. That does not automatically mean the original sender was unauthenticated or that the forwarded copy is fraudulent. Forwarding can change which server delivers the message and can sometimes alter the message itself. To understand a confusing result, compare the original and forwarded copies if you can, identify which system added each authentication result, and ask the relevant mail provider or recipient administrator to interpret the specific headers.
The useful bits
- Forwarding changes the delivery path, so SPF results may differ from the original delivery.
- Compare the message and authentication headers from both copies; check which receiving system recorded each result.
- Ask the forwarding provider or recipient administrator to explain the specific case rather than judging from one result alone.
The message has taken a different route
SPF checks whether the server delivering a message is permitted by the sending domain’s SPF policy. On the first delivery, the receiving system checks the server that connected to it. If a person or service then forwards the message, a different server may deliver the forwarded copy. That server may not be listed as an approved sender for the original domain, so SPF can fail or produce another result even when the original delivery passed.
Forwarding services vary. Some pass messages along with little change; others may rewrite addresses or make other adjustments. The result depends on the route, the message, and how each provider handles it. A changed SPF result is useful context, but by itself it does not establish whether the message is legitimate.
Other checks can tell a different part of the story
DKIM checks a cryptographic signature associated with a domain. A forwarded message may retain a valid signature if the signed content remains intact. If a forwarding system changes content covered by that signature, the check may no longer pass. Whether a change affects the signature depends on what was signed and how the message was modified.
DMARC uses results such as SPF and DKIM, together with domain alignment, to assess whether authentication aligns with the visible From domain. A message might therefore show a passing DKIM check but a different DMARC outcome, or show mixed results across checks. Treat each result as a separate clue, not as a simple overall verdict.
Compare copies without assuming every header is trustworthy
If available, keep the original message and the forwarded copy and view their full headers. Look for the Received lines, which record parts of the delivery route, and for Authentication-Results lines that report checks made by a receiving system. Compare the reported SPF, DKIM, and DMARC outcomes, the domains involved, and the order of the delivery hops. Headers can be lengthy, and the same message may contain results added at different stages.
Pay attention to which system says it performed a check. A result added by the recipient’s mail system is generally more relevant to that system’s handling than a line copied from an earlier message. Do not treat a header line as verified merely because it is present: forwarded content can carry earlier headers along. If you are unsure which lines belong to which delivery, ask the recipient administrator or provider to identify them.
- Keep both copies, including their full headers, if you have access to them.
- Compare the apparent route and authentication results, noting the receiving system that recorded each result.
- Avoid changing or removing headers before asking for help.
A practical comparison
Suppose a sender sends a message to one mailbox, and its owner forwards it to a colleague. The first mailbox’s headers report SPF pass. The colleague’s copy reports SPF fail, while DKIM passes. This can be consistent with the forwarding server not being authorised by the original sender’s SPF policy, while the DKIM signature remained valid. It is not enough information to conclude that the message is safe or unsafe; the recipient’s system and the message context still matter.
Original copy: From: [sender@example.com] → [first-recipient@example.com]; SPF: pass, as reported by [first-provider.example] Forwarded copy: [first-recipient@example.com] → [colleague@example.com]; SPF: fail, DKIM: pass, as reported by [recipient-provider.example] Question to ask: Which delivery hop produced the SPF result, and does the forwarded route explain the difference?
Ask for an interpretation of this message
Contact the provider that handled the forwarding, or the administrator responsible for the recipient’s mail system. Share the message’s approximate arrival time, the sender and recipient addresses, and the full headers through an appropriate support channel. Ask which system recorded each result, whether forwarding changed the route or message, and what the receiving system made of the combined authentication results.
If you manage the recipient’s mail environment, have an authorised administrator review the specific delivery using the available headers and system records. A sender may also ask their own mail provider to explain the original delivery, but that provider may not have visibility into what happened at a separate forwarding or recipient system.
Confirm what was resolved
You have a useful explanation when the provider or administrator can connect the reported result to a particular delivery stage and explain any difference between the copies. If the cause remains unclear, ask what additional information they need and whether they can examine the relevant message records. Keep the original and forwarded copies until the question is settled.
A diagnosis does not guarantee that future forwarded messages will receive the same results, or that a message will reach an inbox. Forwarding routes and message handling can differ. The practical goal is narrower: understand which system reported which check, and whether that result fits the path the message took.
About this guide
Prepared with AI assistance for the BITTU Mail editorial library. Check important details against your original messages and current account settings. Product access depends on your role, plan and provisioning state. Provider interfaces and requirements can change.
View current plans · Security information · Suggest a correction