For Formstack Forms notifications and confirmations sent through your own mail provider, SPF and DKIM belong to that outbound provider's domain configuration. Formstack's connection screen is not a native DNS-record generator. First verify the existing sending domain and signing service, then connect the approved Google or Microsoft 365 account and test actual form messages.
This guide covers the account-wide external-mail connection in Formstack Forms. It excludes Formstack Documents, formerly WebMerge, and Formstack's default sending infrastructure. It does not claim that a universal Formstack SPF include or DKIM selector exists for this route.
On this page
- Decide whether this route is appropriate
- Verify upstream SPF and DKIM first
- Connect the approved account
- Understand the account-wide sender
- Test before relying on the connection
- Interpret SPF, DKIM and DMARC correctly
- Troubleshooting and FAQs
Decide whether this route is appropriate
Changing the sending connection is a routing decision, not merely adding an authentication record. Establish who owns the account, which forms send notifications or confirmations, who receives them, and whether their data may be processed through the proposed mail provider. Get approval for the account-wide change and agree a controlled testing window and recovery plan before enabling it.
This is not a per-form experiment that leaves every other form untouched. Inventory business-critical confirmations, internal alerts and forms handling confidential submissions. A connection failure can interrupt those messages. Do not test with customer data or trigger real submissions simply to see whether the button works.
The mail administrator must confirm the chosen account may send the intended messages through the supported connection, within the organization's tenant policies and service limits. The presence of an OAuth option does not prove your plan, mailbox or tenant is eligible. If the required feature or authorization is unavailable, resolve that prerequisite rather than bypassing policy or switching to insecure authentication.
OAuth authorizes an application to act through an account. It is different from DKIM, which signs a message, and SPF, which evaluates the sending server against an envelope-domain policy. Successful OAuth login is therefore not proof that the visible From domain authenticates.
Verify upstream SPF and DKIM first
Use an existing organization-controlled sending domain with SPF and DKIM already configured and verified at the actual provider. Do not use a consumer mailbox as a substitute for your branded domain, or assume a working staff-mail test proves every connected application path behaves identically.
For Workspace, use the existing Google Workspace SPF and DKIM guide. For Microsoft 365, confirm the domain's real tenant records and signing state against Microsoft's DKIM configuration instructions. These are upstream prerequisites, not Formstack-issued records. The responsible mail administrator should confirm the correct actual sending route and SPF policy as well as signing activation before this connection is enabled.
Do not construct Microsoft targets from an old screenshot or tenant-name formula. Likewise, a Google public key in DNS does not prove authentication has been started. Preserve the provider's complete current record set and existing authorized senders. If upstream authentication is incomplete, finish that provider-specific task first rather than improvising a Formstack DNS record.
Keep the intended From address, provider account and authorized sending identity together in the change notes. If the connected account cannot send as the required address under the provider's policy, stop. An arbitrary display name or Reply-To field cannot grant send-as permission or fix DMARC alignment.
Connect the approved account
An administrator opens the avatar menu > SMTP Settings. Select Microsoft 365 OAuth or Google OAuth under SMTP Authentication Method, then sign into the intended account. The documented flow includes a consent/terms step and finally enabling the SMTP settings toggle. Review the requested access and terms with the authorized owner; proceed only within the approved account and permissions. Official Forms connection procedure.
Choose one approved provider, not both in sequence. Verify the account identity shown during sign-in and after return to Formstack. If the consent screen requests unexpected access, stop for administrator review. Never approve broader permissions just to clear an error. Keep credentials and tokens inside the provider's authorized authentication flow, not in documents, support screenshots or shared notes.
The OAuth route in this guide does not require copying the generic username/password example. Preserve multifactor authentication and tenant protections. Do not switch to a legacy workaround, disable certificate verification or create an unauthenticated relay when OAuth is blocked. A security-policy refusal is not evidence that DNS needs changing.
The source also contains older troubleshooting advice and inconsistent generic port guidance. Those are not the procedure recommended here. If a separately approved non-OAuth server is required, obtain current secure settings and a complete supported procedure from that provider; that is outside this OAuth-only walkthrough.
Understand the account-wide sender
The connection governs notifications and confirmations across all forms in the account. Form-level addresses can serve as Reply-To, while the account's configured Email From controls the sender. With Microsoft OAuth, the provider supplies the From address and Formstack does not let you edit it locally. Forms sender behavior.
The inspected Google OAuth illustration also shows a populated, disabled From field and the connected account identity. Verify the actual address in your tenant instead of assuming an alias can be entered freely. This illustration is not a universal promise about every Google alias or delegated mailbox configuration.
Before enablement, compare the resulting sender with the approved plan for every affected form category. Replies may still go somewhere different. Keep reply destinations authorized and monitored, but do not confuse them with the domain DMARC checks. Do not silently substitute a provider-owned From address and declare the customer's brand authenticated.
Test before relying on the connection
Formstack warns that the On toggle does not validate the external mail-server settings. The Forms illustration includes Send a test message. Use a controlled authorized recipient and then test actual notification and confirmation paths with harmless test data. A saved configuration alone is not evidence that mail can be sent. Connection validation limits.
Check both receipt and sender identity. A successful connection test does not cover conditional routing, every form configuration or both notification types. Sample materially different workflows without submitting real personal information or triggering downstream purchases, approvals or customer notifications. Agree those test boundaries with the form owner first.
If enabling the connection breaks delivery, stop further rollout and coordinate the approved recovery plan. Do not assume turning it off preserves branded authentication on the previous default route. Revalidate the route actually restored, and account for missing or queued business messages without blindly resending everything.
Save the recipient's original message and examine results produced inside the receiving service's known processing boundary. Use that service's documented treatment of externally supplied Authentication-Results, or obtain a receiving administrator's trusted trace. A familiar authserv-id string or header position alone is not enough. Ignore injected or otherwise untrusted result fields. Authentication-Results specification.
Acceptance for this branded route requires the intended upstream DKIM signature to pass and align with the intended visible From under the active alignment policy, plus a trusted receiver DMARC pass. Record the envelope domain, signing domain and selector as well as the visible From. A generic DMARC pass through SPF alone does not establish that the intended DKIM setup works.
Interpret SPF, DKIM and DMARC correctly
SPF checks the SMTP envelope sender, not automatically the visible From address. The system submitting a message into a mailbox provider is not necessarily the IP that delivers it to the final recipient. Do not insert Formstack connection IPs into your public SPF merely because a support page discusses server allowlisting. Relay-access controls and receiver-facing SPF authorization serve different purposes.
If upstream SPF needs correction, work at the actual evaluated owner with the mail administrator. Preserve one v=spf1 policy there, other legitimate senders and intended qualifiers. The ten evaluated DNS-dependent-term limit includes nested mechanisms; it is not just ten includes. A redirect is ignored when an all mechanism is present. Do not promise delivery or rejection solely from a qualifier. SPF specification.
Investigate SPF fail, temporary lookup errors and permanent evaluation errors separately, even when aligned DKIM makes DMARC pass. A provider-owned envelope may authenticate without aligning to your brand. That is different from SPF authentication failing.
DMARC can pass through either aligned SPF or aligned DKIM. Relaxed alignment compares Organizational Domains; strict alignment requires the relevant domains to match exactly. A child envelope domain can meet relaxed alignment but not strict alignment against a root visible From. Check actual message identities rather than assuming the same company owns them all. Current DMARC specification.
Preserve existing direct and applicable inherited DMARC policies and approved report destinations. This connection task does not require a new policy, an enforcement downgrade, a new reporting recipient or any nameserver/MX change. If an organization has no applicable policy, its owner and mail administrator should handle that separate domain-wide decision before rollout. Do not add a generic monitoring record merely to silence a test warning.
Troubleshooting and FAQs
What Formstack SPF include should I add?
None can be inferred from this external-provider connection procedure. Confirm which service actually delivers the message and which envelope identity it uses. Apply the selected provider's supported configuration, not an unrelated native-send recipe or corporate SPF lookup.
Where do I obtain a Formstack DKIM selector?
For this route, signing is the upstream mail provider's responsibility. Confirm that provider's domain configuration and actual delivered signature. The Forms OAuth screen does not issue a native Formstack DKIM key in the documented workflow.
Why is the connection On when no messages arrive?
The toggle does not validate the server connection. Check the connected account, tenant authorization and provider-side logs, then a controlled test. If login works but sending is rejected, investigate authorization or sending restrictions before changing DNS.
Why did another form's sender change?
These are account-wide settings for Forms notifications and confirmations. Review all affected forms with their owners. The form-level Reply-To may differ without changing the account-wide From identity. This is why scope approval is required before enablement.
Can I use a different Microsoft From address in Formstack?
The documented Microsoft OAuth From value is supplied by Microsoft, not editable in Formstack. Resolve the intended supported sender with the Microsoft administrator. Do not spoof an address, alter message headers or assume another mailbox's identity is authorized.
Should I weaken account security when Google sign-in fails?
No. Keep multifactor authentication, certificate validation and tenant policy intact. Use the approved OAuth connection and have the administrator diagnose access. An older troubleshooting paragraph is not a reason to enable obsolete access methods or disable protection.
The test message passes. Are all forms ready?
Not yet. Verify actual notifications and confirmations for materially different paths, their visible From, intended signature, reply destination and recipients. Use controlled test data and check that business-critical routing remains correct. Do not claim every form was tested from one button click.
Is Formstack Documents covered here?
No. Documents has different account and delivery controls. Applying its per-delivery SMTP instructions to Forms would misrepresent this account-wide workflow. Use the product-specific procedure rather than assuming the shared brand means identical behavior.
Sources and limits
The primary Forms private-email connection article and its relevant Forms illustrations establish the application steps and sender scope. Upstream authentication remains a prerequisite, not a feature verified by OAuth consent.
This is documentary review. No account was connected, permissions granted, DNS changed, test sent or page published. Static manuscript checks do not establish customer delivery, live CMS rendering, indexation or rankings.