How to request enough evidence from a sender to diagnose DMARC

The fastest useful DMARC evidence request asks for one representative message, the route that produced it and the receiving system's result. A screenshot saying “SPF passed” or “domain verified” usually omits the identities needed to explain the failure.

Request the smallest evidence set that can distinguish an authentication problem, an alignment problem, a DNS problem and a delivery problem. Expand the request only when a specific uncertainty remains. This reduces unnecessary exposure of customer content and gives the sender a task they can actually complete.

Ask for a safe reproduction first

Where practical, have the application owner send a non-sensitive test message through the affected production workflow to an authorised test recipient. The workflow matters: a test button in the provider console may use a different sender or route from invoices, password resets or scheduled notifications.

Record the application, customer account or tenant reference used internally, triggering action, UTC send time, intended recipient system and whether forwarding or a gateway is involved. A message identifier can help correlate logs, but share it only through the agreed support channel. Do not request passwords, private signing keys, API credentials or unrelated mailbox exports.

Keep the initial request focused on the technical problem. If the failure involves a real customer's message, use approved handling and access controls before sharing its contents with another party.

Preserve the evidence that distinguishes the identities

Ask for the original message as received at the affected destination, or a recipient-side diagnostic export that retains the relevant headers. The useful fields include the visible From domain, envelope identity where available, relevant DKIM signatures and the receiving system's Authentication-Results.

The receiving operator must identify which result is trusted. Header text alone can be forged or carried from an untrusted source; RFC 8601 §1.2 and RFC 8601 §7.1 explain the trust-boundary requirement. If several Authentication-Results fields exist, do not assume the topmost pass is automatically authoritative.

For initial triage, an administrator can extract the relevant identity and result fields while retaining the original securely. That is different from cryptographically re-verifying DKIM. Editing signed headers or the body can invalidate a signature, so a redacted copy cannot necessarily reproduce the original validation. If independent re-verification is necessary, arrange controlled access to an unmodified sample or generate a safe new test. The signature-sensitive handling follows RFC 6376 §3.4 and RFC 6376 §3.7.

A minimal request you can adapt

Use the following as an operational template, not as a request to disclose credentials:

“Please send a non-sensitive test through the affected workflow and provide:

• The application and exact workflow, the send time in UTC, and whether the route includes forwarding or a gateway.
• The original received message through our approved support channel, or the recipient administrator's extracted From domain, SPF-evaluated identity and result, each relevant DKIM d= and s= value and result, and trusted DMARC result.
• The exact rejection response if delivery failed, including which system returned it. If no recipient message exists, provide sender-side trace details instead.
• The authentication settings used by this specific workflow and the provider's current instructions for its supported customer-domain configuration.
• Any recent DNS, key, gateway or sender-address change and its timestamp.

Please do not include account passwords, API keys, private DKIM keys or unrelated customer records. Retain the original sample unchanged if signature verification may be needed.”

This request creates a common reference point. It does not assume that the vendor's shared infrastructure or a familiar source IP proves your organisation authorised the sender.

Match each answer to a diagnostic question

Build a small evidence worksheet before proposing changes.

• Evidence: From domain; Question it answers: Which Author Domain is DMARC evaluating?
• Evidence: SPF result and evaluated domain; Question it answers: Did SPF pass for an identity relevant to this route?
• Evidence: DKIM results, d= and s=; Question it answers: Which signing identities verified, and which keys were used?
• Evidence: Applicable policy and alignment modes; Question it answers: Does a passing identity align under the relevant rule?
• Evidence: SMTP response or final disposition; Question it answers: What actually happened to delivery?
• Evidence: Change timestamps and current DNS observations; Question it answers: Could configuration timing explain different observations?

The identity and alignment checks follow RFC 9989 §5.3.3, RFC 9989 §5.3.4 and RFC 9989 §5.3.5. The worksheet and request format are practical recommendations.

Handle missing evidence explicitly

If the sender only supplies its console status, ask for a received sample from the actual workflow. If a recipient rejected before accepting the message, acknowledge that no final mailbox copy may exist. Use the sender's outbound trace, rejection response and the receiving operator's logs where available.

If current DNS differs from the message's timestamp, do not claim it proves what the earlier receiver saw. Ask for the change history or a fresh controlled reproduction. If the provider cannot offer a supported aligned identity, record that capability gap and the affected workflow instead of inventing DNS values.

Finish the investigation with a before-and-after identity comparison, the exact change and a new trusted result. Link that evidence to the sender inventory. The alignment failure guide helps interpret it, while the reporting privacy guide supports decisions about retained evidence.

Make the next decision explicit

If only a console screenshot exists, mark the evaluated SPF domain, aligned DKIM identity and receiver trust boundary as missing. Ask for those fields rather than declaring a DNS fix. If rejection prevented mailbox delivery, use the SMTP response and sender trace instead. Record each observation’s timestamp separately from later DNS inspection; no original message has been collected or verified here.