Translate private deployment into specific requirements
A request for a private deployment can mean several things: isolated infrastructure, private network connectivity, a dedicated application instance, restricted administration, a particular data location or customer-operated software. These are different requirements. A supplier cannot demonstrate all of them by showing a private IP address or a dedicated tenant label. Begin by stating which boundary matters, what threat or obligation motivates it and what evidence would show that the boundary is enforced.
This article proposes a requirements method. It does not claim that EmailAuth supports private endpoints, dedicated deployments, customer-managed infrastructure or any particular architecture. No deployment, network configuration or access change was performed. Microsoft's shared-responsibility guidance supports distinguishing service models and retained responsibilities, but the actual product's supported arrangements still need direct evidence.
Separate network reachability from data isolation
A private network path controls how a client reaches a service; it does not by itself establish which tenant's data that client may access. Azure Private Endpoint documentation describes a network interface using a private IP address to connect privately to supported services through Azure Private Link. That is an Azure-specific capability and should not be generalized to an unsupported product or treated as proof of application authorization.
Write separate requirements for network ingress, public exposure, tenant authorization and administrative access. Ask whether public connectivity remains possible and how the actual service controls it, rather than assuming creation of a private endpoint disables every public path. Record the supported DNS resolution and connection-approval behavior for the actual deployment. No endpoint was created or queried here, and no security setting was changed.
Identify required data paths and dependencies
Map how reports, provider events, users and integrations would reach the proposed deployment. A network-isolated service may still need approved outbound connections, inbound report collection or access to external identity and DNS systems. Treat each path as a requirement to be supported, not an implementation detail to discover after purchase. Record the data type, direction, purpose, owner and permitted destination for each dependency.
RFC 9990 defines the DMARC aggregate-reporting process. A deployment's private network placement does not make reporting receivers aware of an internal-only collection address or guarantee report coverage. The design must account for the actual supported report-delivery path and any approved intermediary. This draft does not propose exposing a service publicly or bypassing a network restriction; it identifies a compatibility question that the supplier must answer.
Define identity and administrative boundaries
Azure's multitenant identity guidance separates authentication, resource authorization and commercial entitlements. Apply that distinction even if the deployment serves only one organization. Different teams, customers or administrators can still require different access. A private network is not permission for every connected user to read raw reports, export data or change authentication policies.
Ask how user lifecycle, service identities, support access and emergency administration are controlled and audited. Specify whether supplier personnel may access the environment and under what approved process. Do not infer that a dedicated instance excludes all supplier access or that customer hosting eliminates the need for product support. The actual supported controls, not the deployment label, must establish the boundary.
Specify data location and handling precisely
If location matters, identify which data classes the requirement covers: primary records, backups, logs, support artifacts, telemetry and exported files may follow different paths. Ask for current documented behavior and contractual scope rather than assuming that selecting a region covers every copy. This article makes no legal determination about residency or compliance and does not assert any vendor's data location.
Define retention, deletion and recovery requirements separately. A short interface retention period does not necessarily describe backup retention, and a deletion request does not prove all copies were immediately removed. Require the supplier to explain supported behavior, limitations and evidence. Any legal or regulatory interpretation should be reviewed by the appropriate qualified owner. No customer data was collected or moved during this work.
Make operations and workload assumptions visible
Record who supplies infrastructure, manages updates, monitors health, handles incidents and performs recovery. Microsoft’s shared-responsibility model illustrates why these obligations differ by service model, but it cannot replace the actual operating agreement. If a private option requires customer-run components, the buyer must have an owner and capacity for them. If the supplier runs them, the buyer still needs evidence of its retained configuration and access duties.
Document expected domain counts, tenants, reporting volume, retention, integration frequency and availability needs as assumptions for sizing and pricing discussions. Do not invent a workload or convert an incomplete reporting sample into a precise infrastructure requirement. Mark unknowns and state how they will be measured through an authorized process. This draft contains no cost estimate, deployment sizing result or benchmark.
A requirement-and-evidence worksheet
Create rows for deployment boundary, supported product option, network paths, identity, tenant isolation, data handling, operations, recovery and support. Each row should include the business reason, required outcome, supplier evidence, test method, responsible reviewer and acceptance status. Add transparent workload and cost assumptions with their source and date. A requirement marked not supported should remain visible rather than being recast as a roadmap commitment.
For network requirements, distinguish the actual service capability from the cloud primitive it might use. A cloud provider offering private endpoints does not prove that a SaaS supplier exposes a compatible endpoint. For data requirements, distinguish contractual promises from observed technical behavior. Both can matter, but they answer different questions. No row should be marked passed until the required evidence exists.
Fictional diagnosis: private connectivity without report ingress
A fictional buyer requests an internal-only authentication platform and focuses its evaluation on administrator access through a private network. The review later asks how externally generated aggregate reports would reach the supported ingestion path. The proposed design has not documented that dependency, so the network demonstration does not establish a workable end-to-end operation.
The team would ask the supplier for a supported collection architecture and assess its data and access boundaries before approving deployment. It would not open a firewall or create an unapproved public endpoint simply to make the demonstration work. This scenario is fictional; no actual product limitation, network test or report-delivery failure was observed. It shows why private deployment requirements need a dependency map as well as an isolation goal.
Accept only the supported scope
A useful readiness conclusion states which private-deployment requirements are supported now, which depend on customer work and which remain unresolved. It should not imply that a private option is automatically more secure, compliant or reliable than a managed alternative. The decision depends on evidence and ownership, not a label.
The catalogue requires a requirement-and-evidence matrix and transparent workload or cost assumptions. Those original artifacts remain open. Human specialist review, source applicability, production routes, visual accessibility and owner release also remain open. This draft supplies proposed questions and a fictional exercise, not an architecture, benchmark, quote or deployed environment. Publication requires current product-specific evidence and authorized validation of the chosen boundaries.