Define the notification routes before touching DNS
Zoho Forms documents DKIM under Setup > Control Panel > Notification Settings > DKIM Configuration. After the prerequisite domain verification, add the domain, choose a supported key size, and obtain its generated hostname and value through View details. Publish the TXT data and select Verify; the documented status changes from Pending to Verified. Forms DKIM configuration
The proposed scope begins with the organization, edition, account region and forms whose notifications use the domain. Distinguish messages to internal administrators from messages to respondents. A successful submission and a generated notification are application events; neither establishes which transport or author identity was used to deliver the message.
This article describes configuration requirements and an original acceptance plan. It does not claim that any form, tenant, DNS zone or recipient mailbox has been tested. The current-account and broader catalogue evidence requirements remain open until an authorized implementation review supplies the missing observations.
Include custom SMTP and fallback in the inventory
The Forms SMTP guide describes Settings > General > SMTP in the form builder, enabling Custom SMTP and selecting an existing server. It says SMTP delivery problems can route mail through the default server. It also links signing with the verified domain matching the sender's domain. DKIM & SMTP
A fallback is therefore a material acceptance boundary. The proposed inventory should contain the intended primary transport, the documented fallback possibility and the identities expected on each path. Do not assume that a form's nominal SMTP selection proves the path used by a particular notification.
Plan any operational testing in a controlled, separately approved environment. Do not deliberately break a production SMTP service just to trigger fallback, and do not transmit real respondent data as a diagnostic convenience. A safe evidence plan can begin with configuration review and existing authorized samples, while clearly leaving unobserved fallback behavior open.
Treat domain and key selection as managed configuration
The generated key belongs to a particular signing-domain configuration. Record its exact lookup name and public value, along with the account and requested change. The signature's selector and signing domain determine which key a verifier needs; a screenshot from another domain is not a replacement for the account's actual data.
Review key-size choices against the organization's current cryptographic requirements and provider support rather than treating an old example as a universal security recommendation. A DNS interface that displays a long TXT value awkwardly does not justify truncating it. TXT data may contain multiple character strings within one record, and applications can interpret those strings as the required complete value.
Before replacing an existing key record, identify other forms or active services that may rely on it. The proposed change plan should protect scheduled notifications and document the rollback decision. Private keys and SMTP passwords do not belong in the public configuration worksheet or a general-purpose support attachment. RFC 6376, section 3.5; RFC 6376, section 3.6.2.2; RFC 1035, section 3.3.14
Map DNS editor fields to the final lookup name
A common configuration risk is confusing a relative owner label with a fully qualified domain name. The administrator should establish how the actual DNS editor handles the zone suffix and then compare the intended final lookup name with the published result. No single rule about removing or retaining a suffix applies to every interface.
In DNS master-file notation, standalone @ denotes the current origin. It is not a shorthand for all subdomains, and a provider's visual root field should not be interpreted as wildcard authorization. For DKIM, preserve the selector label, the _domainkey component and the intended signing domain as one complete name.
The proposed acceptance evidence should show the exact name and record data, not merely a green save notification in the editor. If the provider cannot verify the configuration, compare the intended owner, zone and complete value before regenerating keys or introducing unrelated SPF changes. RFC 1035, section 5.1; RFC 6376, section 3.5
Evaluate authentication for the actual notification identity
Forms also documents using its default domain when the sender address lacks an authenticated domain. This makes the actual author and signing identities important evidence, not details that can be inferred from a form title or organization logo. SMTP notes
For an authorized representative notification, record the visible From domain, DKIM signing domain and selector, and trusted receiving-system results. Compare the passing identity with the author domain under the applicable DMARC alignment mode. If a custom SMTP path is used, identify the responsible provider's authentication requirements rather than assuming Forms' generated DNS data configures that separate service.
Do not confuse the recipient's submitted address with the authorized sending identity. A respondent can supply an email address without granting the form operator control of that address's domain. The proposed review should ensure that notification design does not make unsupported assumptions about domain ownership.
Passing authentication remains narrower than safe form content, inbox placement or proof that a respondent saw a confirmation. Treat those as separate acceptance objectives. RFC 9989, section 4.4; RFC 7208, section 2.4
Acceptance worksheet for form owners
Use this original proposed worksheet for notification classes rather than assuming one form setting covers every possible message.
- Form scope: organization, form identifier, edition, region and notification audience.
- Sender design: intended author domain, reply destination and business approval for any default-domain substitution.
- Primary transport: built-in or custom SMTP, responsible service owner and existing configuration reference.
- Fallback boundary: expected alternative path, evidence available and any behavior that remains unobserved.
- Domain configuration: generated key name/value, selected key-size review and DNS owner approval.
- Verification: actual product status and timestamp, separate from evidence that a particular notification was sent.
- Message review: minimized authorized headers, observed domains, trusted validation and alignment assessment.
- Data protection: synthetic or minimized content, restricted evidence access and retention owner.
- Release: unresolved production questions, reviewer and a continuity plan for scheduled notifications.
This is a planning artifact. It records no real submissions, SMTP credentials, DNS queries, fallback tests or tenant changes.
Fictional diagnosis: a notification took the fallback route
A fictional training organization selects a custom SMTP server for registration confirmations. Later it receives a sample with a different author or signing identity than expected. The form administrator proposes replacing the Forms DKIM record because the message looks different from an earlier example.
The reviewer instead asks which delivery path produced the sample and whether a fallback occurred. The proposed investigation compares the configuration reference, message time and observed identities before touching a working key. It also separates the administrator notification from the respondent confirmation, because their settings and evidence need not be identical.
The team leaves fallback acceptance open until it has appropriate authorized evidence. It does not intentionally interrupt production delivery or export real registration data to demonstrate the theory. This scenario is fictional and is not a report of a Zoho Forms failure or an executed test.