Inventory notifications before changing DNS
A form can produce an internal notification, an auto-responder and a workflow email. Give each a row in the change plan: form or workflow name, triggering event, intended recipient, From address, Reply-To, business owner and expected transport. Do not assume that a test of one form establishes the identity of every email-producing step.
Use a sending domain your organization controls. A respondent's address can be useful for directing replies, but your domain setup does not authorize you to authenticate an unrelated respondent domain. Decide explicitly whether the form should send as your organization and direct replies elsewhere. Test with controlled addresses and fictitious response data rather than personal submissions.
Meet FormAssembly's sender requirements
FormAssembly's authentication guide requires custom sender domains to include its SPF authorization, include:spf1.formassembly.com. Domains lacking that authorization fall back to no-reply@formassembly.com until verified. DKIM is support-assisted for Essentials plans and above: provide the instance URL, domain and a single alphanumeric selector name. Review Support/Bounce Email under General and Default Notification Email/Sender under Miscellaneous in the Admin Dashboard. Source: FormAssembly, Email Notification Security and Authentication.
Before editing SPF, retrieve the existing policy and inventory all legitimate services using that owner name. Add the needed authorization to one policy, not a second v=spf1 TXT record. Preserve other senders and check the total DNS-lookup-dependent terms, including nested includes. Do not copy a complete sample policy from another organization or change its final qualifier without reviewing the consequences for all mail.
A selector request is not the public key itself. Obtain the final record type, full owner, value and activation instructions from FormAssembly support for this instance. Preserve their response as the configuration authority; never invent a public key or copy one from a third-party tutorial. Give the DNS owner only the records needed for this change and record who will confirm activation. Support setup and DNS caching have separate timing, so neither should be hidden under a generic propagation wait.
Validate sender choice and signing separately
After publishing, query the authoritative servers for the actual record owner and type. Confirm that the DNS editor did not append the zone twice, lose part of a key, or introduce a conflicting alias. Compare the final answer with the instance-specific instructions. If the authoritative answer is wrong, waiting longer will not fix it.
Trigger a controlled submission and inspect the received notification and auto-responder independently. Save the original messages and trusted receiver authentication results. Record visible From, Reply-To, envelope identity and DKIM signing domain/selector. Reply-To routes responses; it is not the domain DMARC uses for alignment. Confirm that any fallback sender is acceptable to the business owner rather than silently treating delivery as success.
Synthetic acceptance case: the internal notification has From forms@example.com and a valid signature with d=example.com. Its receiver reports DKIM pass, giving an exact aligned DKIM path. A different auto-responder using From visitor@another.example is not authenticated for that unrelated domain merely because the same form generated it. The correct response is to review sender configuration, not to add more SPF includes to example.com.
Separate product prerequisites from protocol results
The provider's requirement for SPF is a product setup condition. SPF itself authenticates the envelope sender identity, while DKIM verifies a signature associated with d=. DMARC compares the successful authentication identity with visible From under its alignment mode. Passing a product verification check is therefore not a substitute for recording the domains from a delivered message. Avoid describing a DKIM signature as encryption or claiming authentication guarantees inbox placement.
If one workflow still fails, compare its settings and received headers with a working workflow. An absent signature suggests an activation or route issue; a signature that fails verification calls for key and message-integrity investigation. If authentication passes, inspect the actual delivery error and recipient handling before changing DNS. Do not repeat live submissions indiscriminately or resend genuine customer information as test data.
Retain a recovery path and acceptance record
Save the previous sender settings and DNS policy before changes. If a custom identity is not ready, use an approved known-working sender arrangement while support resolves the issue. Do not remove other services' records or weaken the entire domain's DMARC policy to conceal a form-specific problem. Test reply handling after any sender change.
Accept the work only when the intended forms and workflow steps show the approved From and reply identities, authoritative DNS matches the supplied values, and received messages show a passing aligned path. This article supplies documentary instructions and synthetic reasoning, not live test evidence. Its original catalogue requirement for real message or DNS verification remains open until an authorized operator supplies those results; human review and publication are not implied.
Keep the form owner separate from the respondent
Written case FA-02 assumes a form should send as forms@example.com and direct replies to a controlled visitor@other.example address. The stipulated internal notification has trusted DKIM pass with d=example.com and s=forms1, giving exact alignment for its From. A second route instead has visible From visitor@other.example; its envelope and all signatures are unknown. That second route has no established authentication verdict and cannot borrow the first route’s result. The form owner should review its sender and Reply-To settings before an authorized fictitious submission. No respondent data, form submission, DNS change or support request was used.
Preserve the enforcement boundary
RFC 9989 Section 7.4 requires valid DKIM, not SPF alone, for domains publishing p=reject, and warns about indirect-mail and mailing-list interoperability. A single successful direct-message test is not proof that every legitimate route is ready for stronger policy. Keep existing approved protection while diagnosing the actual gap; any policy change needs its own decision.