Key Survey by WorldAPP SPF, DKIM and DMARC setup, step by step

To authenticate a custom From domain in Key Survey’s documented hosted workflow, open My account > Security settings > Registered Email Domains, add the domain, and publish the SPF and DKIM records generated for that account. Then select Verify Domain and test an actual survey email for a passing, aligned branded DKIM signature. Do not reuse the static key from the old WorldAPP PDF. Current domain-registration instructions

Key Survey’s current website identifies FORM in its footer and links to the FORM help center. This guide follows that documented domain-registration workflow for Key Survey, historically described as Key Survey by WorldAPP. It does not assume every FORM product, private-label installation or self-hosted deployment has identical controls. Key Survey’s official company page and Help Center link

This is a documentary guide; no customer account, DNS zone or delivered message was tested.

Confirm the account, sender and hosting route

Key Survey supports customized From and Reply-To addresses for survey invitations and reminders. Those addresses have different purposes: the From domain is the identity DMARC protects; Reply-To controls where responses go. A custom survey web address is not automatically your email-authentication domain. Key Survey email-distribution features

Before registering a domain, establish:

• The account that launches the survey and whether it is single-user, MultiAccess, a multi-user sub-account or private label.
• The exact From address for invitations, reminders and any other active email workflows.
• Whether messages use the hosted service or a separate self-hosted or custom sending arrangement.
• Access to the authoritative DNS zone, not merely the website or registrar account.
• Existing SPF, DKIM and DMARC records, including which team owns each active selector.

The platform’s account boundary matters. The current documentation says a verified domain added for a MultiAccess account is available to all its users, while one added by a sub-user of a multi-user account is available only to that sub-user. For the same domain across multiple accounts, FORM directs customers to support for assistance copying the domain signature. Do not replace one account’s DNS records with another account’s generated set without coordinating that arrangement. Account and domain scope

If your interface lacks Registered Email Domains, ask the account administrator or FORM support which route applies. Do not create guessed DNS records to compensate for a missing control. Retaining a provider-owned From domain is also not permission to modify that provider’s DNS.

Generate your current domain records

1. Open My account in the account that will send the survey.
2. Select Security settings.
3. Under Registered Email Domains, select Add email domain.
4. Enter the domain you intend to use in From, then select Add domain.
5. Capture the generated record types, full owner names, values and targets for that domain.

The current official DNS guide specifies TXT for SPF and CNAME for DKIM, using values from the account’s Value/Data and Points To fields. The selector and DKIM target are not universal copy-and-paste values. Record generation and record publication

Use an implementation worksheet:

Save the current configuration and DNS export before editing. A screenshot can be useful as a change record, but do not expose account credentials or private messages in a shared ticket.

Do not reuse the legacy WorldAPP shared-key instructions

It describes an SPF include and a static ks-mass TXT-key workflow followed by support verification. The current FORM help center instead documents generated domain records, CNAME delegation and the Verify Domain control. Use the current account-issued values for this workflow rather than treating the PDF’s key as a permanent provider constant. Legacy PDF and current DNS instructions

This distinction is particularly important for existing installations. An old selector in DNS may still support an active message stream. Do not delete it merely because a new guide uses a different method. Inventory its use, obtain the supported migration procedure and verify the replacement before retiring it.

FORM states that new custom-domain DKIM generation uses 2048-bit keys from 16 September 2025. Its statement that system emails use updated keys does not prove that every older custom domain was migrated. Check the key associated with your own generated selector. DKIM is a signature mechanism, not content encryption, despite encryption wording in some provider material. FORM’s key update and DKIM specification

Publish SPF and DKIM safely

Merge SPF at the correct owner

Use the owner and authorization generated by your account. If an SPF policy already exists at that owner, integrate the required authorization into that one policy. Do not add a second v=spf1 record or replace employee-email and other application authorizations. Preserve the intended final all qualifier and any deliberate redirect= design unless the domain administrator approves a broader change.

