Anyone can inspect public authentication records. That ability must not grant access to a customer's reports or administration console. A domain onboarding process needs evidence of authority, a defined scope and a way to withdraw access when the relationship changes.
Define what the claim means
Distinguish legal ownership, control of DNS, authorization to act for a customer and permission to use a service. A DNS challenge can demonstrate control of a record at a point in time. It does not by itself establish legal title, the applicant's employment or authority over every subdomain and associated customer account.
For an MSP, confirm the requesting organization and delegated authority through the customer agreement and designated contacts. Record the exact domain, tenant, purpose and access being requested. Use an independent customer approval path for disputes or transfers. Do not automatically merge tenants merely because they claim the same domain.
Bind and limit a challenge
An illustrative design issues an unpredictable challenge bound to one domain, tenant, claimant and expiry. Check the expected authoritative evidence, preserve the observation time and invalidate the challenge after successful use. Avoid accepting a token from another domain or a previous onboarding attempt. This is a recommended design, not a protocol requirement or claim about EmailAuth implementation.
Require an authenticated identity before starting the claim, then authorize every subsequent access independently. OWASP's authorization guidance calls for default denial and permission checks on every request. Successful domain verification should establish only the permission explicitly approved, not administrative authority over unrelated tenants or historical report archives.
Test rightful claims and adversarial cases
Suppose a new agency can publish the requested DNS challenge but seeks access to reports collected for the previous agency. The DNS observation supports current control of that record; it does not authorize access to the earlier tenant’s archive. Keep archive access on hold until the customer approves the specific data and recipient through a verified independent path.
Separately, test an otherwise valid challenge under the wrong tenant, after expiry and after successful use. In this proposed design those cases should be rejected while a valid scoped claim should proceed to the separately required authority and permission checks. These are hypothetical expected decisions, not supplied tokens, DNS observations or executed tests. Verify real challenge generation, authoritative lookup, caching and service authorization in an approved test environment.
Handle transfer and revocation explicitly
Domain sale, agency changes and employee departure require different actions. Freeze disputed changes while checking authority with verified contacts. Preserve old and new claim evidence without exposing the previous customer's reports to the new claimant. A new controller of DNS should not automatically inherit historical tenant data.
Revoke access at the service layer, including active sessions, background jobs and scoped credentials as applicable. Deleting a DNS challenge is not a substitute for withdrawing permissions. Review any ongoing data collection separately so revoked users cannot continue exporting or receiving reports.
Accept the right evidence
Close onboarding only when the authority check, scope approval, identity provisioning and negative access tests are complete. Record who approved the relationship and which access was granted. Revalidate after material ownership or service changes. A strong verification process produces a bounded authorization decision and recoverable audit history, not a permanent claim that one person owns a domain forever.