Formstack Documents SPF, DKIM and DMARC setup, step by step

For Formstack Documents email deliveries sent through your own mail service, configure that service’s domain authentication first, then connect the approved sending account in Documents. You can configure the connection at account level or for an individual document delivery. An individual delivery’s SMTP settings override the account settings, and an OAuth connection uses the authenticated account as the sender even if you edit the delivery’s From address.

This guide covers the documented remote-mail route in Formstack Documents, formerly WebMerge. It is not a recipe for native Formstack SPF or DKIM records, Formstack Forms notifications, or every legacy WebMerge integration. Formstack’s instructions describe moving document email away from the default noreply@webmerge.me identity through a remote server. They do not supply a universal customer-domain SPF include or a native DKIM key for this route. Official remote-mail instructions · Current Documents identity.

This is documentary guidance, not a test of your account, DNS or document deliveries.

On this page: Choose the actual document-delivery route · Prepare authentication at the outbound provider · Configure the account-level connection · Configure or inspect an individual delivery · Verify an actual document delivery · Troubleshoot the effective route, not just DNS · Frequently asked questions

Choose the actual document-delivery route

Before configuring anything, identify the template, its Email delivery, intended visible From address, actual sending account and recipients approved for testing. Open the delivery’s settings and check whether it already has its own SMTP configuration. Do not assume that changing the account default changes a delivery with an override.

Account-level configuration is documented for account administrators. Confirm your tenant’s feature availability and permissions before proceeding; the reviewed instructions do not establish a universal subscription tier or region. A different screen is a reason to ask Formstack support about your account, not to apply another product’s controls. Account and individual configuration boundaries.

Obtain the owner’s approval for the specific routing change, affected templates, connection account and access requested. Account-wide routing can affect more than the document you are currently inspecting. Preserve existing settings and document the intended rollback without copying passwords or tokens into notes. Do not send real contracts, personal records or customer documents merely to test a connection.

Prepare authentication at the outbound provider

SMTP or OAuth authenticates a connection to a mail service. It does not by itself prove that recipients will see a passing, aligned DKIM signature for your brand. Before connecting Documents, have the mail administrator establish that the chosen account is permitted to send as the approved address and that the actual outbound service signs for the intended domain.

Use the relevant upstream configuration rather than adding guessed Formstack records:

• For a Google Workspace custom domain, use the Google Workspace SPF, DKIM and DMARC guide. Domain records and signing activation belong to that Workspace configuration, not a new Documents selector.
• For a Microsoft 365 custom domain, use the Microsoft 365 sending-route guide. Confirm that this application’s actual route is covered, not just ordinary employee mail.
• For another supported remote server, obtain its current account-specific authentication and secure connection requirements from its administrator. Do not substitute Google or Microsoft values merely because those providers appear in the Documents OAuth menu.

A consumer mailbox address is not a custom-domain authentication solution for a business domain you want in From. If the approved account cannot send as the intended identity, resolve that mismatch before connecting it. Do not replace the intended sender with a provider address simply to make a test pass.

SPF checks the actual SMTP envelope sender, normally the MAIL FROM domain, not automatically the visible From domain. Maintain one v=spf1 TXT policy per evaluated owner, preserving other legitimate senders. The limit is ten evaluated DNS-dependent terms, including nested mechanisms, not ten displayed includes. Any all mechanism causes redirect to be ignored. These are safeguards for the upstream administrator, not instructions to add a second SPF record for Documents. SPF evaluation and limits.

For DKIM, use the upstream service’s complete issued public record and activate signing there. DNS publication, account connection, signing activation and a received message are separate checks. Preserve current selectors, delegated namespaces and shared dependencies. Do not alter MX, nameservers or security controls just to connect Documents. Keep the current direct or inherited DMARC policy and approved reporting destinations; this workflow does not require a policy downgrade or a new reporting recipient.

Configure the account-level connection

Use this route only when the approved change should apply at account level. With administrator authorization:

1. In the Documents application, open your avatar menu and choose SMTP Settings.
2. Select Use My Own Mail Server.
3. Choose the supported authentication method for the approved provider.
4. Configure or authorize that account as described below.
5. Use the documented Test control with an approved test recipient and no sensitive document content. Complete Update Information when saving the authorized settings; the official account screenshots show this save control.

