Ask questions that can be answered with evidence
An enterprise authentication questionnaire should connect business requirements to supported behavior, operating responsibility and acceptance evidence. A long list of yes-or-no feature questions can conceal important limitations: a supplier may support a broad category while not supporting the specific tenant, lifecycle or deployment behavior the buyer needs. The questionnaire should therefore ask what is supported, under which configuration, who operates it and how the answer can be verified.
This article proposes a questionnaire structure and does not state that EmailAuth implements any listed capability. No supplier was contacted and no questionnaire response was obtained. Microsoft's shared-responsibility guidance and Azure's multitenant identity guidance provide official examples of distinctions that matter, but they cannot substitute for current evidence from the product being evaluated.
Start with scope and decision ownership
Record the proposed customer population, domains, sending workflows, deployment option, required integrations and intended administrators. Identify which requirements are mandatory, which are preferences and which need a qualified legal, security or commercial reviewer. A questionnaire without a defined scope can produce answers that are technically true for a different edition or environment. Preserve the product version and offer reference alongside each response.
Ask the supplier to distinguish implemented support, configuration-dependent support, planned work and unsupported requirements. Do not turn a roadmap date into current capability. Where a response depends on another service, identify that dependency and the responsible party. The buyer should also document its own obligations; a supplier cannot demonstrate a complete workflow if required customer DNS, identity or access decisions remain undefined.
Cover identity, roles and tenant boundaries
Ask how users authenticate, how identities are bound to tenants and how permissions are assigned to domains, reports, exports and administrative operations. Azure's identity guidance distinguishes authentication from role-based or resource-based authorization and commercial entitlements. Reflect those distinctions in separate questions. A statement that SSO is supported does not establish customer isolation or the effect of a role reduction on an existing session.
Include questions about service identities, user lifecycle, supplier support access and audit evidence. Require a current explanation of disablement and revocation behavior rather than assuming that a provisioning integration handles every access path. Ask for authorized synthetic negative tests demonstrating that one tenant cannot read, export or change another tenant's resources. A product screenshot or role list alone does not provide that evidence.
Ask how authentication observations are obtained
Document which sources the platform ingests, how their coverage is described and how unsupported or missing observations are represented. RFC 9990 defines DMARC aggregate reporting, which has its own report-discovery and delivery process. A platform's ability to parse reports does not guarantee that every receiver sends them or that every legitimate sender is represented in a period.
Ask how the product preserves original report provenance, handles duplicates and explains interpretation limits. If it combines provider delivery events with authentication reports, ask what identifiers permit linkage and whether conclusions are message-level or stream-level. Do not request a universal delivery guarantee from authentication data. The questionnaire should make the product's observation boundaries visible rather than encourage unsupported claims of complete coverage.
Clarify deployment and operational responsibilities
Ask which deployment options are currently supported and what each includes. Define who patches infrastructure, updates the application, manages identities, monitors ingestion, performs recovery and handles incidents. Microsoft's shared-responsibility framework illustrates why obligations vary by service model, but the actual supplier must provide its own supported allocation. A response marked shared should describe the handoff and verification owner, not merely divide a checkbox between two parties.
For private or dedicated options, ask about network paths, data handling, support access and external dependencies separately. Do not infer isolation from an architecture label. Require evidence for the relevant boundary and transparent workload assumptions for sizing. The questionnaire itself should not authorize a deployment, firewall change or data transfer; those actions require separate approved implementation work.
Include data handling and audit requirements
Ask what data is retained, where supported configurations place it, who can access it and how retention, deletion and export operate. Distinguish primary data, logs, backups and support artifacts. This article does not make a legal compliance determination or assert a vendor's residency behavior. The appropriate qualified owner should review contractual and regulatory requirements using current evidence.
For auditability, ask which actions are recorded, whether denied attempts are included, how actor and tenant context are represented and who may export or alter retention settings. Microsoft Entra audit-log documentation is an example of an official activity-log description, not proof of another product's coverage. Require product-specific samples and limits rather than accepting the word audit as a complete answer.
Make workload and commercial assumptions transparent
State the expected domains, tenants, users, report volume, retention and integration cadence using approved organizational inputs. Mark estimates and unknowns clearly. A partial month of observations may not support an exact annual workload prediction. Ask the supplier which variables affect the quote and how changes are counted, but do not infer prices or package inclusions from technical documentation.
Keep commercial inclusion separate from technical acceptance. A feature may be included in an offer but still require configuration and evidence; a demonstrated feature may be outside the proposed package. Record quote validity, scope and exclusions only when an approved quote exists. No price, discount, cost model or procurement recommendation is produced by this manuscript.
A requirement-and-evidence worksheet
Create columns for requirement, business reason, priority, supported configuration, supplier response, evidence source, reviewer, acceptance test, limitation and decision. Add an assumption register with input, source, date, confidence and impact if wrong. Link each mandatory requirement to a concrete evidence item rather than a broad marketing page. Retain unanswered questions as gaps instead of interpreting silence as support.
For testable controls, describe the authorized fixture and expected result. For contractual commitments, identify the relevant approved agreement. For operational responsibilities, identify the named owner and handoff. These evidence types can complement each other but should not be substituted indiscriminately. A contract can allocate responsibility without demonstrating a technical test; a successful test can show behavior without creating a support commitment.
Fictional diagnosis: a complete-looking questionnaire
A fictional buyer receives affirmative answers for SSO, exports, private deployment and audit logs. The review initially marks the questionnaire complete. A second reviewer asks which edition supports those features, whether exports preserve tenant boundaries and what happens to an active session after disablement. The original answers do not resolve those questions because they describe categories rather than outcomes.
The proposed response is to request scoped evidence and leave the affected requirements open until reviewed. The buyer need not accuse the supplier of misrepresentation; the questionnaire may simply have been too vague. This scenario is fictional and does not describe any actual supplier response or product gap. No external communication or test was performed.
Publish the gaps with the recommendation
A useful assessment identifies supported requirements, accepted limitations, unresolved evidence and workload assumptions that could change the decision. It should be readable by both technical and business owners without collapsing their different responsibilities. Avoid a numerical score that implies precision beyond the evidence unless its method and limitations are explicitly approved.
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, accessibility and owner release also remain open. This draft supplies a framework and fictional exercise, not completed vendor due diligence or an assertion of EmailAuth capabilities.