If the existing SPF policy uses redirect=, reconcile its authorizations and terminal behavior with the DNS owner before changing it. Any all mechanism makes redirect ignored regardless of their order. Do not append all automatically: preserve the redirected senders and approved policy semantics through a reviewed design. SPF all and redirect processing.

The older PDF and third-party articles show different provider includes. That is a reason to use the current generated values, not to publish every historical include “just in case.” A lookup of a provider domain alone would not prove it is the right authorization for your particular hosted account.

SPF permits one selected policy per owner and a maximum of ten lookup-causing terms across the evaluated chain. Nested includes count toward that limit. Diagnose the complete policy with its current dependencies before adding more senders. SPF record selection and processing limits

Publish the generated DKIM CNAME exactly

The DKIM owner normally has a generated selector followed by ._domainkey and the signing domain. Copy your account’s complete value rather than reconstructing it from this description.

Check how your DNS editor handles names:

• If it appends example.com, use only the relative prefix that produces the requested full owner.
• If it accepts complete names, follow its fully qualified name and trailing-dot rules.
• Keep the target as a hostname, without https://, a path or quotation marks intended for TXT values.
• Preserve the underscore in _domainkey.
• Use DNS-only behavior if a web proxy is available; ensure CNAME flattening does not hide the required delegation. Cloudflare documents both per-record and zone-wide flattening as possible causes, including on DNS-only records. Review wider effects before changing zone-wide settings. Cloudflare’s CNAME verification guidance

FORM’s official guide specifically discusses automatic suffix handling and a “non fully-qualified domain name” error for Points To. A trailing dot may be required by the DNS host; it is not an instruction to alter the generated hostname. FORM DNS formatting guidance

A CNAME generally cannot coexist with other ordinary DNS data at the same owner. If an issued owner already belongs to another active account or service, stop and resolve ownership before replacing it. Leave unrelated DKIM selectors, mailbox MX records, website records and domain-verification records unchanged. DNS alias constraints

For an illustrative issued owner SELECTOR._domainkey.news.example.com, a suffix-appending editor for example.com uses SELECTOR._domainkey.news; one for a separately delegated news.example.com zone uses SELECTOR._domainkey. If _domainkey.news.example.com itself is delegated, use relative SELECTOR in that zone. A full-name field takes the complete issued owner. Replace the placeholder with the actual account selector, preserve existing NS delegations and active selectors, and publish with the actual authority rather than adding an inactive parent-zone copy. DNS zone boundaries.

Where the issued authentication or return-path records require literal CNAME answers, use DNS-only aliases returning the exact targets, without an HTTP proxy or flattening hiding them. Turn the relevant per-record Flatten control off when available and ensure applicable zone settings preserve those aliases. Cloudflare documents that 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 conditional DNS-host behaviors, not assumed controls in every panel. If mandatory apex/same-zone behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration with the DNS owner and sender. Do not blindly change the whole zone or remove an existing delegation. CNAME verification, flattening controls and limits.

If the zone is hosted at GoDaddy, use the GoDaddy authentication-record publishing guide for the DNS editor. Key Survey’s current generated values remain the source of truth.

Verify the domain and understand Re-Verify’s effect

After publication, check public DNS and return to Security settings > Verify Domain. The provider allows 24–48 hours for DNS updates. Successful validation produces Verified status. If authoritative DNS already shows a typo or missing record, correct that problem rather than waiting for the timer to expire. Verification procedure

Verified is not continuous monitoring. The official guide says the platform does not automatically recheck the domain later. A once-verified domain can therefore retain its status after its DNS records have been removed or changed.

Re-Verify can affect production signing. If required records are missing, re-verification changes the domain to Not Verified. The guide warns that a granted domain failing this check will stop signing outgoing email for that domain from all users under the account. Check and repair authoritative DNS first, coordinate with the account owner, and avoid using Re-Verify as a harmless exploratory click during a live campaign. Re-verification behavior and signing impact

