Provider documentation checked on 8 November 2026. Account-generated values, entitlements and current support remain deployment prerequisites.
Scope and provider-specific configuration
References: RFC 7208 §3.2, RFC 9989 §4.10.
Survalyzer’s retained German-language guide describes custom sender domains for survey invitations. It requires the Corporate Package and coordination among the customer, DNS team and Survalyzer. It also calls for consistency between the sender domain and survey domain. A custom survey URL is not a substitute for the email authentication setup.
Select the intended invitation-sender domain and confirm the account's data center from its application hostname. The guide distinguishes accounts at survalyzer-eu.app and survalyzer-swiss.app. Both documented DKIM configurations use the TXT owner survalyzer2._domainkey, but the public keys differ. Copy only the public key belonging to the correct account region from the current provider instructions. Publishing both keys as competing records at that same owner is not a way to cover uncertainty.
For the custom MAIL FROM domain, the guide specifies sula.<your-domain>, with MX priority 10 targeting feedback-smtp.eu-central-1.amazonses.com and a TXT SPF policy v=spf1 include:amazonses.com ~all. These are records at the sula subdomain, not replacements for the main domain's receiving MX or its existing SPF policy. The retained instructions show this MAIL FROM endpoint alongside both regional DKIM sections; confirm the intended route with Survalyzer when onboarding rather than inventing a Swiss endpoint from the account hostname.
The minimum DMARC example is v=DMARC1;p=none at _dmarc.<your-domain>. If a policy already exists, review it instead of adding another. Monitoring policy does not request quarantine or rejection of failed authentication. Any move to enforcement must account for other legitimate senders and alignment, not merely the survey platform.
After the DNS team publishes the records, the documented final step is to inform Survalyzer so it can update the account. DNS publication alone is therefore not completion. Obtain confirmation that the intended sender is active, then send an authorized survey invitation to a controlled recipient. Inspect its real From, envelope identity and DKIM selector before declaring the setup ready.
The decision that matters
The data-center-specific key and provider-side activation are separate gates; both must be satisfied. Illustrative diagnosis: the Swiss account uses the EU public key at the shared selector name. A syntactically valid TXT answer does not establish that it verifies the actual signature. Resolve the account-region mismatch with Survalyzer rather than publishing two competing keys. Survey-domain consistency is a provider requirement; matching a hyperlink hostname is not itself a DMARC alignment test.
Verify the published records and the real sending path
References: RFC 7208 §3.3, RFC 9989 §4.4, RFC 6376 §6.
Record the change owner, sending product, domain, approved maintenance window and prior DNS answers before editing. Obtain the current record values from the named account or documented provider workflow. Separate values supplied by the provider from choices your organization controls, such as DMARC policy and reporting recipients. Existing mailbox MX, unrelated verification TXT records and active DKIM selectors are not cleanup candidates merely because a new service is being added.
Query the authoritative name servers for each exact owner and record type after publication. Record the query time, responding server and complete answer. Compare TXT strings as one logical value where the DNS response splits them into character strings. Check CNAME targets as well as the starting alias. Then compare a recursive-resolver answer to identify caching differences. A successful provider validation is useful evidence of configuration, but it does not establish what an actual recipient received.
Send only an authorized test to a controlled recipient using the intended product route. Retain the raw message and the trusted receiving system's Authentication-Results. Record the visible From domain, SMTP MAIL FROM or observed Return-Path domain, every DKIM d= and s= value, SPF and DKIM outcomes, and the receiver's DMARC result. A passing SPF or DKIM check supports DMARC only when its authenticated domain aligns with the visible From domain under the applicable policy. Reply-To and a branded display name are not alignment identities. RFC 7208, RFC 6376 and RFC 9989 provide the protocol basis for these distinctions.
Acceptance worksheet, recovery and evidence limits
This is an original acceptance worksheet, not a report of live testing. Mark each gate pending until evidence exists: account scope confirmed; previous DNS captured; exact new owner/type/value published; provider verification complete; intended route exercised; received identities recorded; aligned authentication confirmed; other senders unaffected. Assign a person and evidence file to every gate. A red gate blocks rollout even when the provider dashboard is green.
If a test fails, first distinguish missing publication, stale cached data, inactive provider configuration, wrong outbound route and nonaligned authentication. Correct the smallest demonstrated defect and test again. Do not weaken DMARC or delete other senders' records simply to make one test pass. If a change harms existing mail, use the approved recovery plan and the captured pre-change configuration, coordinating any provider-side sender change as well as DNS. Retain old keys while queued messages or an approved overlap still require them.
No customer tenant, authoritative before/after change or real received message was available for this manuscript. The retained sources support the documentary workflow; they do not satisfy the commissioned live-evidence gate. Independent checker review and human SME approval remain pending. Do not describe this guide as field-validated or publish it as having passed those gates.