A delegated assistant, a support platform and a mailing workflow may put different addresses in From, Sender and Reply-To. A fraudster can exploit the same differences. The useful question is whether the identities and reply destination match a verified business arrangement, supported by trusted authentication evidence where applicable.
Read the fields according to their roles
From identifies the author or authors of the message. Sender identifies the mailbox of the agent responsible for its actual transmission when that differs from the author. Reply-To indicates where the author suggests replies should be sent. When Reply-To is absent, replies should by default be directed to From unless the recipient has other knowledge. These are message-format semantics, not independent proof that the named people authorized the message. RFC 5322 section 3.6.2.
A display name can say “Finance” while the actual address belongs elsewhere. Expand and examine the address, but do not treat a familiar exact address as sufficient either: header text is sender-controlled unless supported by authentication and appropriate provenance. If From contains more than one mailbox, RFC 5322 requires a Sender field containing one mailbox. Preserve that distinction rather than collapsing multiple authors into one identity.
Keep authentication inputs separate
DMARC evaluates the author-domain relationship with relevant SPF or DKIM authenticated identifiers. Reply-To and Sender are not substitute alignment inputs. A matching Reply-To domain cannot rescue a failed author-domain alignment decision. Conversely, a different Reply-To can be legitimate and does not by itself establish DMARC failure. RFC 9989.
A domain-authentication pass does not authorize a bank-account change, credential request or new recipient for confidential material. Treat the business instruction separately, especially when a reply would disclose sensitive information or accept a consequential commitment.
Inspect a bounded example
Consider a hypothetical support message with From: support@brand.example, Sender: operator@service.example and Reply-To: case123@service.example. The brand’s approved support workflow might explain all three roles. A separate request to send financial records to an unrecognized reply address needs independent confirmation even if the author domain authenticates. These are invented comparisons, not a parsed message or an authenticated service relationship.
For a real message, compare the fields with the approved service configuration and prior verified workflow. Ask whether the organization intentionally routes support replies to that destination. Verify a surprising or high-impact request through an established independent channel, not the phone number or link supplied in the suspect message.
Record a contextual decision
Document the claimed author, transmitting agent, reply destination, trusted authentication result and business verification outcome. If the differences match an approved arrangement, record why they are expected. If the destination is unexplained, hold the consequential action while the owner verifies it. Avoid blanket rules that all three domains must match, which can break legitimate delegation without providing a complete fraud defence.
Close the investigation with the recipient's next safe action. That might be replying through a known support portal, confirming a request with an established contact, or escalating a suspected impersonation with the original message preserved.
Verify the workflow before the reply
- Expand the actual From, Sender and Reply-To addresses.
- Map author, transmitting agent and suggested reply destination separately.
- Corroborate trusted authentication without treating it as business approval.
- Check unexpected destinations through an established independent channel.
- Record whether the approved arrangement explains the difference, or hold the consequential action.