Survalyzer SPF, DKIM and DMARC setup, step by step

For Survalyzer-managed invitations sent from your own domain, publish the DKIM TXT record for your account's EU or Swiss data center, configure the documented sula custom MAIL FROM subdomain, and ask Survalyzer to activate the domain. Then verify a newly delivered invitation. The custom-domain workflow requires the Corporate Package. Survalyzer custom email domain instructions

This guide is based on published documentation, not a customer-account configuration or live delivery test. DNS checks and message tests below are steps for your administrator to perform.

Choose the right sending route

This guide covers Survalyzer's managed custom-domain route. It does not configure an independent Amazon SES account or replace your organization's mailbox service. The company that hosts your website may not host the authoritative DNS zone; make the changes wherever those authoritative records are maintained.

Survalyzer also documents a customer mail-relay option. That route has sender-address and wildcard routing rules and uses a Survalyzer envelope identity for bounce handling. Do not apply the managed-route records below to that relay without its agreed configuration. Its SPF, DKIM and bounce-handling responsibilities must be established with the mail administrator and Survalyzer. Survalyzer mail relay

The relay documentation estimates about two weeks for setup and notes additional cost. It also identifies a possible account-wide bounce-handling consequence if your infrastructure rejects Survalyzer's envelope sender. Review that consequence with both administrators before choosing the route; do not disable bounce handling as an authentication workaround. Relay prerequisites and limits

The provider's sending policy requires Corporate Package customers to use both a custom email domain and a custom survey domain. Check the survey's Distribute → Survey links view and the intended invitation branding. This brand-consistency requirement is separate from DMARC's cryptographic and domain-identity checks. A matching survey hyperlink cannot make an unaligned signature pass DMARC. Survalyzer sending policy

Prerequisites and change worksheet

Before editing DNS, collect:

• The intended From address and the domain after its @ sign.
• The actual account hostname, including survalyzer-eu.app or survalyzer-swiss.app.
• The account's Corporate Package entitlement and a contact who can confirm activation.
• Access to the authoritative DNS zone and a copy of all affected records and TTLs.
• The current DMARC policy, alignment settings, legitimate senders and mail-owner approval.
• A controlled survey/sample containing only authorized test recipients, plus a recovery owner.

In the examples, example.com represents the selected sending domain. If you send from research.example.com, use that full domain in the record names, not automatically the organization's apex. Save the before-and-after values so a failed change can be reversed without disturbing another sender.

Configure the regional DKIM record

The current instructions assign the TXT owner survalyzer2._domainkey and publish different public-key values for EU and Swiss accounts. Select the section matching the actual account hostname and copy its complete current value directly from the official page or your account-specific instructions. Do not combine both keys, use a search-result fragment, or obtain a private signing key. Regional DKIM configuration

Use this publication procedure:

1. Open the authoritative zone for the selected sending domain.
2. Check whether the full owner, such as survalyzer2._domainkey.example.com, already exists. If it serves another active configuration, stop and resolve the collision with Survalyzer.
3. Publish one complete provider-issued DKIM TXT value at that owner. Check whether your DNS editor expects a relative name or automatically adds the zone suffix.
4. Save and query the resulting full name. If the DNS interface splits a long TXT value into character strings, they must remain parts of one logical record, not competing key records.

A public key in DNS is necessary but does not prove that the platform is signing with the matching private key. The delivered-message check is the evidence for that. DKIM DNS and verification specification

For sending domain research.example.com, the full DKIM owner is survalyzer2._domainkey.research.example.com: enter survalyzer2._domainkey.research in the parent example.com zone, or survalyzer2._domainkey in a separately delegated research.example.com zone. If _domainkey.research.example.com itself is delegated, enter only survalyzer2 in that authoritative namespace. For _domainkey.example.com, the apex signing key similarly uses relative name survalyzer2. Preserve existing NS delegations and query the authoritative service rather than publishing a shadow parent-zone record. DNS authority and delegation.