After a repair and successful verification, confirm signing on new messages from every relevant account or user scope. A historical Verified badge cannot establish which signature a new invitation uses.

Include account-level signing controls in the review. FORM’s User Administration Guide, currently under its Self Host Guide, documents a right named Disable emails security: when enabled, mail from that account is not DKIM-signed and uses the unsigned SMTP queue. For a deployment exposing this right, have its authorized administrator confirm the intended signing state. Do not infer a hosted-customer toggle from that self-host administration page; ask FORM to establish whether an equivalent account setting affects your hosted route. DNS verification cannot override disabled signing, and changing security rights requires a separately approved configuration decision. FORM account-administration reference.

Plan a 2048-bit key migration without losing signing

FORM’s documented upgrade method for an older 1024-bit registration is to remove the registered email domain, add the same domain again, and use the newly generated records. That is an account configuration change, not simply a DNS key-length edit. Official 2048-bit upgrade method

Before following it on an active sender:

1. Inventory scheduled invitations, reminders, automations and all users/accounts sharing the domain.
2. Export current DNS and capture the registration and account scope.
3. Ask support whether a supported overlap or staged migration is available for your configuration. The public procedure does not promise uninterrupted signing or an overlap period.
4. Arrange a maintenance window or pause relevant sends if uninterrupted authentication cannot be established.
5. Carry out the approved remove-and-add workflow, publish the newly issued records and complete Verify Domain.
6. Validate the new selector/key and test real messages before resuming normal volume.

Keep the prior public record only as long as the supported migration and in-flight messages require. Do not delete other accounts’ records, assume the old selector remains valid indefinitely, or promise that restoring old DNS alone will restore a removed account registration. The application and DNS state must agree.

Understand the identities DMARC compares

SPF evaluates the SMTP MAIL FROM domain, usually visible in Return-Path and reported as smtp.mailfrom. It does not evaluate Reply-To or the visible From address. For a null reverse-path, SPF uses HELO. The public Key Survey workflow does not guarantee one envelope hostname for all accounts, so inspect the actual value on delivered mail. SPF identity rules

DKIM uses the signing domain in d= and the selector in s=. The selector identifies the public key at selector._domainkey.signing-domain. A CNAME pointing into worldapp.com does not itself mean the message’s signing domain is worldapp.com: inspect d=. DKIM signature and verification

DMARC requires a passing, aligned SPF or DKIM result. Under relaxed alignment, the authenticated domain and visible From share an organizational domain. Strict aspf=s and adkim=s require exact equality for the respective mechanism. A provider-owned envelope can pass SPF without aligning with your brand; a passing branded DKIM signature can provide the DMARC pass instead. Adding an SPF include at your root domain does not change the service’s envelope identity. DMARC alignment

Preserve DMARC policy and set up useful reporting

Inspect _dmarc for the actual From domain and any applicable parent policy. Keep existing enforcement and reporting settings. Neither account verification nor a new DKIM key requires replacing a valid DMARC policy.

If beginning a new monitored rollout with no existing applicable policy to preserve, an illustrative TXT record at _dmarc.example.com is:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the example with a domain-owner-approved policy and working report address. Publish one policy at that owner. Do not downgrade an established quarantine or reject policy to this sample. p=none is monitoring, not a delivery guarantee. DMARC policy semantics

For a first policy at full owner _dmarc.example.com, a relative-name field in zone example.com takes _dmarc. For a deliberately approved child policy at _dmarc.news.example.com, use _dmarc.news in the parent zone or _dmarc in a separately delegated news.example.com zone. A full-name field takes the complete owner. These examples do not authorize overriding an inherited policy.

Review aggregate reports for the survey stream, other legitimate senders and unexplained sources. Do not enable failure reports by default.

