A message that appears to have two senders can involve several different things: one From field containing multiple authors, two separate From fields, or a display name that looks like another address. Those are different parsing and security cases. A screenshot of a mail client's sender line cannot reliably distinguish them.
Preserve the original message header and begin with its structure. Do not silently select whichever address aligns with a passing signature. That can hide the ambiguity the receiver and the recipient need to understand.
Separate field count from address count
RFC 5322 permits a single From field with a mailbox list. When that list contains more than one mailbox, a Sender field with one mailbox is required. The message-format rules still specify one From field, so two separate From fields are not the same construct as one valid multi-author field.
Sender identifies the transmitting agent in the message-format model. It does not replace the From domain as DMARC's Author Domain. Reply-To, Return-Path and a display name also serve different purposes.
Use the identity-chain walkthrough to keep these roles separate before investigating authentication.
Apply the DMARC domain rule explicitly
RFC 9989's normal processing requires precisely one extracted From domain. If zero or more than one domain is extracted, its ordinary validation process terminates. The specification permits a receiver to continue in the multiple-domain case and discusses the security and processing implications.
That is not permission for a diagnostic tool to choose the most convenient author and report an unqualified success. If a receiver elects to evaluate multiple domains, the resulting procedure and coverage need to be recorded.
Section 11.5 discusses evaluating each domain and applying the strongest policy among the checks that fail. It also cautions that processing an excessive number of domains can create a resource problem; if not all are processed, the evaluation is incomplete. These are receiver-handling considerations, not a promise that every product accepts or displays such mail identically.
Use controlled cases with labelled expectations
The cases below are synthetic header fragments. They are not executed tests or reported receiver results, and each would need the rest of a correctly constructed message in a controlled test.
| Case | Illustrative fields | Assessment to record |
|---|---|---|
| Single author | From: author@example.com | Ordinary one-domain path, subject to the remaining message and authentication checks |
| Multiple authors in one field | From: author@example.com, editor@example.net | With the required separate single-mailbox Sender field, this can be valid multi-author format; multiple From domains still require DMARC exceptional-handling analysis |
| Duplicate From fields | One From field for example.com and another for example.net | Message-format defect; do not repair it invisibly while claiming to evaluate the original message |
| Address-like display name | Display text containing an apparent address before an actual mailbox | Parse the actual mailbox domain; assess the display risk separately |
For each case, retain the raw fixture and parser output. Count fields, list extracted mailbox values and record the domain result that led to the chosen processing path. If two mailboxes use the same domain, do not assume the mail client's display answers how the evaluator handles that multi-author construction; retain its extraction result and test the implementation.
Keep authentication evidence tied to the parsed identity
An SPF or DKIM pass for one domain cannot explain another displayed identity without the required alignment analysis. Preserve every relevant DKIM d value and trusted receiver results. Also retain the exact From bytes, including folding and comments, so the parse can be reproduced.
Do not rewrite the original From to a single author before verifying the original signature or investigating what the receiving system saw. A rewritten copy may be useful as a separate test case, but label it as a modified fixture with a different identity question.
A rejected attempt may never produce delivered headers. Preserve the SMTP response and receiving logs where available rather than inventing a delivered Authentication-Results sample.
Test presentation as well as processing
The security concern includes what a recipient sees. One component may evaluate one construction while a mail client highlights a different apparent author. In an authorised test environment, compare parser output, authentication outcome, handling and the displayed sender line for the exact same fixture.
Record software versions and settings with actual observations. Do not copy one client's behaviour into a universal claim. RFC 9989 identifies multiple-domain constructions as a potential way to avoid normal DMARC processing, so a result labelled “not evaluated” should not be presented as “safe”.
A practical outgoing configuration generally benefits from one clear From mailbox for ordinary automated mail. Where genuine multi-author functionality is needed, confirm the applicable format and supported handling with the systems that will process it rather than assuming that a required Sender field solves every downstream authentication issue.
The investigation is complete when it preserves the original syntax, explains the extracted-domain decision and connects that decision to actual receiver handling and presentation. Keep exceptional or incomplete processing visible instead of manufacturing a single green authentication answer.