Configure SPF on the custom MAIL FROM subdomain

Survalyzer documents the following two records for the managed route. Replace only example.com with the agreed sending domain; confirm any account-specific exception before changing the target. The published MX endpoint appears after both regional DKIM sections, so do not invent a Swiss endpoint by altering its region name. Survalyzer MAIL FROM records

Before publishing or activating this route, obtain the mail-routing owner’s separate approval of the exact full MAIL FROM owner and the complete numeric-priority/MX-target set, plus the matching SPF policy. A provider packet establishes required values, not permission to redirect mail. For From research.example.com, the full owner is sula.research.example.com, entered as sula.research in the parent zone or sula in the delegated child zone. Preserve normal mailbox MX and resolve existing use of that owner first.

These records belong at the MAIL FROM subdomain, not at the main domain. Do not replace your normal receiving MX or root SPF policy. Enter MX priority separately if the DNS editor has a dedicated priority field. If sula is already a CNAME or is used for another service, resolve that conflict before proceeding; a CNAME cannot coexist there with the required ordinary MX and TXT data.

The MX record handles bounce-related traffic for the envelope identity. It does not create a staff mailbox. Amazon SES explains why custom MAIL FROM requires its own MX and SPF records and why the subdomain must not also be used for ordinary sending or receiving. Survalyzer administers this service-side route; its customers should not create a separate SES identity as a workaround. Amazon SES custom MAIL FROM

SPF is evaluated against the envelope MAIL FROM identity, not the visible From address. Maintain one SPF policy at each evaluated owner. Where an owner has a legitimate existing use, do not add a second v=spf1 record or silently replace its policy. Have the owner resolve the service conflict. Evaluate the final policy's maximum of ten DNS-dependent terms, including nested include and redirect processing; counting only the includes visible in the first line is insufficient. SPF specification, sections 3.2 and 4.6.4

Any all mechanism makes redirect= ignored, regardless of term order. If an existing policy relies on redirect, identify its legitimate senders and preserve the approved authorization and qualifier through a reviewed design rather than appending all blindly. SPF precedence.

Preserve DMARC and request provider activation

Read the policy applicable to the visible From domain. Survalyzer shows a minimum p=none example, but that is not an instruction to weaken an existing quarantine or reject policy. If no policy exists, the domain owner can plan a monitored introduction with an approved reporting destination. Do not add a duplicate policy or copy somebody else's reporting address.

Only when no direct or applicable inherited policy exists and the domain owner approves an appropriate monitoring plan, an illustrative first record is TXT at _dmarc.example.com with value v=DMARC1; p=none. Enter relative name _dmarc in the example.com zone. For a deliberately separate research.example.com policy, use full owner _dmarc.research.example.com, relative _dmarc.research in the parent zone or _dmarc in the delegated child zone. These examples are not an instruction to override existing protection; add reporting only after the separate approval and authorization checks below.

Before adding or changing aggregate reporting through rua, approve the recipient or processor and its handling of domain-level authentication data. For an external destination under a different Organizational Domain, have the reporting service establish the required DNS authorization; adding its address to your policy alone is insufficient. Restrict access and retention according to your organization's requirements and review the processor's privacy terms. Aggregate reporting is distinct from sharing raw messages or enabling failure reports, which can expose different information. DMARC aggregate reporting, RFC 9990, sections 4 and 7

Compare the destination host’s Organizational Domain with the Organizational Domain of the domain where the DMARC policy was found, which may be a parent rather than the visible From domain. If they differ, the receiver generating reports must perform the external destination DNS authorization check; the same-Organizational-Domain case is excepted. A different hostname alone is not external for this rule. This protocol check does not replace the owner’s data-sharing approval. RFC 9990 section 4.

DMARC passes when at least one authenticated identity aligns: SPF's MAIL FROM domain or a passing DKIM signature's d= domain. Relaxed alignment compares Organizational Domains; strict alignment requires identical domains. Thus, with From example.com and MAIL FROM sula.example.com, the illustrated SPF path can align under relaxed aspf=r, but not strict aspf=s. Aligned DKIM can still provide DMARC success. These are conditional protocol examples, not observed Survalyzer results. Current DMARC specification, RFC 9989

