A tender notice can be authentic yet contain an unauthorized bank-detail change after an account compromise. Authentication helps evaluate domain identity. Procurement authority comes from the approved process and accountable people. Design the two checks to reinforce each other without allowing one to substitute for the other.
Map the notice to the procurement record
For tender publication, supplier notices and delegated procurement, record the system of record, notice identifier, approved sender and accountable contracting role. The notification should help a supplier find the authoritative procurement record through a known channel. Avoid treating a link in an unexpected message as independent verification of the same message.
Record the application tenant, From domain, envelope domain, DKIM domain and selector for each route. An outsourced procurement portal may have separate sending infrastructure from the authority's staff mail. A branded footer or Reply-To address does not establish an aligned authentication path. Keep reply handling in the route map because a genuine notice can direct replies to a different operational mailbox.
Keep consequential changes behind their own approval
Classify notices by what they ask the recipient to do. A tender-open announcement, deadline amendment, award communication and payment-detail request have different operational consequences. This guide recommends separate procurement and finance verification for sensitive supplier or bank changes using established contact records, not a phone number supplied in the disputed email.
DMARC does not inspect a tender's terms or determine who approved an award. Nor does a passing signature establish that a bank account belongs to the intended supplier. Retain the change authority, approved record and independent verification result in the procurement system. These are workflow recommendations, not a statement of any jurisdiction's procurement law.
Test the delegated sender before a deadline
Run approved samples for initial notice, amendment and cancellation, with fictional tender details. Confirm the intended From identity, signature result, applicable alignment, reply destination and successful access to the official record. A signature test cannot establish that the notice arrived before a legal deadline. Preserve the relevant delivery and publication evidence separately.
If a contractor changes platform during an active tender, retain the old route until the approved cutover and queue handling are understood. Set an owner for failed notices and a documented alternate notification process. Do not silently resubmit a notice through a new identity because an integration failed. Such a change can confuse suppliers and must be handled under the procurement team's approved communication process.
Reassess the supplier-facing boundary
Review reports by procurement service, not merely across the department's total mail volume. An apparently healthy aggregate can hide a low-volume amendment sender. Escalate unexpected signing domains, new Reply-To destinations and unowned vendor accounts. Before retiring a domain or selector, establish which tender records and recurring notices still depend on it. Authentication evidence belongs alongside, rather than in place of, procurement audit records.
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.
- tender publication: visible From domain tenders.civic.example; DKIM d=tenders.civic.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: Procurement lead. Next action: Obtain an authorized sample and trusted receiver result for this exact tenant.
- supplier notice: visible From domain suppliers.civic.example; DKIM d=suppliers.civic.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: Supplier communications owner. Next action: Confirm this separate route and its business event rather than inheriting the first route’s result.
- delegated procurement: visible From domain contracts.civic.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: Contracting authority. 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.
Use a notice-specific acceptance card
For fictional tender T-01 amendment version 2, require the approved record version, authorized contracting role, From identity, reply destination, publication time and recipient-notification evidence. If authentication passes but the official record remains version 1, stop and reconcile the amendment with procurement; do not label it approved. If the record is correct but notification fails, invoke the already approved alternate notice process and retain timing evidence. A changed beneficiary triggers the separate finance verification process regardless of either result. These are proposed decisions, not procurement-law requirements or completed tests.
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.