Make onboarding an evidence trail, not a record generator
An approved business service is not automatically an approved domain configuration. A team may have permission to use an email platform while still needing decisions about which tenant, sender identity, DNS changes and data-sharing destinations are appropriate. An agent can organize that work, expose missing prerequisites and prepare a precise change proposal. It should not turn a familiar provider name into permission to modify production.
This is a proposed operating workflow. It does not assert that EmailAuth currently implements service discovery, approval enforcement, provider connectors or automated verification. Those capabilities require current product evidence. No service account, DNS zone, message stream or approval control was inspected or changed for this article.
Identify the business service and its accountable owner
Start with the business purpose, responsible team, approved provider account and intended message categories. Record the domain or subdomain the service may use, expected recipient population and the person who can approve that scope. A provider’s infrastructure can be shared by many customers; an IP or hostname seen in a report is a lead to investigate, not proof that this organization authorized the sender.
An agent can compare an approved inventory with available observations and label a possible match. The owner must resolve ambiguity about the actual service instance. Keep evidence of the match separate from a confidence score. RFC 9990 aggregate reports provide useful authentication and source information, but their contents may be false and do not independently establish a commercial relationship. RFC 9990, sections 3.1 and 8.2.
Assemble prerequisites without expanding access
Collect the provider’s current supported setup instructions for that service instance, the organization’s sender requirements and the relevant existing configuration. Identify which parts can be read under existing authorization and which require an administrator. Preparing an inventory does not require collecting passwords or private keys into an agent’s conversation or report.
The proposed access boundary should allow the agent to inspect only the approved tenant and resources needed for the task. An integration with broad write privileges is not made read-only merely because the prompt asks for analysis. OWASP’s excessive-agency guidance recommends limiting both tool functions and downstream permissions. Verify the actual enforcement before using a connector in production. OWASP Excessive Agency.
Preview identities and changes together
The proposal should connect the visible Author Domain, SPF identity, DKIM signing domain and provider account. A generated TXT value is only one part of that relationship. DMARC evaluates qualifying authenticated identifiers and alignment with the Author Domain; a provider’s unrelated default signature is not automatically aligned. RFC 9989, section 4.4.
Show the exact proposed owner names, record types and values alongside the observed current state. Explain whether a change adds a narrowly scoped record, alters an existing sender authorization or delegates control through a provider-managed name. Do not silently replace an entire SPF record, broaden a domain delegation or remove another sender’s selector to make a new service fit. Each operation needs a responsible approver and a recovery decision.
Keep reporting consent distinct from technical routing
If onboarding proposes an external aggregate-report destination, identify who would receive the reports and why. RFC 9990 defines a DNS-based check of external reporting arrangements. That technical confirmation establishes the destination’s willingness to receive reports under the protocol; it does not replace the organization’s approval to share its reporting data with that processor. RFC 9990, section 4.
The same distinction applies to provider access. An agent should describe a required administrative permission before anyone grants it. An approval to prepare documentation does not authorize persistent account access, credential creation or cross-tenant changes. If the supported workflow needs more authority than the agent has, the preparation remains useful while the execution step stays assigned to the authorized administrator.
Bind approval to the actual proposal
A useful approval identifies the service instance, tenant, domain, exact changes and relevant current-state snapshot. If those facts change before execution, return the affected change for review rather than treating an old approval as a general license. The execution mechanism should verify the approving actor’s authority and the requested scope independently of the model’s explanation. OWASP Authorization Cheat Sheet.
Consider a fictional receipts service using notices.example. Its business owner approves customer receipts, while the DNS administrator reviews a proposed provider-specific selector. That approval would not cover adding another tenant, redirecting reports to an agency or changing the parent domain’s DMARC policy. This example contains no actual provider values and does not demonstrate that an approval control exists or works.
Verify a real message before handing over
The planned acceptance test should use an authorized recipient and a message from the actual service, not only a DNS checker. Capture the sender identities, selected signature, trusted receiver-added authentication results and observed delivery disposition. Authentication evidence must be interpreted within the receiver’s trust boundary, rather than taken from any favorable header supplied with the message. RFC 8601, section 7.
A final SMTP acceptance is a transport handoff, not proof of inbox placement or successful business processing. Keep those outcomes separate. Handover should identify configuration owners, retained evidence, change dependencies, monitoring responsibility and the approved recovery route. An unresolved alignment result is a blocker to the stated acceptance criterion, not a reason to declare completion because the DNS value was saved. RFC 5321, section 4.2.5.
Commissioning evidence still required
Run one approved service through prerequisite checks, change preview, verification and handover. This exact requirement remains open. The workflow and map are documentary preparation. Actual service identity, current provider applicability, approval enforcement, executed change, real-message result and handover evidence must be collected before claiming that onboarding has been demonstrated.