A third-party sender should enter production through an onboarding decision, not through the first complaint about a failed campaign. Start before the vendor sends customer messages. Establish who wants the service, which domain authority it needs and how a controlled test will demonstrate that the intended identities survive the actual delivery route.
Gather a service-specific request
Require a business purpose, owner, vendor account identifier, audience, criticality and planned launch date. List visible From domains, envelope sender domains, signing domains and selectors. Identify who controls DNS and who can configure the vendor account. Include replies, bounces and any gateway that modifies outgoing mail. A provider's generic setup guide is useful input, but it does not select the right scope for your organisation.
Treat each requested DNS entry as an authority decision. An SPF include authorizes an evaluation path and contributes to DNS lookup processing; it is not merely a verification label. Review the effective record and its lookup budget rather than appending vendor instructions blindly. RFC 7208. For DKIM, record the exact selector and domain and establish how keys and delegated records will be retired later. RFC 6376.
Define acceptance before applying changes
Approve an exact proposed configuration and test plan. The plan should include representative templates, expected sender identities, authorized recipients, the real outbound route and the evidence to retain. Use a recipient you control and have permission to test. Confirm authentication at a trusted receiver and evaluate alignment with the visible author domain. A valid vendor-domain signature is not automatically aligned with your From domain. RFC 9989.
Add negative cases that matter to your threat model: an unapproved From identity, a service without approval or a configuration that authenticates an unrelated domain. Where safe testing cannot demonstrate account-level restrictions, document the vendor control and remaining uncertainty. Do not attempt to send as another organisation to prove the point. Separate approved test mail from permission to begin production sending.
Separate approval, identity and route evidence
Suppose a hypothetical billing tool is approved for one account and From domain. A controlled sample is assumed to have a valid DKIM signature from an unrelated vendor domain. That signature alone does not satisfy the intended alignment check. Inspect the actual SPF identity and every relevant valid signature before concluding whether the message passes DMARC; an aligned SPF pass may satisfy the message-level rule even when this signature is unaligned.
Now suppose a campaign tool has an aligned passing sample but no business approval. Its technical result cannot authorize launch. These two cases require different next steps: investigate the billing identity configuration and obtain the campaign decision. They are illustrative assumptions, not executed messages or genuine approvals. For domains publishing p=reject, RFC 9989 sections 7.4 and 8 separately require valid DKIM signatures and forbid reliance solely on SPF; a passing message does not waive that deployment obligation.
Release and monitor the first production flows
After successful testing, let the named approver authorize the specific service and identities. Record the production start time, monitor the initial reporting windows and keep a rollback or pause route available. High-volume success should not obscure transactional failures. Record any restricted launch conditions, such as one domain or one application flow, in the service register.
Finish onboarding by assigning renewal, key-change and offboarding responsibilities. The vendor relationship will evolve, and a one-time DNS success does not ensure continuing authorization. A complete handover gives the next operator enough information to distinguish a normal change from unexplained new authority.
Keep the launch decision scoped
Record which templates, identities and routes the approval covers. If testing reveals another provider account or domain, return that scope for review instead of extending the launch implicitly. The next owner should be able to identify both the evidence passed and the conditions still open.