OAuth: Google or Microsoft

Choose OAuth, select the correct provider, and use Login for the intended account. Review the application, tenant/account identity and requested permissions before authorizing them. Stop for the responsible administrator if the scopes or access are not approved. Do not consent to unexpected permissions simply because a tutorial says to continue.

Formstack documents Google and Microsoft OAuth providers. Crucially, the account used for OAuth determines the send-from email even when a different From address is entered. Check that account before saving. Editing a display name or From field is not a supported way to turn one authenticated account into another sender. The Documents source specifically directs Google connections to OAuth rather than basic authentication. OAuth providers and sender behavior.

Another approved remote SMTP service

Where the provider and tenant support the documented basic-authentication route, supply the exact host, port and approved account credentials from the administrator’s secure configuration process. Keep credentials in the authorized service or credential store, not in shared tickets, screenshots or the document template.

Use the service’s current supported encrypted transport and certificate-validation requirements. The article and screenshots contain example port values; they are not a universal transport configuration. Do not guess an encryption mode from a port, disable MFA, weaken certificate validation or enable obsolete “less secure apps” to get the test working. If current provider policy rejects basic authentication, resolve a supported connection with the administrators instead of bypassing that policy.

A successful Test is an intermediate connection check. It is not evidence that every document delivery inherits this connection or that a real received document message passes branded DKIM and DMARC.

Configure or inspect an individual delivery

For a specific template’s approved route:

1. Open the Deliver tab in Documents.
2. Edit the intended delivery, or create the authorized new delivery, and choose Email.
3. Expand More Options and select Use your mail server to send email (SMTP).
4. Configure and test the chosen account using the supported SMTP or OAuth method.
5. Use Save Delivery, shown in the official delivery screenshots, to save the authorized configuration.

Formstack explicitly states that a delivery-specific connection overrides the account-level SMTP settings. OAuth is available at this level too. Maintain a small inventory of template, delivery, effective connection, intended From and owner so an account-level repair does not leave an old delivery route silently active. Delivery override and OAuth support.

Review recipient, CC/BCC and delivery conditions without altering unrelated behavior. Do not enable an “always send” option, disable document protection, add forwarding recipients or change attachment/download-link behavior merely because those controls appear near SMTP settings. Those choices affect data delivery and need their own approved purpose. Email delivery options.

Verify an actual document delivery

After the approved connection and upstream signing are ready, exercise the intended template’s actual Email delivery using synthetic, non-sensitive document content and controlled valid recipients. A test from the mail provider’s web interface does not exercise the Documents override. Test each materially different connection rather than assuming one template represents all of them.

Inspect the message at a receiving service whose authentication processing boundary is known. Use results generated inside that service and its documented handling of externally supplied Authentication-Results; disregard untrusted injected fields. A familiar authserv-id string or a header’s position alone does not prove that the receiver generated it. Authentication-Results trust considerations.

Record these separate acceptance checks:

• Intended identity: the actual visible From is the approved sender, not an OAuth-account surprise or rewritten provider address. Reply-To is a reply destination, not DKIM or DMARC identity.
• Intended signing service: the expected upstream provider’s DKIM signature passes, with its actual d= domain and selector. A passing unrelated signature does not complete this route’s commissioning.
• Alignment: that intended DKIM signature aligns with visible From under the effective policy. Relaxed alignment permits the same Organizational Domain; strict alignment requires an exact domain match. SPF alignment compares the authenticated MAIL FROM domain with visible From on the corresponding relaxed or strict basis. A child envelope domain does not automatically satisfy strict alignment.
• DMARC: the trusted receiving result reports dmarc=pass for the intended From. DMARC can pass via aligned SPF or DKIM, so SPF-only success does not prove the intended DKIM signature works.
• Delivery behavior: the correct controlled recipient receives the expected synthetic document through the intended delivery, without an unapproved recipient, attachment or routing change.

The governing DMARC alignment rules are in RFC 9989. Keep redacted evidence of the actual path and results; do not copy confidential document bodies or credentials into a support case.

Troubleshoot the effective route, not just DNS

For unresolved cases, give support the product, template/delivery identifier, account-versus-delivery scope, authentication method, approximate time and redacted receiver evidence. Never send passwords, access tokens or customer document contents. Retest the actual document route after any approved repair or rollback.