Scope the route to Alchemer Survey
This guide covers Alchemer Survey Email Actions and Email Campaigns using the documented custom email integration. It does not apply the same settings to every Alchemer product, report notification or export. The retained Set Up DKIM & SPF Records guide distinguishes sending through Alchemer's servers with a custom domain from sending through a separate SMTP integration. Establish which route the actual action or campaign uses before preparing DNS changes.
The source says the custom integration is available for Send Email Actions and Email Campaigns, not for emailing Reports or Exports. It also says only one of the SMTP and DKIM/SPF integration routes can be used for a given action or campaign. These scope limits are essential: a correct integration can exist without being used by the workflow under investigation. No Alchemer account was accessed and no integration was created in this work.
Confirm the owner and prerequisites
The guide requires an Alchemer Account Administrator for setup and coordination with the domain administrator or IT team for DNS publication. Record the business workflow, integration owner, intended From domain and DNS owner before collecting configuration values. A user who can edit a survey should not be assumed to have authority to authorize an external sending service for the organization's domain.
The guide describes a valid MX record as a prerequisite in this Alchemer setup and notes that missing MX data can prevent saving or generating the public key. Treat that as the documented product requirement, not a universal statement that SPF itself requires MX for every sender. RFC 7208 defines SPF's separate SMTP-identity and evaluation rules. Keep product validation conditions distinct from protocol requirements.
Select the documented Alchemer-server configuration
The retained guide directs an authorized administrator to Integrations, Data connectors, then Configure beside Custom Email Settings. It asks for a meaningful integration name and offers a default for new email invitations and actions. The Alchemer-server route is selected with the option to send emails using Alchemer's servers and set up SPF and DKIM. These are documented instructions, not a report that the current tenant displays or has completed them.
The configuration takes a Domain Name and Default From Address. The guide explains that the local part of the From address can be adjusted in an action or campaign while the configured domain cannot be changed there. Record the actual intended domain rather than assuming that an attractive sender display name controls authentication. A default for new workflows should not be treated as proof that every existing campaign uses the integration.
Obtain exact DNS values from the integration
The guide provides an SPF Entry within the integration and directs the administrator to generate DKIM public-key information. The generated DNS Domain Name and DNS Public Key must be retained from the actual authorized setup. Although the documentation illustrates a selector, this manuscript does not publish a tenant-specific key or assume that copied example data is suitable for a real account. Private signing material is not needed for the DNS review.
Review the existing SPF policy before incorporating the supplied entry. The provider instructions should not be interpreted as permission to create a second SPF policy at an owner that already has one. RFC 7208 requires selection of a single SPF record and defines errors for multiple SPF records. Prepare a complete intended diff preserving other approved senders and check the evaluated DNS-query-term budget rather than counting only the new visible entry.
Preserve DKIM record structure
The Alchemer guide warns that DNS editors differ in how they handle surrounding quotes and long public keys split into strings, and that extra quotation marks can invalidate the record. RFC 1035 defines TXT RDATA as one or more character strings. Several strings within one record are not several DKIM policies. The operator should compare published bytes with the generated public value rather than relying solely on an editor screenshot.
Record the exact owner, record type, value, TTL and affected zone in the proposed change. Do not overwrite an unrelated selector or remove existing authentication records just because they are not mentioned in this integration. The final public DNS state needs authorized observation after publication. No DNS lookup or write was performed for this manuscript.
Distinguish saving, verification and actual campaign use
The guide says Alchemer attempts validation when the integration is saved by sending a test email to one of its servers and reviewing the headers. It also says the integration must be verified before use and identifies a green check mark in the Verified column. Saving therefore has a documented message-sending side effect, not merely a local form update. An authorized operator must understand that behavior before executing it; this work did not save or trigger validation.
A particularly important exception is the Email Campaign Test Link. The source states that this link does not use the DKIM/SPF information and comes from Alchemer. It directs users to use a live campaign for testing that custom route. This manuscript does not send such a campaign or authorize recipient contact. The acceptance plan must identify an approved recipient and the exact production-like route before any later test is performed.
Build a received-message identity table
For an authorized sample, retain the action or campaign identifier, selected integration, sending time and trusted receiving system. Record the visible From domain, envelope identity, DKIM signing domain, selector, SPF result, DKIM result and DMARC alignment result. RFC 8601 explains why Authentication-Results needs a trusted receiver boundary; a copied pass line without provenance is insufficient.
RFC 9989 defines alignment to the visible From domain. A successful SPF or DKIM result is useful only in its actual identity context. The provider's Verified status and a real received-message table answer different questions and should both be retained. Neither guarantees inbox placement or validates the human intent behind the message.
An integration acceptance worksheet
Create a worksheet with Alchemer Survey scope, action or campaign, selected route, integration name, intended From domain, account owner, DNS owner and exact generated public records. Add existing-state evidence, approved diff, provider verification status and the received-message table. Include a specific check that the sample did not come from the excluded Test Link path or from a Reports/Exports notification.
If verification fails, separate missing MX prerequisite, DNS publication mismatch, key formatting, cached answers and wrong integration selection. Do not infer the cause from one red status without retaining the supporting evidence. The guide's propagation guidance describes possible delay, not permission to label an unobserved record correct. Record actual observation times and retry only under an authorized operational plan.
Fictional diagnosis: a test link gives the wrong identity
A fictional survey administrator configures a custom integration, then uses the campaign Test Link and sees an Alchemer-owned From identity. The administrator assumes the DKIM setup failed. The documented route exception offers a different explanation: that test path does not use the custom DKIM/SPF integration. The next step is to confirm the route before changing DNS or generating another key.
An authorized later sample from the intended campaign would be evaluated separately. This example is fictional; no campaign, key, DNS record or received message was observed. It illustrates a product-specific diagnostic distinction rather than a completed configuration.
Release status
The catalogue requires current first-party setup evidence and a received-message identity table from the exact product and route. Documentary setup evidence is retained, but tenant applicability and the original received-message table remain open. All six release gates remain open. This draft is not a claim that Alchemer was configured or tested, and no sending, credential generation or publication occurred.