FormAssembly SPF, DKIM and DMARC setup, step by step

FormAssembly custom sender domains need SPF authorization using include:spf1.formassembly.com. For branded DKIM on Essentials plans and above, contact FormAssembly Support with your instance URL, sending domain and an alphanumeric selector name. Complete sender-address verification too, then test a real notification, auto-response and workflow email separately. A verified sender or published key alone does not prove DMARC alignment. FormAssembly authentication requirements

This guide reviews public documentation; no customer account, DNS change or delivery test was performed.

Choose the email route before editing DNS

This guide covers emails sent by FormAssembly. A connector that triggers Salesforce or another service to send mail has a different sending system; configure that system's authentication instead of assuming FormAssembly's include authorizes it.

Workflow settings are copied from a form only once. Later changes to the form notification do not update that workflow step, or vice versa. This explains why one route can use a corrected sender while another continues to fail. Workflow Email Step

Keep the respondent's address separate from your authenticated sender. Use an address on a domain you control as Sender Email; put the respondent address in Reply-To where appropriate. FormAssembly does not authorize you to impersonate Gmail, Yahoo or AOL senders. Reply-To does not determine DMARC alignment. Notification and auto-responder settings

If the form instead triggers a separate Microsoft 365 sender, use the Microsoft 365 authentication guide for that route. FormAssembly’s sender verification and provisioned DKIM do not configure a different service.

Prepare the domain and account

Before making changes, collect:

• The exact instance, subscription, form and workflow owners.
• A controlled Sender Email mailbox and the intended visible From domain.
• Access to that domain's authoritative DNS, not simply the registrar account.
• Existing SPF, DKIM selectors and applicable DMARC policy, including policy inherited from an ancestor domain.
• A list of other legitimate senders and a DNS export for narrow rollback.
• Controlled external test inboxes and permission to submit non-sensitive test responses.

Choose a new DKIM selector that will not collide with another service. A selector is a name used to locate the public key; it is not the private signing key. Never publish a private key in DNS or a support screenshot.

Add FormAssembly to SPF without breaking other senders

FormAssembly requires its authorization in the custom sender domain's SPF before that sender can be verified; otherwise mail can fall back to no-reply@formassembly.com. Add this mechanism to the existing SPF policy before its final all mechanism:

include:spf1.formassembly.com

This is a mechanism, not a second standalone SPF record. Preserve every still-required authorization and the existing final qualifier. Do not replace an organization's Microsoft 365, Google Workspace or transactional-service permissions with a FormAssembly-only example. The vendor allows up to 48 hours for DNS changes to become visible to verification. SPF requirements

Publish at the exact domain being verified. For forms.example.com, an SPF record at example.com does not automatically apply. Check whether the DNS editor expects forms or the full name, and avoid an accidental forms.example.com.example.com owner.

SPF checks the SMTP envelope sender, usually shown as smtp.mailfrom by the receiver, not the visible From field. FormAssembly's domain-verification requirement and the receiver's SPF result are different checks. An include in your From domain cannot change a provider-owned Return-Path into your domain. SPF identity and evaluation

There must be only one TXT record beginning v=spf1 at an owner. Several quoted strings in a single TXT record are not necessarily several records. Count DNS-query-causing SPF terms across the evaluated include/redirect path: the limit is 10, not 10 visible includes. Resolve duplicate policies, syntax faults or obsolete authorizations before adding more. Do not manually flatten provider hostnames into today's IP addresses; that creates a stale list when the service changes infrastructure. SPF limits

If an existing SPF policy uses redirect=, preserve its intended authorizations and final semantics through a reviewed merge. Any all mechanism causes redirect to be ignored, so appending a canned policy or an all without reviewing that dependency can change which senders are authorized. SPF redirect semantics.

Request DKIM, publish the issued record and confirm activation

Contact Support with the instance URL, domain and your chosen single alphanumeric selector. FormAssembly documents eligibility from Essentials upward and a typical setup time of one to two days. Review Support Email, Bounce Email, Default Notification Email and Default Notification Sender in the relevant Admin Dashboard settings. DKIM provisioning

Ask Support to confirm the record type, fully qualified owner, complete public value or target, signing domain and activation step for this instance. Use exactly the issued values. There is no universal FormAssembly public key to copy from an article.

The public document does not expose a universal DNS payload or self-service activation button. If the response lacks these details, obtain them before editing. Do not generate an unrelated key in a third-party tool and expect FormAssembly to use its private counterpart.

For an issued signing domain such as news.example.com, a full owner SELECTOR._domainkey.news.example.com is SELECTOR._domainkey.news relative to the parent example.com zone, or SELECTOR._domainkey in a separately delegated news.example.com zone. If _domainkey.news.example.com itself is delegated, the relative owner there is SELECTOR. Replace the selector placeholder with the issued value, preserve the account’s exact type and public value, and publish at the actual authority without removing the NS delegation. This example explains name placement, not automatic product eligibility for a new domain. DKIM owner construction, relative DNS names.

For Cloudflare-hosted DNS, an issued authentication CNAME should be DNS-only and remain visible as a CNAME, not flattened to an IP response. This conditional safeguard does not mean this provider necessarily issues CNAMEs. Cloudflare proxy status · CNAME flattening

