A bank's marketing platform can pass DMARC consistently while a small authentication-code service fails. The aggregate percentage hides the customer's inability to sign in. Inventory critical notifications by purpose and operational consequence before using overall mail health to judge readiness.
Distinguish three service promises
An authentication-code message has an expiry and retry lifecycle controlled by the identity service. A fraud alert may need timely attention through an approved contact workflow. An account notice can be less immediate but still carry consequential information. For each, document the trigger, application owner, expected timing, alternative access path and escalation team.
Do not turn this inventory into an endorsement of email as an authentication factor for a particular banking transaction. Whether email codes are appropriate depends on the institution's approved security design and applicable requirements. DMARC protects a domain-identity assessment; it cannot make a weak recovery process or unsafe factor choice acceptable.
Inspect the route that actually emits the code
Record the From domain, envelope identity, DKIM signer, selector, application tenant and environment for the identity service. Verify that test, staging and production configurations are clearly separated. A successful test through a developer mailbox says nothing about the production notification worker if it uses another provider.
For fraud alerts, record the sender that creates the alert and the channel by which customers should independently verify it. Avoid teaching customers to trust a message solely because it appears branded or authenticated. Account notices may use a batch processor with different signing and retry behavior; include it explicitly rather than inheriting the code service's result.
Measure latency without claiming more than the clocks show
Capture trigger time, provider submission time, remote acceptance where available and controlled mailbox observation time. Record time zones and clock uncertainty. Compare these stages with the institution's own approved service targets; no universal delivery-time threshold is supplied here. Aggregate reporting intervals cannot measure the arrival time of a particular code.
Use synthetic codes that cannot authenticate to any real account. Never collect usable codes in broadly accessible screenshots or diagnostics. Test expired-code behavior, delayed delivery and repeated requests in an approved non-production environment. A late code may authenticate perfectly at the email layer while correctly failing at the application layer because it has expired.
Assign recovery before tightening policy
The identity owner should define how a user regains access when email fails, while fraud operations should define how customers can verify alerts through a trusted path. The mail team diagnoses the sending identity and receiver evidence. Avoid automatic suppression of a critical security notification simply to improve an authentication percentage.
Require a representative test for every critical route and a named owner for any gap. In the local map below, the account-notice signer is stipulated to be unaligned while the code and fraud signers match exactly. This is a training contrast, not a bank measurement. Recheck after provider failover, identity-platform changes, selector rotation and changes to code lifetime or retry behavior. Separate documented rollback authority from the technical ability to change DNS.
Work through three written route records
These reserved example domains, selectors, roles and passing DKIM premises are fictional. No signed message, key, cryptographic verification, DNS lookup, SMTP transaction or live service test is supplied or executed for these cases. No test code or external specimen is needed to inspect the reasoning below.
- authentication code: visible From domain codes.bank.example; DKIM d=codes.bank.example; selector demo1; assume DKIM pass solely for this written case. SPF MAIL FROM identity and result unknown; other signatures unknown; actual policy discovery and delivery unknown. Proposed owner: Identity service owner. Next action: Obtain an authorized sample and trusted receiver result for this exact tenant.
- fraud alert: visible From domain fraud.bank.example; DKIM d=fraud.bank.example; selector demo2; assume DKIM pass solely for this written case. SPF MAIL FROM identity and result unknown; other signatures unknown; actual policy discovery and delivery unknown. Proposed owner: Fraud operations owner. Next action: Confirm this separate route and its business event rather than inheriting the first route’s result.
- account notice: visible From domain accounts.bank.example; DKIM d=provider.example.net; selector demo3; assume DKIM pass solely for this written case. SPF MAIL FROM identity and result unknown; other signatures unknown; actual policy discovery and delivery unknown. Proposed owner: Account services owner. Next action: Ask the verified supplier for this tenant’s supported aligned signing path; do not broaden authorization to its entire network.
For the first two stipulated signatures, d= exactly equals the From domain, so the identifier satisfies strict as well as relaxed alignment. Given the stipulated successful DKIM result, an aligned authentication path exists for those hypothetical messages. The third signer is deliberately unrelated to the author domain and cannot provide that aligned path. Do not call the third message a DMARC failure: aligned SPF or another aligned passing DKIM signature could still satisfy the mechanism, and those inputs are unknown. Do not infer real deployment or inbox placement from any row.
A cryptographic signature authenticates a signing domain’s responsibility, not the truth or authorization of every instruction. Changes to covered canonicalized bytes can invalidate a signature; not every visible edit necessarily changes the signed input. Authentication and application-level acceptance remain separate.
Read a hypothetical expiry timeline
For nonfunctional case OTP-01, assume synchronized clocks: trigger 10:00:00 GST, provider submission 10:00:01, remote SMTP acceptance 10:00:03, approved application expiry 10:01:00 and controlled-mailbox observation 10:01:10. This invented arrival is 70 seconds after trigger and 10 seconds after the assumed expiry. Even a stipulated aligned DKIM pass cannot extend the code lifetime. The identity owner investigates latency and the approved recovery path; the application must apply its configured validity rules. Remote acceptance is not mailbox observation or human reading. No operational latency, code validity or customer access was measured. Actual logs need clock offsets and uncertainty before comparing stages.
Apply the standards without claiming compliance
RFC 9989 Sections 4.4 and 5.3.5 support the alignment and mechanism distinction. Its Section 7.4 warns about indirect-mail interoperability: domains using p=reject must use valid DKIM, not SPF alone, and general-purpose mailing-list use needs particular care. A route inventory is not itself permission to enforce reject. RFC 6376 Sections 3.4–3.7 and 6.1 describe signed inputs and verification. RFC 9990 Section 3.1 provides reporting context, not per-recipient arrival proof. RFC 5321 Section 4.2.5 distinguishes server acceptance responsibility from later delivery outcomes. Sector workflow choices here are editorial recommendations; legal scope, factor suitability and local authorization need their own accountable review.