Turn a capability label into a testable question
Buying an authentication service requires more than recognizing feature names. A buyer needs to know whether the relevant product version can perform a particular task with the intended inputs, permissions and operating constraints, and what evidence it leaves behind. This guide proposes questions and acceptance records for evaluating EmailAuth. It does not certify that EmailAuth currently provides any listed function, integration, deployment mode or service outcome.
A fresh read of the EmailAuth public homepage on 8 November 2026 found vendor descriptions and customer-oriented marketing. That establishes what the page displayed, not current plan entitlement, independently demonstrated performance or permission to repeat customer claims. No approved capability register, account access or representative product test was supplied for this article. Treat every proposed evaluation below as unanswered until supported.
Specify the buyer's task before the demonstration
Replace a broad requirement such as visibility with an observable question: can an authorized analyst identify the source of a selected result and export the supporting evidence without gaining access to unrelated tenants? Define the intended domain population, input format, reporting period, operator role and expected output. Record the product version, deployment configuration and any paid entitlement needed for the task.
A capability register should distinguish available and demonstrated, documented but untested, planned, unsupported and unknown. Those are different states. A roadmap date is not current availability; a demonstration in another environment is not acceptance in yours. Request the limitation that would change the purchase decision, including scale, retention, export completeness, dependency on professional services and behavior when inputs are incomplete.
Test correctness with interpretable fixtures
Prepare authorized representative inputs and expected outcomes before viewing the result. For aggregate reporting, include a normal report, a duplicate, a late report, an ambiguous sender and a document that should be rejected safely. RFC 9990 supplies reporting semantics and security considerations, including duplicate handling and hostile input. A parser accepting a file is not enough: the displayed interpretation must preserve the relevant provenance and explain any discarded content.
For authentication explanations, ask the demonstration to distinguish raw SPF or DKIM success from DMARC alignment. RFC 9989 is the current core specification, while actual product and receiver adoption must be verified separately. A legacy interpretation should be identified as such. Do not assume that a recently updated page proves a current implementation or that a green indicator proves message delivery.
The proposed fixtures are a test design, not completed tests. Production reports may contain information that needs specific sharing permission. Start with approved synthetic material when appropriate, then determine whether a separately authorized representative-data trial is needed. Never invent a successful result to fill a missing evidence row.
Verify permissions and observable actions
Evaluate access separately from analytical accuracy. Can a reader view only approved domains? Can an administrator delegate an appropriate role without exposing other tenants? Does a revoked user lose access through exports and interfaces as well as the main screen? These are proposed questions, not descriptions of EmailAuth controls.
OWASP authorization guidance recommends least privilege, default denial and permission checks for each request. Use that guidance to design positive and negative acceptance cases. A screenshot of role names does not establish enforcement. Require an authorized test environment, defined identities and reviewable results without testing another customer's resources.
If a capability can modify DNS, credentials or policy, separate preview from execution. The evidence should identify the exact resource, change, approver and resulting state. An interface accepting a request is not proof that the requested operation completed. Record partial failures, stale configuration, interrupted jobs and recovery behavior. Capability evaluation does not grant permission for real changes, and security-sensitive actions need their own authorized procedure.
Include the people and dependencies
Ask who performs onboarding, investigations, exception review and maintenance. If a demonstration succeeds only because a specialist prepares the input beforehand, include that effort and prerequisite in the result. Distinguish a software function from a managed service commitment. Confirm support responsibilities and escalation arrangements through approved commercial evidence rather than inferring them from a helpful demonstration.
A fictional evaluation asks whether an analyst can explain a disputed authentication result. The acceptance record would capture the supplied report, the product's answer, source linkage, analyst corrections, total hands-on time and unresolved ambiguity. If a reviewer supplies the missing sender identity, the outcome must credit that human contribution. No such evaluation has been run here, and no timing or accuracy result is claimed.
Check dependency behavior as well. Determine whether losing the dashboard affects only investigation or also live DNS, signing or reporting. Verify how data can be exported and interpreted independently. A successful trial should leave enough evidence for another reviewer to reproduce the reasoning without trusting a sales presentation.
Approve exact claims rather than an entire impression
Bind each proposed public statement to a dated evidence item, product scope, limitation, accountable owner and next review trigger. Customer categories, names, quotations and outcomes require their own approved supporting material. Do not reuse an attractive website testimonial as permission or proof. The FTC's advertising substantiation policy is a useful United States reference for supporting objective claims before dissemination; local legal review remains separate.
The commissioning instruction is explicit: Attach approved product proof and customer-claim permissions; otherwise omit the claim. That gate remains open. The article therefore offers an evidence checklist and proposed acceptance map, with no feature entitlement, security certification, integration, customer result or service guarantee asserted as fact. A buyer can use the unanswered questions to organize due diligence while the product owner supplies current, reviewable answers.