Manufacturing email inventories often begin with employee mail and miss the ERP scheduler, procurement tool and supplier portal. These applications may run under service accounts, send only after an overnight batch, or use a relay owned by a plant team. Authentication work must follow the production process without interfering with it.
Map the application, relay and owner
Assign ERP notifications to the ERP service owner, purchase requests to procurement technology and supplier-portal mail to the supplier integration lead. Record the trigger, plant or business unit, provider account, relay, author domain and signing selector. Include scheduled jobs and exceptional processes such as rework, cancelled orders and supplier-account recovery where they use different routes.
Use a test work order and a clearly nonbinding purchase-request specimen. Never generate a real supplier commitment merely to collect an email header. Ask procurement to confirm that the test cannot approve expenditure or enter a live fulfillment queue. Avoid confidential bills of materials, pricing or bank details in the retained message sample.
Trace the final signing point
An ERP may submit through an internal relay that adds a notice before an external gateway signs. Another route may sign first and then have the message altered. Map the sequence rather than assuming that configuring a key in one console covers the entire path. A substantive footer inserted after signing changes the canonicalized signed body and can invalidate a full-body signature. Canonicalization can tolerate some formatting differences, so diagnose the actual signed bytes and signature settings rather than treating every alteration alike. No footer test was executed here.
The fictional procurement service uses buy.factory.test as From and procurement-vendor.test as signer. Even assuming a cryptographically valid signature, these hypothetical domains fail strict DKIM alignment; this is not an observed verification result or a complete DMARC verdict. Confirm the intended domain and actual service tenant, then evaluate supported configuration changes. Do not fix the mismatch by granting a plant-wide relay unrestricted use of every corporate domain.
Keep business approval separate
Authentication does not establish that a purchase request is approved, that a supplier account is genuine or that a payment destination is correct. Maintain the procurement system's authorisation and payment-verification controls independently. An authorised but compromised application can send a well-authenticated malicious instruction.
For acceptance, trigger the real test job, retain a received sample and reconcile it with application logs. Compare normal and exception jobs rather than taking a single manual send as proof. If the system is batch-driven, observe an appropriate cycle under the owner's approval; a quiet hour is not evidence that the application never sends.
Change around operational constraints
Plan maintenance with the plant and ERP owners. Document a recovery path for the specific service, preserve approved configuration evidence and monitor pending jobs after the change. Report a sender as unresolved when its owner or tenant is unknown rather than granting speculative permissions. Contract, confidentiality, export-control and recordkeeping requirements need qualified review. This technical example makes no determination about those obligations and authorises no purchasing action.
Fictional route map
The following explicit identities are illustrative inputs, not real customer configuration. The identities and accountable roles are hypothetical, not customer approvals or supplied messages. No signing test or network delivery was performed.
- Erp notification: ERP service owner; From erp.factory.test; envelope and DKIM signer erp.factory.test.
- Procurement system: Procurement technology lead; From buy.factory.test; envelope and DKIM signer procurement-vendor.test.
- Supplier portal: Supplier integration lead; From suppliers.factory.test; envelope and DKIM signer suppliers.factory.test.
Resolve a batch-path discrepancy
Suppose a manually triggered ERP test passes but the overnight procurement batch uses another relay that inserts a substantive notice after full-body signing. Keep the procurement route unresolved and compare its received header and signed-content evidence with the application logs. Changing the manual route’s key would not address an alteration on the batch route. These are assumed conditions, not a diagnosis of an actual plant.
RFC 6376 Sections 3.4, 3.5 and 3.7 explain canonicalization, signature tags and message hashes. RFC 9989 Sections 4.4, 5.3.5 and 5.4 separate alignment and receiver decisions. Other aligned authentication can affect a message verdict, while p=reject deployment requires valid DKIM under Sections 7.4 and 8 rather than SPF alone. No purchase order, signer change or production mail test was performed.