Specify which message the banner changes
An outbound legal disclaimer, an inbound warning banner and a header-only classification mark can all be called a mail banner. They do not have the same effect on authentication. Identify the direction, insertion point and exact representation being changed before interpreting a DKIM result. A passing check at ingress can coexist with a later failure after an internal body modification.
This is a proposed evaluation, with no transport-rule changes or messages sent. Original evidence gate: Direct and indirect delivery samples with route, envelope, signatures and trusted results compared. The fictional cases illustrate boundaries; they are not observations from a customer tenant.
Separate rule matching from content transformation
A disclaimer rule needs both a condition that selects messages and an action that changes them. Microsoft's Exchange Online documentation describes additions to the top or bottom of messages and conditions for limiting them to outbound mail. Those documented capabilities do not identify the rules installed in a particular organization. Record actual scope, exceptions and priority from an authorized configuration review before predicting outcomes. Microsoft disclaimer rules
Distinguish a logged rule match from an actual transformed message. Microsoft states that Test without Policy Tips logs results without adding the disclaimer. That mode can help evaluate selection, but it cannot by itself demonstrate whether inserted content would survive DKIM verification or render correctly. Plan a separately authorized controlled message transformation when evidence of those effects is needed. Microsoft rule mode
Compare the signed inputs rather than the label
DKIM verification depends on selected header instances and canonicalized body coverage. Adding an unsignaled visual label in a mail application's interface is not necessarily a change to the stored message. Inserting HTML warning text into a MIME part is a message change. An added header outside the selected signature coverage can have a different outcome from editing a signed Subject field. RFC 6376 sections 3.4–3.5 and 5.4
Do not claim that every content modification inevitably breaks DKIM. Some differences disappear under the configured canonicalization, and coverage can be affected by header selection or l=. For a signature covering the entire body, an ordinary disclaimer that adds non-whitespace text changes the canonicalized input and invalidates that signature, assuming it verified beforehand. Relaxed canonicalization is not permission to append arbitrary text. RFC 6376 sections 3.4 and 3.5
Place authentication results on the processing timeline
For inbound mail, an identified trusted gateway may authenticate the original message before adding a warning for internal readers. A later system can then see modified bytes and obtain a different result. Preserve both the evaluation time and the representation assessed. Authentication-Results is useful only within an established trust model; an untrusted field claiming success does not establish what the gateway actually checked. RFC 8601 section 7
For an organization's own outbound mail, consider whether the intended disclaimer is applied before its authorized aligned signer. A final external hop that appends text after signing can undermine that signature. Do not infer actual order from rule priority alone when the signer and rule engine belong to different services. Capture the real path and supported processing arrangement before proposing an order change. RFC 6376 section 5.1
Follow two fictional banner cases
In fictional case one, example.com signs a full-body message, then an outbound relay appends “For business use only.” Assume the signature verified before the relay and that the new words appear inside its canonicalized body coverage. The final representation no longer verifies under that original signature. A second aligned authenticated path would need separate evaluation; a DKIM failure is not automatically a final DMARC failure. RFC 9989 section 5.3
In fictional case two, a receiving organization's trusted ingress records a valid original signature and then inserts an internal caution banner. The preserved ingress assessment and a later verification failure can both be consistent with the processing history. Neither case proves how any actual gateway works. The remedy question differs: fix outbound signing order in the first case, and accurately preserve evaluation boundaries in the second.
Treat wrapping as a different message structure
When a disclaimer cannot be inserted, Microsoft's documented fallback choices include wrapping the original as an attachment inside a new message. The documentation also describes subsequent rules examining the new outer message. A retained signature on an attached original must not be confused with a signature authenticating the outer message carrying the disclaimer. Inspect both layers if this fallback is actually used. Microsoft fallback options
Microsoft specifically prohibits Wrap in rules affecting incoming messages from external senders because it interferes with Safe Attachments scanning. For those rules, Microsoft says to use Reject instead; that fallback returns the original message to the sender in a non-delivery report. This product-specific restriction is not authorization to change a rule, and no Reject action was configured or executed here. Microsoft incoming-message restriction
Wrapping also changes the recipient experience and downstream processing. The acceptance plan should include opening the attachment, reply behavior, scanning requirements and any content that must remain visible. Do not select a fallback solely because it avoids one authentication indicator. Encrypted or otherwise unmodifiable content needs an owner-approved handling decision rather than an assumed universal exception.
Keep warnings and delivery decisions separate
A disclaimer does not authenticate its author, and a warning banner does not prove that the message failed DMARC. DMARC evaluates the author domain against aligned authenticated identifiers; message disposition also reflects receiver policy and other signals. Describe the actual rule and authentication result independently, particularly when a banner is based on external origin rather than an authentication failure. RFC 9989 sections 4.1 and 5.3
Close an approved evaluation with direct and indirect raw-message samples, rule-match evidence, transformed copies and per-signature results. Include messages that should match and should not match, plain text and HTML where relevant, and repeat handling that could duplicate a disclaimer. None of those live checks occurred here, so rendering, tenant behavior and actual delivery remain open gates.