Compare the Organizational Domain of the aggregate-report URI's host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as the policy domain is excepted; a different hostname alone does not make it external. Obtain the reporting operator's exact authorization instructions when required. This protocol check is separate from the domain owner's approval to share report data; agree access, retention and privacy. RFC 9990 section 4.

Move toward enforcement only after the domain owner has evaluated all legitimate sending routes. One survey test cannot establish that payroll, support and employee mail are ready.

Test public DNS and delivered survey messages

DNS checks

Replace all placeholders with the generated values. generated-selector and issued-target are placeholders, not Key Survey record values.

dig +short NS example.com
dig @ns1.example.net TXT example.com +noall +answer
dig @ns1.example.net CNAME generated-selector._domainkey.example.com +noall +answer
dig +short CNAME generated-selector._domainkey.example.com
dig +short TXT issued-target.example.net
dig +short TXT _dmarc.example.com

Use the actual SPF owner if it differs from example.com, and repeat for all generated records. Expect one SPF policy at the required owner, the exact DKIM CNAME target and a resolvable public key at the delegated destination. Compare authoritative and recursive results after relevant cache lifetimes. Query the actual envelope domain’s SPF record once a delivered message identifies it.

Delivered-message acceptance

After implementation is authorized, send a test invitation and reminder through the real survey workflow to controlled external mailboxes. Use test recipients and non-sensitive survey content. Include each account or user scope that needs to send as the domain; do not assume an administrator’s test proves every sub-user is configured.

Repeat acceptance for every other actually used native path, including alerts, notifications, scheduled report delivery and task-related email where enabled for this deployment. Record each path’s account, approved From, envelope, intended signer and trusted DMARC result; do not assume invitation success covers it. Confirm that applicable account-level rights have not routed that path through an unsigned queue. Use a controlled non-commercial workflow and approved recipients, not a mass live launch.

Inspect the Authentication-Results added by the trusted recipient system, not an arbitrary upstream header. Save the visible From, Return-Path, smtp.mailfrom, each DKIM d= and s=, and the reported SPF/DKIM/DMARC outcomes. Trusted authentication results

Establish which results were generated inside the receiving service's known processing boundary and how it removes, ignores or distinguishes externally supplied Authentication-Results. Use receiver-controlled diagnostics or have the receiving-mail administrator confirm its documented handling. A familiar authserv-id string or header position alone is not proof. Ignore attacker-supplied or otherwise untrusted fields; obtain authenticated receiving-system evidence when provenance is uncertain. Receiver-result trust.

Completion requires:

• The intended custom From domain on the real invitation and reminder.
• dkim=pass for the intended branded signature, using the current generated selector and a signing domain aligned under the published adkim mode.
• The actual SPF result and envelope alignment evaluated separately.
• dmarc=pass for the intended From domain.
• No unexplained difference between relevant accounts, sub-users or sending workflows.

Do not accept missing branded DKIM merely because SPF passes DMARC. Investigate SPF fail, softfail, permerror and temperror even if DKIM supplies DMARC’s aligned pass. Check the actual connecting IP and envelope-domain policy, then distinguish direct delivery from a forwarding hop before editing DNS.

Diagnose SPF at the actual envelope owner independently even when aligned DKIM supplies DMARC. For fail or softfail, compare the observed connecting source and MAIL FROM identity with the approved authorization and sending route. For permerror, check duplicate SPF policies, malformed syntax and the full nested DNS-dependent term budget. For temperror, investigate temporary DNS resolution or availability failures and retest after recovery. A provider-owned SPF pass without alignment is different from these failures; escalate errors for provider-owned identities to that sender rather than editing unrelated apex DNS. SPF result definitions.

Keep the approved branded From unchanged. A provider rewrite is not a substitute for authentication of the intended invitation or reminder identity.

Troubleshooting

Registration and account-scope failure modes are documented in FORM’s Registered Email Domains guide. Authentication does not guarantee inbox placement, and recipient allowlisting is not a substitute for signing or alignment.