QuestionPro SPF, DKIM and DMARC setup, step by step

For survey invitations sent through QuestionPro's own servers, use My Account → Domain Authentication → New Domain, publish the account-issued SPF and DKIM information, retain a valid applicable DMARC policy, and verify the domain. Then verify the sender mailbox and test a real invitation. If you use a custom SMTP relay, configure authentication at that mail provider instead. QuestionPro domain authentication · SMTP relay integration

Public documentation was reviewed; no account, customer DNS or delivered invitation was tested.

Identify the account, product and sending route

QuestionPro survey distribution, Customer Experience, Communities and other products should not be assumed to have identical entitlement or navigation. Record the product, account, data center, From domain and whether SMTP relay is enabled before requesting DNS work.

QuestionPro's SMTP documentation lists Team Edition and Research Edition for that feature and warns that the main account's relay applies to subaccounts. It currently says Azure-based SMTP relay setups are unsupported. Do not treat an older server table as proof that a particular Microsoft/Azure route is supported. Confirm compatibility before changing a production transport. SMTP relay scope and setup

For an authorized custom-relay setup, open My Account → Account Settings, enable SMTP, enter the mail provider’s connection details and choose Save and verify connection. Confirm the success notification; on failure, inspect the connection log. The relay must accept the selected From and Reply-To addresses. Then activate branded signing at that provider and run the receiver checks below. A verified SMTP connection alone does not validate DKIM or DMARC. QuestionPro SMTP controls

Prepare for a first-domain setup

Have your DNS administrator retain the current zone records and identify the authoritative DNS service. Obtain access to the intended sender mailbox and controlled test inboxes. Inventory other domain senders before touching SPF or DMARC, including any applicable inherited DMARC policy.

The domain-authentication document lists two domains for Advanced, five for Team Edition and ten for Research Edition; it also gives separate product entries. A separate invitation-settings page lists lower limits for some plans. Confirm the current entitlement in your account or with Support rather than treating either table as a purchase promise or extrapolating from an email-server page's broader license list. A custom survey URL does not by itself authenticate the domain in an invitation's From header. Domain authentication and limits

Configure SPF and generate the DKIM record

1. Open User Profile, then My Account → Domain Authentication.
2. Select New Domain and enter the email domain you control.
3. Review the SPF information presented. Merge the required authorization into the existing policy at the specified owner; do not create a second SPF record.
4. Choose Generate DKIM Key. Copy the issued selector and complete public-key information into the DNS change request.
5. Publish the issued public TXT record at the selector owner, select Finish, and use Verify after records and signing keys are available.

QuestionPro says its generated keys can take up to six hours to become available on its email servers and recommends waiting six to twelve hours before domain verification. These are provider estimates, not proof that a malformed record will fix itself with time. First-domain workflow

No example key belongs to your account. A selector owner has the structural form selector._domainkey.example.com, but use the actual issued selector, domain and public value. Do not publish a private key, replace another service's selector or invent a CNAME target. If the account issues a CNAME instead, confirm the updated method and publish its exact target without proxying or flattening; a CNAME cannot coexist with other data at that owner.

For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. 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

Only if the current account actually issues a CNAME for the updated route: Keep the required literal CNAME answer: turn relevant per-record Flatten off where available and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, apex CNAMEs are flattened by default and same-zone targets are flattened regardless of that setting; flatten-all cannot be overridden per record. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration without breaking other services or removing NS delegation. These are DNS-host behaviors, not controls assumed in the sending provider. Cloudflare flattening controls and limits.

Which QuestionPro SPF include should I use?

Prefer the value issued for the account's actual data center. The current server reference distinguishes, among others:

The reference lists two alternatives for US/LATAM: _spf.qp-mail.mx and _spf.questionpro.mx. Confirm the issued choice instead of copying the table's separator into DNS or adding both speculatively. QuestionPro email-server reference

For a confirmed Seattle account, the mechanism is include:_spf.qp-mail.com. Insert it before the existing terminal all, preserving legitimate senders and the current qualifier. SPF does not inherit from a parent domain: authorize the exact owner required by the setup and actual envelope route.

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

A separate QuestionPro DKIM article still describes a support-led process and include:_spf.questionpro.com. Treat that as a distinct documented workflow, not a reason to override the regional values issued by Domain Authentication. If your account follows the support-led route, obtain its exact records, fees and activation instructions from the account representative. Support-led DKIM procedure

Diagnose SPF rather than adding more records

Only one TXT record beginning v=spf1 is allowed per owner. SPF permits at most 10 evaluated DNS-query-causing terms, including nested includes and redirects. Several quoted chunks within one TXT record are different from two separate SPF records. Preserve unrelated verification TXT data. SPF requirements and limits

Do not manually flatten the regional include into today's IP list. Do not use the domain-authentication page's macro example as a ready-made SPF recipe: macros are not supported inside an ip4 address literal. Keep the provider-maintained include issued for your route and validate the entire existing policy under RFC 7208.

If SPF fails, read the receiver's smtp.mailfrom domain and sending IP first. A valid record at your visible From domain may not be the record evaluated by the receiver. permerror suggests a permanent configuration problem such as duplicate policies, invalid syntax or lookup-term overflow; temperror suggests a temporary DNS problem. An ordinary fail means the evaluated sender was not authorized. These require different fixes.

