Separate the visible signature from the cryptographic one
An email signature service usually adds visible material such as a person's contact details, company logo or legal wording. DKIM adds a cryptographic header that binds selected message content to a signing domain. The shared word “signature” does not make these operations interchangeable. The key question is whether visible content is inserted before or after the DKIM signature that the receiver evaluates.
No signature-service account, connector or raw customer message was examined here. This article provides a diagnostic plan and a fictional ordering example. The original evidence gate remains open: Original and modified raw messages, signer placement and a before-and-after verification test. Collect these before attributing an incident to a service.
Locate where the visible material is inserted
A user's mail application can insert a signature during composition. A server-side service can instead receive a submitted message, add content and send it onward. Other workflows combine client insertion with server fallback. These are possible designs, not universal product behavior. Ask for the specific supported integration and the route actually used by the affected sender.
Microsoft's documentation distinguishes user-applied signatures from organization-wide mail-flow rules that add signatures, footers or headers. It demonstrates that insertion location can differ even within a familiar platform. It does not establish the relative order of an unknown third-party service and an organization's DKIM signer. Retain the provider's applicable integration guidance and verify the deployed sequence separately. Microsoft message additions
Read the signature that actually failed
Record the DKIM signing domain, selector, canonicalization and signed-header list for every signature present. A message may carry signatures from multiple processing stages, and each must be assessed independently. Do not summarize one failed original signature and one valid provider signature as a single unexplained “DKIM problem.” Preserve the result and domain associated with each check. RFC 6376 sections 3.5 and 4.2
For the body, compare the bytes after the selected canonicalization, not only the appearance of the email. Relaxed body canonicalization normalizes specified whitespace; it does not erase a logo, a new HTML table or a changed link. Conversely, a change consisting solely of tolerated whitespace need not invalidate that signature. Check any l= body-length limit when describing coverage, but do not propose leaving newly appended business content unsigned as the default repair. RFC 6376 sections 3.4 and 8.2
Compare MIME forms and route variants
A message can contain plain-text and HTML alternatives, embedded images and attachments. A server-side addition may alter more than the part displayed by one mail client. Capture unchanged raw messages at the relevant boundaries and compare MIME structure, encoding and the resulting canonicalized body. An image that looks identical on screen can still accompany a different serialized message.
Include the routes that matter to the organization: desktop composition, mobile sending, shared-address replies and automated applications where applicable. Their paths may differ. A pass on one desktop message cannot prove that a mobile message used the same signer or avoided a second insertion. Record unknown routes as gaps rather than inventing provider defaults to fill them.
Work through a fictional double insertion
Imagine fictional example.com prepares a message containing a user-added text signature. Its outbound signer applies a full-body DKIM signature with d=example.com. A later service appends a centrally managed HTML signature before external delivery. Assume the input signature verified and the added material changes the canonicalized body. The original signature then fails verification on the modified representation. This is a constructed example, not an executed trial.
Suppose the service also signs with d=signature-service.example while the visible From remains person@example.com. That new signature can be valid without aligning with the author domain. DMARC evaluates aligned authenticated identifiers, not whichever signature was added most recently. A separate aligned SPF result could still provide a passing path, so the failed original DKIM signature alone is not a complete DMARC diagnosis. RFC 9989 sections 3.2.10 and 5.3
Review signing order without granting new authority
For legitimate example.com outbound mail, a proposed integration might complete visible-content insertion before an authorized example.com signer processes the final message. Another supported architecture may have an appropriately authorized service perform aligned signing after its additions. Which option is available depends on documented product behavior and the actual tenant design; neither has been configured by this article. RFC 6376 section 5.1
Changing signing order is different from handing a vendor private-key material or broad relay permissions. Identify the responsible domain, approved identity and credential boundary before proposing a deployment. Adding a vendor to SPF does not repair a changed DKIM body hash, and it does not automatically make an unrelated envelope identity align. Keep envelope authorization and message-signature integrity as distinct tasks. RFC 7208 section 2.4 RFC 9989 section 3.2.4
Verify both appearance and authentication
The acceptance plan should include intended branding, absence of duplicate additions, correct links and readable plain-text output alongside cryptographic checks. A visually attractive result can fail authentication, and a valid signature can cover the wrong corporate footer. Assign separate owners for content approval and mail authentication so that neither criterion silently substitutes for the other.
After a separately authorized test, retain the original and final raw samples, route evidence, relevant public-key context and per-signature verifier results. Use Authentication-Results only from an identified trusted evaluator; a copied field is not proof of the final message's integrity. This package contains no such operational samples or completed account-specific validation. RFC 8601 section 7