Provider documentation checked on 8 November 2026. Account-generated values, entitlements and current support remain deployment prerequisites.
Decide who actually sends the survey mail
Expoints supports two documented routes for customer-domain mail: delivery by Expoints and forwarding through your own SMTP server. Choose the route before preparing DNS. A permission for Expoints infrastructure is not a substitute for the authentication configuration of your own relay. Record the survey owner, DNS administrator, certificate contact and person responsible for the receiving reply mailbox.
The provider's custom-domain documentation asks teams to settle the sender address, survey hostname and reply address together. It recommends using the same domain for the survey and sender. This is a branding and operational recommendation, not a protocol rule that every cross-domain link fails DMARC. DMARC evaluates authentication alignment, not whether a survey link has the same hostname as the sender.
Configure the Expoints-managed sending route
References: RFC 7208 §3.2, RFC 7208 §4.6.4, RFC 6376 §3.6.2.
Agree the approved sender domain with the Expoints Experience Manager and technical contact. The documentation identifies include:mailservers.expoints.nl as the SPF mechanism for Expoints delivery. Obtain confirmation of the intended DNS owner and current supplied values for your account. If an SPF policy already exists at that owner, integrate the required permission into that one policy after reviewing the existing senders and lookup budget. Do not create another SPF policy or replace a working policy with a sample.
Expoints documents that it can configure DKIM and asks which selector the customer wants. Coordinate a selector that does not conflict with another sender. Obtain the exact record type, owner and public key or target from the implementation team. There is no universal DKIM value established by this guide. Preserve the approved record and the final selector used by the service, then confirm that a received message actually contains the expected signature.
For the survey website, the documented flow uses a customer-specific Expoints target for a CNAME and a certificate based on a CSR supplied by Expoints. Treat these as separate web-hosting tasks. Do not confuse the survey CNAME with the DKIM record or infer mail authentication from a valid HTTPS certificate. Confirm existing uses of the chosen survey hostname before adding a CNAME.
Understand the customer SMTP alternative
On the own-SMTP route, Expoints passes messages to your server for onward delivery. The provider warns that mailing statistics are less complete because it cannot register bounces in this arrangement. Confirm who will monitor relay delivery failures, how failures reach the survey owner, and which transport signs the final message. Do not promise Expoints bounce statistics that the documented route does not retain.
Use the relay's current instructions for its authentication and access controls. Check both a generated survey invitation and the final received message. An SMTP acceptance response from the relay is only one stage in delivery; it does not prove that the destination mailbox accepted the message or that the final signature survived later processing.
Keep replies and authentication separate
Expoints says replies to the selected reply inbox need forwarding to Expoints for its handling. Agree this routing with the business owner before activation, because replies can contain customer information. Test a harmless reply and confirm the expected destination. A Reply-To address is not the SPF identity and does not supply DMARC alignment. Do not edit authentication records merely because reply forwarding fails.
Verify one complete invitation journey
References: RFC 9989 §4.4, RFC 9989 §5.3.5.
Create a controlled invitation through the exact chosen route. Save the original received message and record its visible From domain, envelope identity, every DKIM d= and s= value, and the trusted receiving system's authentication verdicts. Also follow the survey link and test the agreed reply path separately. These are distinct acceptance checks.
Illustrative identity case, not an Expoints observation: From is survey@example.com, SPF passes for relay.vendor.example.net, and a valid DKIM signature has d=example.com. SPF is not aligned to the visible sender, but the exact-domain DKIM signature supplies an aligned passing path. If the signature fails, the SPF result for the unrelated domain cannot rescue this example's DMARC result.
Troubleshoot and retain a recovery route
References: RFC 1034 §3.6.2.
Check the authoritative DNS owner and values before attributing a problem to propagation. Check accidental suffix duplication, conflicting CNAME data and the agreed selector. When DNS is correct but the signature is missing, investigate the selected transport and signing configuration. When authentication passes but placement is poor, investigate reputation and recipient handling separately; authentication is not an inbox guarantee.
Keep the prior DNS values and a known working sending route until the invitation, survey and reply tests are accepted. This guide retains documentary evidence only. No real tenant, DNS deployment or received-message test was performed; the production identity table and human approval remain required before rollout.