After publication, notify Survalyzer so it can update the account, as required by the official workflow. Obtain confirmation for the exact domain and route, rather than treating a saved DNS record as activation. Ask what DKIM signing domain and MAIL FROM domain should appear on the resulting invitations. Provider confirmation step

Verify DNS before sending a test

Replace example.com and ns1.example.net below with your sending domain and an authoritative server for the relevant zone. These read-only examples are not results from a configured account.

dig +short NS example.com
dig @ns1.example.net survalyzer2._domainkey.example.com TXT +noall +answer
dig @ns1.example.net sula.example.com MX +noall +answer
dig @ns1.example.net sula.example.com TXT +noall +answer
dig +short TXT survalyzer2._domainkey.example.com
dig +short MX sula.example.com
dig +short TXT sula.example.com
dig +short TXT _dmarc.example.com

Accept DNS publication only when:

• The DKIM TXT value matches the complete current key for the selected data center.
• The MAIL FROM owner returns the approved MX preference/target and exactly one applicable SPF policy.
• Authoritative and recursive answers agree after relevant caches expire. Record TTLs and check times instead of assuming a universal propagation delay.
• DMARC remains consistent with the approved domain policy. An empty direct _dmarc lookup does not prove no inherited policy applies.

Do not substitute a successful domain scan for the next step. A scan cannot show which sender identity the live invitation actually used.

For the MAIL FROM MX, compare the entire authoritative and recursive numeric-priority/target set with the separately approved routing plan. Stop on any extra, missing or different tuple; a nonempty answer or one matching target is insufficient. The documented SES custom MAIL FROM arrangement requires exactly one MX, not an additional mailbox fallback. Preserve unrelated incoming-mail routes. SES MAIL FROM requirements.

Validate an actual invitation

In the invitation workflow, check the Sender e-mail address and the separate Reply e-mail address. Use Send test mail with a controlled address for an initial check, then exercise the intended distribution route with an isolated, approved sample. A template preview alone does not establish production-path authentication. Survalyzer invitation workflow

Retain a new raw message from a receiver you control and complete this table:

Require both the intended branded DKIM pass with alignment and a trusted receiver's DMARC pass before accepting this custom-domain setup. DMARC can pass through SPF while branded DKIM remains broken, so its overall result must not hide that unfinished configuration. Likewise, investigate actual SPF fail, softfail, permerror or temperror even when aligned DKIM supplies DMARC success.

Establish which receiver actually generated the results and is authorized to assert them for this delivery. Use receiver-controlled diagnostics and the mail administrator's verified trust boundary and inbound-header handling. A familiar authserv-id or a header's position alone is not proof: forged results can impersonate a receiving domain. If provenance is uncertain, ask the receiving administrator to confirm it before accepting the test. Preserve evidence securely and redact personal content before sharing diagnostics. RFC 8601, section 7.1: forged authentication results

Troubleshooting and recovery

Amazon SES supports either fallback to its default MAIL FROM domain or rejection when custom MAIL FROM MX validation fails. This guide does not establish which option Survalyzer has configured for your account. An unexpected envelope domain needs investigation even if mail arrives. SES failure behavior

For missing invitations, Survalyzer recommends checking bounce statistics after at least 30 minutes and escalating unexplained prior-bounce exclusions. Its sending policy also excludes opted-out recipients. Authentication fixes do not authorize reversing an unsubscribe. Delivery troubleshooting and sending policy

If a change disrupts sending, pause the affected distribution and coordinate the provider setting with restoration of the recorded DNS values. Do not delete old keys while valid queued messages may still need them. Keep unrelated mail records and DMARC enforcement intact. Repeat DNS and message tests before resuming volume. Authentication is necessary evidence, not an inbox-placement guarantee.