Reuse a domain without disrupting the first account

For a domain already authenticated through another QuestionPro account, the documented second-account flow supplies a domain-ownership record rather than asking you to recreate SPF and DKIM. Add the issued ownership record, finish and verify. Keep the existing working authentication records. Multiple-account domain authentication

The article does not settle every cross-data-center combination. If the second account supplies different instructions or cannot recognize the domain, ask Support whether reuse is supported for those regions before replacing anything. Test both accounts after an authorized change. Domain ownership in account B does not prove account B signs with account A's working configuration.

Verify the From address and activation

Domain authentication proves control of DNS. Sender-address verification proves access to the selected mailbox. Complete both where required; select the verified address in the survey's distribution settings rather than assuming the account profile address is used.

In Surveys → select survey → Distribute, open the From dropdown and choose Add From Email. After domain verification, use the Email tab to select that domain, enter the mailbox and choose Add and Verify Email. Complete the inbox link, refresh verification status and select the address for the invitation. Survey invitation sender verification

Customer Experience has a separate template workflow under CX → Deploy → Distribute → Templates. Match the product-specific interface in your account rather than transferring this navigation to every edition. Customer Experience invitation settings

For the support-led DKIM path, QuestionPro describes activation after TXT verification and a subsequent signature/delivery check. For the Domain Authentication path, complete its Verify action and then inspect your own test invitation. Neither path's badge alone proves a receiving server accepted a branded signature. DKIM activation

Preserve DMARC and prove alignment

A valid applicable DMARC policy is part of QuestionPro's documented domain-verification requirements. Preserve an existing direct or inherited policy. Do not lower enforcement just to obtain a Verified badge. QuestionPro prerequisites

DMARC needs either passing SPF aligned with the visible From domain or a passing aligned DKIM signature. Under relaxed alignment the organizational domains match; strict alignment requires exact domain equality. spf=pass for a provider-owned envelope domain, or dkim=pass for an unrelated provider domain, does not alone authenticate your brand under DMARC. RFC 9989

Only when no applicable existing or inherited policy is present should the domain owner approve a first policy. Create a single TXT record at _dmarc for the intended From domain. A minimal observation-stage value is v=DMARC1; p=none; add rua=mailto: only for an approved operational report destination, including any external-report authorization it requires. Without rua, that minimal record does not provide aggregate monitoring. Inspect reports and all legitimate sending streams before stronger enforcement. Do not rely on obsolete pct percentage rollout.

Use RFC 9990 aggregate reporting for the monitoring plan. Do not enable ruf failure reports by default: message information can be disclosed, so apply the separate privacy and recipient approval described by RFC 9991.

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 that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4. For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names.

Acceptance test: one invitation, all relevant identities

Use read-only DNS checks with your actual issued names. The example below is illustrative, not an account configuration:

dig +short NS example.com
dig +short TXT surveys.example.com
dig +short TXT qpissued1._domainkey.surveys.example.com
dig +short TXT _dmarc.surveys.example.com

Confirm the correct SPF policy, full public key and applicable DMARC record with authoritative DNS and an independent recursive resolver. If no direct DMARC record exists, inspect ancestor policy discovery before adding one. Confirm any ownership record separately.

Send an authorized test invitation to controlled external inboxes. Retain full headers and verify the intended From address, the receiver's SPF result and smtp.mailfrom, every DKIM signature's d= and s=, and dmarc=pass. Trust results added by the receiving service, not an arbitrary header embedded by the sender.

For a branded-DKIM rollout, require dkim=pass for a domain aligned with your From domain even if SPF already produces a DMARC pass. Repeat for each active account, region, From domain and separately configured reminder route. Track delivery location and bounces independently; authentication does not guarantee inbox placement. QuestionPro explicitly disclaims guaranteed delivery in its mail-server guidance.

Require the intended QuestionPro-issued signature, or the intended final external-relay signature on that separately selected route, to match its active account-issued d= and s=, pass DKIM, and align under effective adkim with the intended unchanged From. Also require the trusted receiver’s dmarc=pass for that From. Another aligned signer or SPF alone does not complete the intended signing setup. DKIM signature identifiers, DMARC alignment.

For a message with multiple signatures, EmailAuth’s DKIM selector guide explains how to keep each signing domain and selector together when deriving its public-key lookup. Do not pair one signature’s selector with another signature’s domain.

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

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

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.

Troubleshooting by symptom

For escalation, supply account/product, region, route, redacted headers, the DNS owner/type, timestamps and the exact error. Do not send credentials, private keys or the survey recipient list. Keep any rollback limited to the failed change and retest unaffected accounts.

For survey-delivery investigation, select the survey, then open Distribute > Email > Sent and select the Undelivered count to inspect the failure reason. Preserve that reason separately from DNS results. Verify recipient consent and list quality instead of treating every bounce as an authentication fault. Confirm that the approved reply mailbox is usable and that its owner will handle responses; changing Reply-To does not repair alignment. QuestionPro delivery troubleshooting.