Use the current domain setup before changing DNS
SmartSurvey's sending-domain configuration governs the identity of survey mail. Begin with the actual account and the kinds of mail it sends: invitations, reminders, triggers, save-and-continue messages and scheduled reports. Record the intended From address for each route and which users or sub-accounts may use it. A successful test invitation should not close untested notification routes.
The official setup page changed between retrieved versions. The newer page, displaying build 2026.11.3.24, says the sending domain itself needs no SPF record for this setup. It describes DKIM TXT verification and an optional bounce domain with MX and TXT records. Use the account's current output, not older root-SPF instructions. SmartSurvey sending-domain guide, Setting it up.
The discrepancy is an implementation hold until an administrator confirms which workflow the tenant presents. Preserve a dated copy of the current instructions and issued records with the change request. Do not combine fragments of old and new flows, and do not delete an existing SPF policy needed by other mail services.
Separate the survey web address from the sending domain
Choose names with the DNS administrator before setup. The branded survey-link hostname and the email sending domain cannot occupy the same CNAME owner alongside mail records. The current guide warns about this collision. SmartSurvey sending-domain guide, Choosing a sending domain.
Inventory current DNS use rather than assuming a name is free because it has no website. It may already serve tracking, a delegated child zone, certificate validation or another provider. Record the full intended names for the survey site, visible From and bounce domain separately. Those names have different functions even when they share the same organizational domain.
Get approval for the displayed sender name and working reply mailbox. Survey recipients may need to ask why they were contacted or request help. Test reply routing as an operational requirement, while keeping it distinct from DMARC, which compares the visible From with authenticated identities rather than Reply-To.
Apply domain and address permissions deliberately
In My Account > Advanced > Domain Sender Settings, follow the tenant's current verification flow and copy its issued records. Review the Senders column: a domain may allow any address or require individually verified addresses. Sharing with sub-accounts broadens who can use that identity. SmartSurvey sending-domain guide, Which addresses can send and Requiring Verified Sender Addresses.
The current guide also says existing scheduled invitations, triggers, save-and-continue messages and scheduled exports keep sending after verified-address requirements are enabled; the requirement applies when they are next edited and saved. Collaborators can continue using the survey owner’s verified address. Inventory existing workflows explicitly instead of treating the new switch as immediate revocation everywhere.
Build a small permissions matrix before changing those controls. Include the account owner, the survey owner, collaborators and sub-account operators. For each, identify which From address is permitted and whether the existing workflow is being edited. Do not treat a domain-wide approval as an invitation to impersonate a colleague. Retain the approved scope in the implementation record.
Address verification and DNS verification answer different questions. Evidence that somebody received a confirmation email does not prove that outgoing mail uses an aligned DKIM signature. Conversely, valid DNS does not establish that every account user should be allowed to select every address.
Verify the custom bounce route on its own terms
SmartSurvey's bounce guide describes a move from its older CNAME implementation to Amazon SES custom MAIL FROM. If a bounce domain is supplied but fails verification, domain verification remains incomplete. Leaving it blank uses a provider Return-Path. The custom subdomain model requires relaxed SPF alignment when the envelope and visible From domains differ. SmartSurvey bounce-domain guide.
The bounce page calls for a child of the sending domain, yet its example pairs surveys.example.com with sibling bounce.example.com. Do not infer that every sibling arrangement is supported. Confirm the exact allowed relationship in the tenant or with support and retain that uncertainty separately from protocol alignment.
Use only the MX and TXT values displayed for this tenant. Do not manufacture an SES region hostname, substitute a generic CNAME or reuse values from another organization's account. Retain MX priority as well as owner, type, target and TTL. An MX change at the wrong owner could affect ordinary inbound mail, so a second reviewer should compare the full names before publication.
Review the actual DMARC policy. A child bounce domain can align under relaxed SPF rules while failing strict exact-domain comparison. That does not automatically make the whole message fail DMARC: an independently passing aligned DKIM signature can still satisfy it. Apply protocol rules to the receiver's results rather than treating every provider shorthand as the complete evaluation. RFC 9989, Identifier Alignment Explained and DMARC Evaluation.
Publish records and preserve the public answers
Export the relevant zone before making changes. Add the exact current records at the authoritative service and verify the resulting full owner names. For long DKIM values, ensure the DNS editor creates one logical TXT record, even if its text is split into multiple strings. Do not create multiple competing key records at the same selector.
Check the public DKIM answer against the account's key and then perform the provider verification. A signature's d and s values identify the signing domain and selector; the received message supplies the decisive pair to inspect. RFC 6376, sections 3.5 and 6.1.
For any bounce-domain SPF record, keep one policy at that owner. Multiple SPF policies are invalid, and DNS-querying terms are subject to the protocol evaluation limit. These checks apply to the relevant envelope domain, not automatically to the corporate apex. RFC 7208, sections 4.5 and 4.6.4.
Test identity and fallback behavior
Send harmless samples through every material survey-mail route to controlled external recipients. Preserve Message-ID, sending time, survey or workflow identifier and original headers. In the worksheet, record visible From, Return-Path, trusted SPF result and domain, every DKIM d and s, and the DMARC result. Mark the aligned mechanism explicitly.
SmartSurvey's automatic-check documentation says DNS problems can trigger an account-owner warning and later deactivate the sending domain; affected systems can continue using its fallback sender. That means delivery may continue while branding changes. SmartSurvey automatic domain checks.
The automatic-check page describes weekday working-hours checks and a 24-hour notice to the account owner before deactivation. Its older SPF wording differs from the current setup flow; confirm the applicable records rather than recreating an unnecessary root SPF step. The receipt-issues page says only invitations currently expose bounce feedback, so absence of a reported bounce for another notification is not proof of delivery.
Assign someone to receive and act on those warnings. Monitoring should check both message arrival and expected identity. A rule that merely counts delivered invitations can miss the fallback. The receipt-issues guide also distinguishes application sending from recipient-side filtering, so retain exact bounce or rejection details before assuming a DNS change will fix every missing message. SmartSurvey email receipt issues.
Use an explicit release and recovery record
Complete the SmartSurvey sender and bounce worksheet (create a separate review record with the fields described here). Include the tenant's documented flow, the permissions matrix, the separate web and mail names, and evidence from each route. If a requirement is untested, leave it open rather than reporting a universal pass.
If a new configuration fails, pause affected invitations or return them to a previously approved sender through the agreed operational process. Obtain business approval before deliberately relying on provider-branded fallback. Preserve old authentication answers while queued traffic may still need them. Do not lower the organization-wide DMARC policy merely to avoid investigating one survey route.
Fictional diagnostic case involving a fallback sender
Fictional written case only: SS-01 assumes expected From surveys@orchard.example but the received invitation instead shows member@smartsurveyuser.com after a domain deactivation warning. Exact DKIM and SPF identities/results are unknown. The survey owner must inspect the warning, confirm current tenant-issued DNS settings, restore only the approved configuration and collect a new invitation showing the required brand identity. Delivery alone is not acceptance, and no successful repair or alignment is asserted. No tenant, DNS or message was inspected.
Acceptance remains pending
The draft follows the newer recovered setup text and retains the older-text discrepancy for review. Original-scope acceptance, tenant-specific feature confirmation, live DNS and message evidence, independent technical review, visual review and human SME approval remain pending. No configuration or policy change has been made.
Separate a passing message from enforcement readiness
RFC 9989 Section 7.4 requires valid DKIM for a domain publishing p=reject and cautions about indirect-mail interoperability. A single aligned SPF result does not by itself justify a reject-policy rollout. Review all legitimate routes and policy ownership separately from this provider setup.