Documentary review: 8 November 2026. No delivery attempt, TLS report or message header was inspected. The diagnostic matrix and fictional case below are proposed evidence structures, not findings about an actual mail incident.
Locate the failure in the delivery sequence
Transport-policy failures and message-authentication failures answer different questions. Transport checks concern the connection used to move a message between mail servers. SPF, DKIM and DMARC evaluate sender identities and message authentication. A message can arrive over authenticated TLS and still fail DMARC; a legitimate signed message can also be delayed because the receiving transport route fails an enforced policy.
Begin with an actual delivery attempt reference, timestamp, sender system and intended recipient domain. Determine whether the sender reached an MX, negotiated TLS and transferred the message, or stopped before message acceptance. If delivery did not reach the receiver, there may be no received message whose Authentication-Results can be inspected. Do not invent header evidence to fill that gap.
Record who observed the failure. A sender's SMTP log, a receiver's connection log, a TLS-RPT aggregate report and an accepted message each see different parts of the transaction. A customer-facing bounce summary may omit the stage needed for diagnosis. Ask for the precise sanitized response and relevant context rather than interpreting the word authentication in isolation.
Identify transport-policy evidence
MTA-STS uses DNS discovery and an HTTPS policy to tell supporting senders which MX hosts and TLS conditions are acceptable for a policy domain. In enforce mode, a compliant sender must not deliver to a host that fails MX matching, certificate validation or STARTTLS support. This concerns the receiving route, not the message's visible From identity. MTA-STS validation and application
DANE for SMTP uses DNSSEC-authenticated TLSA information for the relevant receiving service. A DNSSEC validation problem or a mismatch with usable TLSA associations can prevent a compliant sender from using that candidate securely. DANE certificate usages have their own validation semantics; do not apply ordinary public-CA expectations indiscriminately to every DANE configuration. SMTP DANE discovery and authentication
TLS-RPT can describe failures such as STARTTLS not being supported, certificate hostname mismatch, certificate expiry or policy-related problems. Read the report's policy domain, policy type, receiving host, reporting interval and failure detail together. An aggregate failure count is not an individual message trace and does not identify the business sender's SPF or DKIM status. TLS reporting schema and result types
Keep policy retrieval failures separate from SMTP endpoint failures. An inaccessible MTA-STS HTTPS file is not the same as an MX presenting the wrong certificate. A cached MTA-STS policy can remain applicable when live retrieval fails, so the state at a sender may differ from the file currently visible to an operator. Retain the policy version and observation time where available.
Identify message-authentication evidence
SPF evaluates whether the connecting client is authorized for the relevant SMTP identity, normally the envelope sender domain. It does not validate the visible From address by itself. Collect the evaluated identity and result from a trusted receiver rather than guessing from the sender display name. SPF evaluation
DKIM verifies a signature using the signing domain, selector and public-key lookup, together with the signed message data. Record the d= and s= values and every relevant signature result. A TLS certificate on the receiving MX is not a DKIM key, and rotating that certificate will not repair a wrong DKIM selector. DKIM verification
DMARC assesses whether an authenticated SPF or DKIM path aligns with the visible From domain under the applicable alignment rules. A raw SPF pass for an unrelated envelope identity can coexist with DMARC failure. A working encrypted connection does not make that identity alignment pass. DMARC identifier alignment
Use Authentication-Results only from the receiver or trusted boundary relevant to the investigation. A header carried in an untrusted original message can claim arbitrary results. Preserve the raw message and the trust context so the analyst knows which system performed the check. This proposed workflow does not treat a pasted green badge or an unverified header line as conclusive evidence. Authentication-Results trust boundaries
Match the remediation to the failed layer
If the SMTP route fails because an intended MX is absent from an MTA-STS policy, review the receiving route and policy update process. Adding an SPF include at the sender domain does not add that MX to the transport policy. If the receiving certificate fails its applicable validation, the receiving service owner needs the certificate and hostname evidence.
If a delivered message fails DKIM because the actual selector cannot retrieve a matching public key, investigate the signing configuration and DNS key path. Do not disable transport enforcement to make the message authenticate. If DKIM passes but DMARC fails, compare domains and alignment settings rather than replacing an unrelated TLS certificate.
Some incidents span layers. A migration can change MX providers, envelope identities and signing domains at the same time. Track separate evidence and owners for each change. A transport repair may allow delivery to resume while exposing an unresolved authentication failure in the newly delivered messages. That is not proof that the first diagnosis was wrong; it may mean the investigation has reached the next stage.
Preserve timing and policy context
Authentication and transport evidence should be compared for the same route and time window. A current DNS lookup does not necessarily describe the answer used during an earlier attempt. MTA-STS policy caches and DNS caches can outlive a configuration change. Record when each policy, key and DNS observation was collected.
For an enforce-related MTA-STS failure, compliant senders check DNS for an updated policy before permanently failing delivery, and the specification recommends treating such failures as transient and retrying. Do not translate that guidance into a guaranteed retry schedule or a promise that a business message will eventually arrive. MTA-STS failure handling
TLS reports are normally aggregate, delayed observations from participating systems. A clean reporting interval is not proof that every sender or backup route was tested. Conversely, missing TLS reports cannot establish SPF, DKIM or DMARC health. Keep collection coverage as its own evidence state.
Cross-layer diagnostic worksheet
- Attempt: timestamp ___; sender system ___; recipient/policy domain ___; message or delivery reference ___.
- Route: selected MX ___; address/context ___; SMTP stage reached ___; exact sanitized response ___.
- Transport policy: MTA-STS or DANE ___; policy/TLSA evidence ___; cache or DNSSEC status ___; hostname/certificate/STARTTLS result ___.
- Reporting: TLS-RPT submitter ___; interval ___; policy type ___; failure category/detail ___; limits of correlation ___.
- Accepted-message evidence: trusted receiver ___; visible From ___; SPF identity/result ___; DKIM d=/s=/result ___; DMARC alignment/result ___.
- Action: failed layer ___; responsible owner ___; proposed scoped repair ___; other unresolved layers ___; retest and sign-off ___.
A field that cannot exist because the attempt stopped earlier should be marked not observed, not passed. That distinction prevents a transport rejection from being mislabeled as a verified message-authentication failure.
Fictional example: encryption works, alignment does not
This case is fictional. A receiver accepts a message over a valid MTA-STS-compliant TLS connection. Its trusted results show SPF passing for an unrelated supplier envelope and DKIM passing for that supplier's domain, while the visible From is example.com. DMARC fails because neither passing identity aligns.
The proposed diagnosis preserves the successful transport result and investigates the sender's supported aligned signing or envelope configuration. It does not alter the receiving MX certificate or weaken MTA-STS. A fresh controlled message is required after the approved sender change. No test in this example occurred; independent review, live evidence, visual checks and accountable owner release remain pending for this draft.