These controls apply only if Support explicitly issues a CNAME, not to an issued TXT key. For authentication records that actually use CNAME, retain a literal CNAME answer to the issued target and use DNS-only rather than HTTP proxying. Turn the relevant per-record Flatten setting off where available, and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are DNS-host behaviors, not assumed controls in the sending application. If mandatory behavior or shared settings cannot preserve the required CNAME answer, stop and coordinate a supported layout without breaking other services or removing shared NS delegations. Do not blindly disable features across the whole zone. Cloudflare verification guidance, flattening controls and limits.

Verify the sender address on each relevant route

Configure the auto-responder's Sender Email and complete its verification email. Links expire after 24 hours; verification is instance-specific. Until verification finishes, FormAssembly uses its fallback address. Trial and legacy-account restrictions differ, so check the account's actual sender controls rather than treating a display-name restriction as a DKIM fault. Sender verification and restrictions

For Workflow Email Steps, review Sender Email and Reply-To in the Configure tab. The workflow verification link also expires after 24 hours, while Reply-To does not require the same verification. Check every copied step rather than assuming a form-level change repaired the whole workflow. Workflow sender settings

Keep DMARC policy intact

DMARC passes when at least one authenticated identifier aligns with the visible From domain: a passing aligned SPF result or a passing aligned DKIM signature. Relaxed alignment compares organizational domains; strict alignment requires the same domain. A passing FormAssembly-domain signature is not branded alignment for example.com. Current DMARC standard, RFC 9989

Retain the existing applicable policy and reporting configuration. Do not change p=reject or p=quarantine to p=none just to complete FormAssembly setup. If no applicable direct or inherited policy exists, the domain owner can authorize a first monitored policy. Publish one TXT record at _dmarc for the chosen From domain, for example v=DMARC1; p=none, then add rua=mailto: only with an approved, operational reporting destination. The minimal record without reporting does not itself provide monitoring.

For a first policy at From example.com, the full TXT owner is _dmarc.example.com, entered as _dmarc relative to that zone. For From forms.example.com, use _dmarc.forms.example.com: _dmarc.forms in the parent zone or _dmarc in a separately delegated forms.example.com zone. Preserve existing inheritance and publish at the actual authority.

Use an approved report processor, satisfy external-destination authorization when needed, and review all legitimate senders before tightening policy. The pct tag is obsolete in RFC 9989; do not use it as a percentage-rollout control. Aggregate reporting is specified by RFC 9990; failure reports can disclose message information and need a separate privacy decision under RFC 9991.

Compare the Organizational Domain of the aggregate-report URI host with the Organizational Domain of the domain where the DMARC policy was found, not automatically the visible From domain. If they differ, the report-generating receiver must check the destination’s DNS authorization. A destination in the same Organizational Domain as that policy domain is excepted, even when its hostname differs. This protocol check does not replace the domain owner’s separate approval to share report data with that recipient. RFC 9990 section 4.

Validate DNS and delivered messages separately

These read-only commands use illustrative names. Replace the domain and selector with the issued ones; they are not records to publish.

dig +short NS example.com
dig +short TXT forms.example.com
dig +short TXT faforms1._domainkey.forms.example.com
dig +short CNAME faforms1._domainkey.forms.example.com
dig +short TXT _dmarc.forms.example.com

Compare authoritative answers with an independent recursive resolver. Expect one SPF policy at its correct owner and the exact issued public key or CNAME. An empty CNAME answer is normal for a TXT-only setup. If the direct DMARC answer is empty, inspect the applicable ancestor policy rather than assuming the domain is unprotected.

After Support confirms signing, submit a test response without personal or sensitive data. Save full headers from each internal notification, auto-responder and workflow step. In the receiving system's trusted Authentication-Results, inspect:

• header.from: your intended domain, not an unnoticed fallback.
• spf and smtp.mailfrom: authorization result and actual envelope identity.
• dkim=pass with header.d aligned to your From domain; compare the selector with the provisioned one.
• dmarc=pass for that From domain under its current alignment settings.

For this branded-DKIM implementation, require an aligned DKIM pass even if aligned SPF already makes DMARC pass. Record which route, instance, timestamp and recipient produced the evidence. A vendor badge cannot substitute for receiver authentication, and successful authentication cannot guarantee inbox placement.

Use only authentication results from the receiving system’s trusted boundary; an arbitrary sender-supplied header is not proof. Authentication-Results trust model, RFC 8601

Use receiver-controlled diagnostic output, or have the receiving administrator establish which fields were generated inside its known processing boundary and document how externally supplied Authentication-Results are removed or distinguished. A familiar authserv-id string or header position alone does not establish provenance. Ignore attacker-inserted or otherwise untrusted results, including a forged field naming the expected receiver. Operational receiving-boundary requirements.

Investigate an actual SPF fail, permerror or temperror even when aligned DKIM makes DMARC pass. DKIM success does not repair a broken SPF policy. First distinguish that error from an ordinary SPF pass on an unaligned provider envelope domain, then apply the corresponding diagnostic below.

Troubleshoot the failed layer

For escalation, share the instance, route, redacted headers, DNS owner/type and timestamps through an approved support channel. Avoid sending full form responses or private keys. If rollback is necessary, reverse only the failed change and preserve other senders' records and the established DMARC policy.