Check identity and alignment

Video transcript

1. 0:00–0:06

   Inventory every sender • Include staff mail, website, CRM and campaigns. • Staff mail • Website • CRM / helpdesk • Campaigns / finance • Record domain + owner • Unknown sender • Investigate first

   Inventory every authorised sender and its domain, owner and validation evidence. Staff mail, website forms, CRM and helpdesk systems, campaigns, finance and infrequent senders can be independent paths. Keep a source being retired visible until its legitimate work has ended. Investigate unknown senders rather than authorising everything seen in a report.

2. 0:06–0:12

   Distinguish the identities • Visible From can differ from authenticated domains. • Visible From: example.com • SPF identity: vendor.example.net • DKIM identity: example.com • Assumed domains — not captured headers

   The visible From domain, the SPF identity (normally the envelope domain) and the DKIM signing domain are distinct. This assumed example uses reserved domains: visible From example.com, SPF vendor.example.net and DKIM example.com. These labels are a teaching example, not captured message headers. SPF authorises hosts for its evaluated identity; DKIM verifies signed content for a signing domain.

3. 0:12–0:18

   A pass also needs alignment • Aligned SPF or DKIM can produce a DMARC pass. • From: example.com • SPF: vendor.example.net • DKIM: example.com • DMARC via DKIM • Assumed passing checks • Check the result AND domain

   Assume the checks in the approved figure pass. SPF passes for vendor.example.net but does not align with visible From example.com. Passing DKIM for example.com aligns and can produce the per-message DMARC pass. The per-message rule allows aligned SPF or aligned DKIM; it does not require both. Separately, the article current RFC 9989 discussion says p=reject senders must use valid DKIM and must not rely solely on SPF. Forwarding only retains the DKIM path if the signature remains valid.

4. 0:18–0:24

   Inspect a received message • Published DNS alone does not prove correct signing. • Published key • Signing service • Received message • Separate placement review • Check the signing result • Placement stays separate

   A published DNS key does not prove that a service signs outgoing messages correctly. Inspect the signing domain and authentication results on a received message from each legitimate sender. Preserve unrelated TXT records; one SPF policy for a domain does not mean one total TXT record. Delivery and inbox placement remain separate checks. Authentication does not establish that content is safe, wanted or guaranteed to reach the inbox.

5. 0:24–0:30

   Make an evidence-based change • Preserve existing policy while investigating. • Existing policy stays in place • Evidence • Named owner • Verification plan • Document a proposed change

   Keep existing policy in place while investigating unless the responsible owner explicitly authorises a change. Document evidence, sender coverage, unresolved cases, owner and verification plan before a policy decision. Do not infer complete coverage from empty reports, reset an established policy by default, or reuse an obsolete percentage rollout recipe. Retire old sender authorisation only after verifying that its legitimate work has ended.