Define the survey invitation route
This guide covers survey invitations sent through QuestionPro's own email service using a custom From address. It does not configure an organization's separate SMTP service or assume that every QuestionPro product shares identical controls. Record the account, product, survey, intended From address, and responsible domain administrator before changing anything. A recognizable display name alone says nothing about the domain that authenticates.
QuestionPro's invitation guide distinguishes domain authentication from access to the individual From inbox. Its custom-address workflow is reached from the selected survey's Distribute area, using the From-address control. After the domain is verified, the sender address must also be added and confirmed through its inbox. Treat those as separate acceptance gates. QuestionPro customized invitations
Identify who can receive the confirmation and who will handle respondent replies. Avoid using an invented mailbox solely because the domain exists. If the team wants an unattended address, establish reply handling through the responsible mail service rather than assuming QuestionPro provisions a mailbox. Keep the test survey free of respondent personal data, and use recipients authorized for controlled testing.
Authenticate a first domain in the account
The documented account path is User Profile, My Account, Domain Authentication, New Domain. Enter the controlled domain, obtain the displayed SPF instruction, then generate the DKIM key. Publish the issued selector and public value and use the verification control. The provider also requires a valid DMARC record. Its guidance allows up to six hours for generated keys to become available on its email servers and recommends waiting six to twelve hours for verification after DNS changes. QuestionPro domain authentication
Treat those published intervals as troubleshooting guidance, not a promise about a particular DNS cache or tenant. Save the key-generation time separately from the DNS publication time. If verification fails immediately, first establish which prerequisite is still pending. Repeatedly generating new keys can make the evidence harder to reconcile, so do not regenerate merely because a short-lived pending state appears.
Use the public values issued for that domain. Do not copy a selector or key from another customer, and do not put private signing material in DNS. The selector and signing domain determine where a receiver retrieves the DKIM public key. This is why a record at an appealing but incorrect owner name does not repair an actual signature. DKIM RFC 6376
The QuestionPro SPF page also directs readers to the account-generated instruction. Apply it only to a domain the organization owns or is authorized to administer. A mailbox at a public email provider does not grant control of that provider's DNS. QuestionPro SPF guidance
Preserve existing SPF and receiving mail
Before editing, capture the current authoritative nameservers, SPF record, DMARC policy, and any existing DKIM records at the proposed selector. Identify other services sending with the same identity. The new provider must not displace the organization's normal mailbox authorization or another operational sender.
Publish a single SPF policy at each owner and merge authorized mechanisms into the existing policy where appropriate. Check the lookup limit after the merge. SPF evaluates an SMTP identity; simply adding an include to the visible From domain does not establish that a received message will use that domain for SPF. Use the actual envelope identity during testing. SPF RFC 7208
Check the full owner names after publication. An editor that appends the zone can create a doubled domain when a fully qualified name is pasted into a relative-name field. Record both the value shown in the DNS interface and the public answer. Do not modify MX routing as an unrelated troubleshooting experiment. The invitation workflow needs a usable sender inbox, but authenticating a survey service is not an instruction to migrate all organizational mail.
Handle a domain already used by another account
QuestionPro documents a different branch when the same domain is authenticated in another account: complete the account flow and publish its domain-ownership record rather than assuming a fresh SPF and DKIM setup is required. Preserve the existing signing records until the current tenant instructions establish what is needed. QuestionPro domain authentication
Create an account-to-domain register with the original setup owner, additional account owner, existing public records, and any new ownership proof. A second account's request should not become an accidental key rotation for the first account. Record precisely which account shows a verified state and which message routes have been tested. “The domain is already verified somewhere” is not sufficient acceptance evidence for the new sending account.
There is a documentation conflict in the current first-party material: the domain-authentication page and the customized-invitation page list different domain quotas for the same license families. This guide deliberately promises no numeric quota. Confirm the current entitlement in the actual account or with QuestionPro before planning additional domains. That conflict does not justify inventing missing controls or using an unauthorized account workaround. QuestionPro domain authentication QuestionPro customized invitations
Validate the selected invitation rather than the badge
After domain and inbox verification, select the intended From address in the actual invitation and send a controlled test. Confirm the message's From and Reply-To values, envelope domain, DKIM d= and s= values, and the receiver's trusted Authentication-Results. Test a reminder separately if reminders are part of the deployment. Keep account and survey identifiers with the evidence so the result cannot be accidentally attributed to another workspace.
DMARC requires a passing mechanism aligned with the visible From domain. Either aligned SPF or aligned DKIM can supply the pass. Preserve the actual alignment mode and policy scope rather than assuming a provider badge proves all receiver outcomes. A domain record, a verification status, and a received authentication result are different types of evidence. DMARC RFC 9989
QuestionPro documents delivery investigation through the selected survey's Distribute area, Email, Sent, and the Undelivered count. It asks support cases to establish permission to contact recipients and the state of SPF, DKIM, and DMARC. Use the specific failure information alongside authentication evidence instead of changing DNS for every bounce. QuestionPro delivery troubleshooting
A nonexistent recipient, an account limit, or poor engagement requires a different response from a missing DKIM key. Do not claim that passing authentication guarantees the inbox. Preserve consent and list-quality checks as a separate operational responsibility.
QuestionPro acceptance worksheet
Complete this proposed record for each sending account and domain. No fields below represent customer test results.
- Scope: account, product, license entitlement confirmed without relying on conflicting quotas, survey, sender owner, and delivery service.
- Domain branch: first authentication or additional-account ownership proof, original setup owner, and existing dependencies.
- DNS: issued SPF instruction, selector and public key, ownership record if applicable, authoritative answers, TTLs, and timestamps.
- Provider timing: key-generation time, DNS publication time, verification attempts, exact status, and unresolved messages.
- Sender address: confirmed inbox, selected From, Reply-To, reply-handling owner, and verification completion.
- Received evidence: invitation or reminder, receiver, envelope domain, DKIM domains and selectors, authentication outcomes, and alignment.
- Decision: remaining accounts or products, rollback plan, quota clarification, human reviewer, and approval state.
Fictional diagnosis of a second account regression
This example is fictional. A second research account is added for a department. An administrator assumes the existing domain must be authenticated from scratch and proposes replacing its working DKIM record. The original team's campaigns are still active.
The safer investigation identifies the additional-account ownership branch, compares the tenant-issued instruction with existing records, and preserves the working signing key. Both accounts then need separate controlled invitation tests. If the current interface differs from the documented branch, the change remains on hold for provider clarification rather than forcing the old instructions. This is an illustrative decision path, not a completed tenant change.
Evidence and review gates
Live account eligibility, generated values, domain ownership, DNS responses, key readiness, inbox confirmation, and received-message alignment remain untested. The conflicting domain quotas are a specific product-scope hold. Human SME review, visual review, and publication approval are pending. Keep the candidate unpublished and retain the account-specific worksheet with any later validation.
Keep the second-account decision reversible
Before changing a shared domain for a new research account, record the original account owner and the candidate record names. If a new instruction overlaps a working selector, stop and ask whether this is ownership proof or a signing-key change. The fictional example establishes no actual selector, successful campaign or completed migration. Maintain the existing route until the intended change and rollback are agreed.
Separate message acceptance from policy rollout
A passing aligned SPF result can satisfy a message evaluation, but does not alone justify moving an entire domain to reject. RFC 9989 Section 7.4 requires valid DKIM for domains publishing p=reject and warns about indirect-mail interoperability. Inventory all legitimate senders and indirect routes before the policy owner approves enforcement. No DNS change, tenant operation or received-message test was executed for this article.