Separate message construction from domain authentication
An application can send a correctly authenticated message that it should never have constructed. SPF, DKIM and DMARC answer questions about sending authorization, signatures and domain alignment. They do not decide whether a contact form was allowed to choose recipients, whether a subject field was interpreted as another header, or whether a workflow approved the request. This distinction matters for password notifications, support forms, invoices and any application that assembles mail from external input. A successful DMARC result is not a substitute for validating that input before message serialization.
RFC 9989 explicitly excludes content analysis and authentication of entities other than domains from DMARC's goals. That boundary is the starting point for this threat model, not a reason to weaken authentication. Keep aligned authentication and separately control how applications construct messages. This manuscript proposes defensive review steps. It does not reproduce an exploit, send messages, inspect a real application or supply an attack payload.
Understand the serialization boundary
RFC 5322, section 2.2, describes a header field as a field name followed by a colon and a field body, terminated by CRLF. The standard also describes folding and unfolding long fields. Those are message-format rules. They do not mean an arbitrary form field should be permitted to supply header separators or continuation lines. An application must distinguish data intended for one field from the structure that separates fields.
Header injection is the failure mode in which externally controlled data crosses that structural boundary and affects headers beyond its intended position. Its practical impact depends on the mail library, API, transport and authorization model. Do not assume every newline accepted by a web form reaches SMTP unchanged. Equally, do not assume a downstream signer repairs an unsafe construction decision. A signature can cover the message that the application actually produced, including an unwanted but syntactically valid result.
Inventory input and authority before choosing validation
Build a field map for the application. Record where a value originates, which component parses it, its intended type, who may supply it and where it ends up. Distinguish a display label from an address, a subject from a body, and visible recipient fields from the transport envelope. A contact address submitted by a visitor should not automatically become an authorized envelope sender. A support form's customer identifier should not be treated as an unrestricted recipient list.
Define business constraints first. Some applications need exactly one recipient selected from an internal mapping; others legitimately support several approved recipients. Free text may be acceptable in the body but not in a routing field. Apply limits to size and cardinality, and reject unexpected structural characters where the field contract prohibits them. These are proposed application requirements, not a claim that RFC 5322 mandates one validation implementation for every language or product.
Prefer structured construction, then verify its behavior
Use the supported structured mail interface for the chosen framework rather than manually concatenating complete header lines from input. The Python EmailMessage documentation illustrates this separation: the object represents headers and payload, offers field operations, and serializes according to an email policy. It also warns that flattening can trigger changes such as generating MIME boundaries. These documented capabilities do not establish that every application using that class is secure, or that all library versions reject the same invalid inputs.
Review the actual library version and policy in the application before relying on its handling. Validate before constructing the message and retain a separate authorization check for destinations. Avoid a repair routine that silently removes suspicious characters and changes the meaning of a value. A predictable rejection with a safe error is often easier to reason about than a value transformed into a different recipient. Never log passwords, reset tokens or complete sensitive notification bodies merely to debug construction.
A non-destructive acceptance worksheet
Create one worksheet row for each input-to-output path. Include the application component, input field, expected type, allowed destination source, parser and serializer versions, validation decision, and expected observable result. Add a column for the reviewer who owns the field contract. A business owner can approve intended recipient behavior while an engineer checks how the implementation enforces it; neither approval should be inferred from a mail authentication dashboard.
Proposed local cases can include a normal short subject, an empty required value, an overlength value, unexpected control characters represented as test metadata, and a display label containing punctuation. Keep the cases in an isolated harness that cannot connect to a mail service. Inspect the parsed message structure rather than sending an exploit to a production recipient. Acceptance means the intended field remains within its contract, unauthorized recipients are impossible through that input path, and errors are handled without exposing secrets. No such harness was executed for this manuscript.
Fictional diagnosis: a support form with mixed responsibilities
Consider a fictional company, Cedar Support, whose form allows a visitor to enter a reply address and a request description. A developer also lets a query parameter choose the destination support queue. The message passes DMARC because Cedar's approved service signs it. The team initially treats that result as proof that the form is safe. It is evidence of neither recipient authorization nor the input validation rules.
The proposed investigation separates two questions. First, does the queue parameter map only to approved internal destinations? Second, can any free-text value alter the serialized message's structure? The team would review local construction output and authorization decisions without sending mail. Even if the serializer rejects malformed header data, an unrestricted destination parameter could remain a distinct abuse path. Conversely, a correct destination allowlist does not prove every header field is safely constructed. This is an invented diagnostic scenario, not a discovered vulnerability or a completed test.
Release criteria and evidence still needed
Document what each layer proves. Input validation establishes that submitted data meets the application's contract. Authorization establishes whether that actor may request that destination or action. Serialization produces the intended message format. Authentication helps receiving systems evaluate domain use. Delivery monitoring reveals what happened afterward. Combining these layers is useful precisely because none alone proves the others.
The catalogue requires a defensible threat model and a non-destructive lab reproduction tied to the original research. That evidence is still open. This draft contains a proposed model and worksheet, not original research or a lab reproduction. OWASP pages requested during research were unavailable and are not cited as support; they were not retried through another route. A qualified application reviewer must verify the implementation, a controlled lab must retain its actual observations, and source applicability, production routes, accessibility and owner release must be reviewed before publication. No production input, credential or real message is needed to understand the boundary described here.