Separate email identity from document authority
Zoho Sign's Email Domain Verification guide describes Settings > Account settings > Email domain verification status > Verify now. Enter the domain and select Generate Key to obtain a hostname and value. Publish the generated TXT data, continue through Next, then select Verify Domain. The guide says to retain the record while using that address in Sign. Zoho Sign verification
This is an email-authentication workflow. It should not be described as verifying a signer's legal identity, approving a contract, or establishing that an envelope was authorized by the business. Those decisions have separate evidence and approval requirements. A valid notification signature can coexist with an unauthorized or mistaken document request.
The proposed scope should identify the Sign organization, account region, edition, intended notification sender and business owner. The public documentation does not establish the configuration of a real tenant or prove that every notification category uses the same identity. Current-account and operational acceptance therefore remain open.
Confirm the custom-domain prerequisite and application boundary
The Sign FAQ says this feature requires a custom domain and recommends the default Sign notification address otherwise. It also says a domain verified in another application still needs separate verification in Zoho Sign. DKIM FAQs
Do not treat a successful CRM, mailbox or other application status as proof that Sign is ready. The proposed inventory should connect each application with its own generated configuration and acceptance evidence. A shared corporate domain can have several legitimate signing selectors, each with a different lifecycle owner.
Before selecting a custom notification identity, confirm that the organization controls the domain and that its communications owner approves the visible sender. A user of a public mailbox service cannot authorize that service's domain merely by possessing an address. If the default sender is retained, document that decision clearly rather than presenting it as custom-domain authentication.
Review the issued TXT record as a dependency
A DKIM verifier uses the selector and signing domain from the message to locate public-key data. Record the exact generated owner name, type and complete value, together with the account and change request. An example in documentation is not a universal selector and does not justify overwriting another application's key.
The proposed DNS review should identify existing records at the same name, active notification routes and any planned key transition. Retain a recoverable before-state and designate the administrator authorized to publish the change. Do not remove a key immediately after a single successful verification screenshot; active or queued notifications may still rely on the configuration.
The public key is appropriate configuration evidence. Private signing keys, account passwords and authentication tokens are not part of the routine worksheet and should not be collected or sent to a general support thread. The review is about the public dependency and observed message identity, not possession of the provider's secrets. RFC 6376, section 3.5; RFC 6376, section 3.6.2.2
Resolve DNS name representation deliberately
The Sign FAQ highlights duplicate domain suffixes as a troubleshooting issue. Interpret that warning in the context of the actual DNS editor rather than making a universal rule that every full name must be shortened. Verification troubleshooting
Some interfaces append the zone automatically; others allow an absolute name. The administrator should compare the intended fully qualified lookup name with what the editor will publish. A saved form field is not conclusive evidence of the final DNS name. In master-file notation, a standalone @ denotes the current origin, not a wildcard for every subdomain.
Preserve the complete key value as well. TXT records may contain multiple character strings within one record; that is different from several independent records. A long value should not be truncated to satisfy an assumed interface limit. If verification fails, compare the exact owner name and logical data before regenerating keys or changing unrelated email policies. RFC 1035, section 5.1; RFC 1035, section 3.3.14
Verify the notification, not the document’s legitimacy
The proposed received-message acceptance records the author domain, DKIM signing domain, selector and trusted receiver authentication results for an authorized representative notification. DMARC then evaluates alignment between the author domain and a passing authentication identity. A provider configuration badge is useful context, but it does not replace this message-level evidence.
Keep the evidence sample tied to a specific route and time. An earlier notification using the default sender cannot prove that a newly selected custom sender is aligned. Conversely, a custom-domain sample does not establish every reminder or completion-message path unless the scope has been demonstrated.
Do not use an authentication pass to approve a document, payment instruction or change in signing authority. Review unexpected requests through established business channels and the organization's document-control process. Email authentication establishes a narrower domain relationship, not the safety of the request or the legal effect of signing it. No contract submission, signature or legal commitment is authorized by this guide. RFC 9989, section 4.4; RFC 9989, section 2.4
Acceptance worksheet for document operations
Use this original proposed worksheet to keep notification setup separate from consequential document actions.
- Account scope: Sign organization, edition, region and notification categories included in the review.
- Sender decision: custom-domain or default notification identity, with the communications owner's approval.
- Application boundary: Sign-specific domain verification evidence, not a status copied from another product.
- DNS request: exact generated hostname, public value, existing-record comparison and change owner.
- Lifecycle: active dependencies, queued-message considerations and a reviewed retirement or rollback plan.
- Message evidence: minimized authorized headers, observed domains, trusted validation and alignment assessment.
- Document authority: the separate business process used to approve envelopes, signers and material requests.
- Release: named reviewer, remaining tenant or applicability gaps and explicit production approval.
The worksheet is not an executed test. It contains no real documents, signer identities, private keys or completed envelope actions. No DNS publication or account change has been performed for this manuscript.
Fictional diagnosis: a valid email carrying an unexpected request
A fictional procurement team receives a signing notification with a familiar organization name. Its email authentication checks pass, and an employee assumes that the revised bank details in the associated document must therefore be approved. The technical evidence does not establish that business conclusion.
The proposed response separates two questions. The messaging reviewer records the notification's actual author and signing domains, while the procurement owner verifies the document request and financial changes through the established approval process. Nobody signs the document or changes payment instructions merely to complete an email-authentication test.
In a separate configuration review, the team confirms that Sign's domain verification is not inferred from another application's status. The final record identifies both the technical evidence and the still-required business approval. This scenario is fictional; it does not allege a real compromise or report a tested Zoho Sign account.