LivePerson SPF, DKIM and DMARC setup, step by step

For LivePerson Conversation Builder's documented post-conversation survey email route, request backend SPF/DKIM provisioning and the domain's DNS records from your LivePerson representative. The published SPF mechanism is include:sendgrid.net; the DKIM records must come from LivePerson. Then configure the survey bot's Email Transcript option and approved sender identity, and verify an actual native transcript email. DNS publication, backend readiness and the transcript offer are separate checkpoints. LivePerson's post-conversation survey instructions

This guide is for an existing, enabled survey bot on the LivePerson platform, accessed through Conversational Cloud single sign-on, in Messaging. It does not cover Live Chat, direct Conversation Builder access on Google Cloud Platform, a generic Email Integration, marketing campaigns or every service sold by LivePerson. No account operations, DNS changes or test sends were performed to prepare this guide.

On this page: Confirm the survey-email route and permissions · Request the domain-specific packet from LivePerson · Review and update SPF without replacing other senders · Publish the issued DKIM records in the authoritative zone · Enable the transcript offer and approved sender · Preserve DMARC and approved reporting · Test the actual native email without customer data · Troubleshooting by the failed checkpoint · Frequently asked questions

Confirm the survey-email route and permissions

LivePerson documents that survey bots must first be enabled by its representative. Start with a feature and bot your organization already uses and is authorized to administer. Confirm the correct brand, account, environment, bot and skill before changing anything. Access to a bot editor is not, by itself, permission to alter production conversation routing or disclose conversation content.

The documented email workflow sends a transcript after the main conversation, with an opportunity for the consumer to accept or decline. It is not simply a sender-address field on a normal mailbox. Establish the approved sender domain, display name, recipient-consent behavior and privacy requirements for this specific transcript route.

For development and testing, use an already approved nonproduction environment or an isolated test skill that is not used in a production campaign. A survey bot becomes active with its assigned skill once the supporting feature is enabled; the documentation says there is no separate manual survey-bot deployment step. Do not assign a production skill as a way to “try” email authentication. Scope, prerequisites and deployment behavior

Before proceeding, confirm:

• The representative can provision the specific outgoing email backend for this account and domain.
• The domain owner approves the DNS and sending-authority changes.
• An authorized administrator can access the actual authoritative DNS zone, including any separately delegated subdomain.
• The person making bot changes has the appropriate existing access and approval for the sender identity and transcript offer.
• A controlled external mailbox and synthetic, non-sensitive conversation are available for an explicitly approved test.

If the feature or controls are unavailable, ask the account owner and LivePerson to establish eligibility. This guide is not permission to buy a feature, create a new connection, expand access or change subscription terms.

Request the domain-specific packet from LivePerson

Contact your LivePerson representative through your organization's established support channel. The official process asks for an administrator email address and the domain to authenticate. Its wording mixes “DNS host” with an example domain name: avoid that ambiguity in the request. Identify the sending domain separately from the authoritative DNS provider and zone, and confirm the intended account and transcript-email route.

LivePerson then configures a backend outgoing server supporting SPF and DKIM and sends the required DNS records to the administrator. Use that packet, not a selector copied from another account or a generic SendGrid setup tutorial. The use of SendGrid infrastructure does not mean you should create your own SendGrid account, API key or unrelated domain-authentication object. Representative provisioning and record issuance

Have the packet identify each record's complete owner, type, value or target and purpose. Ask which domain the intended DKIM signature will use and how the representative confirms the account's domain is ready to sign. Also confirm which actual MAIL FROM domain the SPF instruction applies to. The public instructions do not establish a universal DKIM selector, fixed record count, universal Return-Path, region or self-service verification badge.

Distinguish the inputs:

Only public DNS material belongs in DNS. Do not request, upload or publish a private signing key. If a packet unexpectedly includes MX, NS, A records, tracking routes or forwarding instructions, stop and compare those destinations and consequences with a separately approved routing plan. Do not activate them merely because they appear beside authentication records.

Review and update SPF without replacing other senders

LivePerson documents include:sendgrid.net for this representative-provisioned transcript backend. SPF evaluates the SMTP MAIL FROM domain, or HELO in the relevant case, not automatically the visible From address. Confirm the actual owner before editing an apex or subdomain policy. LivePerson SPF instructions, SPF specification

Read every TXT answer at that owner and identify any policy beginning v=spf1. There must be one SPF policy at that evaluated owner. If a policy exists, reconcile the required mechanism into it while preserving the other legitimate senders and the approved terminal qualifier. Do not create a second SPF record, replace a working policy wholesale or add authorizations solely because they appeared in an example.

For a domain whose only authorized sender at the confirmed SPF owner is this documented route, LivePerson's example is:

v=spf1 include:sendgrid.net -all

This is a conditional sole-sender example, not an instruction to overwrite your domain's existing policy. If the policy uses redirect, do not casually append an all: any all mechanism suppresses redirect. Check the whole evaluated policy, including nested mechanisms, against SPF's limit of ten DNS-dependent terms. That is not a limit of ten literal include strings.

Keep the existing enforcement choice unless the owner has approved a change based on the full sender inventory. Qualifiers do not guarantee a particular delivery outcome. Publishing this SPF mechanism also does not guarantee SPF alignment: the actual message's MAIL FROM must be compared with its visible From under the effective DMARC policy.

Publish the issued DKIM records in the authoritative zone

Record the current DNS values and proposed changes before saving anything. Identify authority from actual delegation, not from the registrar's brand or an assumption that the website host controls email DNS. Publish exactly the record types and public values provided for your account.

For an illustrative issued owner selector._domainkey.example.com, a DNS interface that appends the example.com zone would normally need selector._domainkey. For selector._domainkey.mail.example.com, the relative name is selector._domainkey.mail in the parent zone, but selector._domainkey in a separately delegated mail.example.com zone. These are owner-mapping examples, not LivePerson-issued selectors.

Check for an existing _domainkey delegation, an active selector used by another service, or a conflicting record at the exact owner. Do not remove a delegation, replace an active key or delete historical selectors without confirming their dependencies and an approved rotation plan.

If the issued record is TXT, preserve the complete tagged public value and verify the logical TXT string without truncation. A DNS system may represent one long TXT value as multiple quoted character strings; that is different from creating unrelated competing records. If the packet instead requires CNAMEs, preserve every exact owner-to-target pair and do not place a competing TXT, A, AAAA, MX or another CNAME at the same owner.

On hosts with HTTP proxying, authentication CNAMEs need DNS-only handling. Where literal CNAME answers are required, a relevant per-record flattening option must be off and applicable zone settings must not hide those aliases. Check zone-wide flattening and mandatory apex or same-zone behavior too. If the host cannot preserve the required answer, stop and coordinate a supported configuration; do not switch off shared settings globally or remove a delegation as a workaround. Cloudflare's documented flattening controls

Read the published records from authoritative DNS and check recursive answers after relevant caching. LivePerson says verification may take up to 48 hours. Treat that as provider guidance, not a deadline or proof of success. Ask the representative to confirm the exact domain's backend readiness if it remains unclear. The source does not name a public “Verified” badge or a second universal DKIM-enable switch, so do not invent either. DNS verification guidance

Enable the transcript offer and approved sender

After DNS and provider readiness are established, configure only the intended existing bot under the approved change plan:

1. Open the correct bot and select the three-dot menu near the upper-left menu bar.
2. Open Bot Settings, then More Settings.
3. Enable Email Transcript and save the bot settings using Save.
4. Configure the added Email Transcript interaction, including the approved Sender Name and Sender Email. The official screenshot marks both fields as required. Use the domain covered by the provider's packet; do not use an unrelated address just because the field accepts text.
5. Preserve the consumer's choice to accept or decline the emailed transcript. Keep the interaction in the supported end-of-dialog position and retain the documented Close Dialog behavior for this existing flow.

Bot settings and Save, Email Transcript interaction and sender fields

Do not confuse saving a bot setting with proving DKIM signing. Conversely, do not assume DNS changes alone will create or enable the transcript offer. Reopen the intended settings to confirm they persisted and that the correct sender is still selected before the authorized test.

The source distinguishes individual bot settings from account-level survey configuration, which can affect all survey bots and require connector redeployment. Do not change account-level targeting, sampling, session behavior, logging, production skills or connectors as incidental authentication work. Removing the Email Transcript interaction can disable its setting; avoid deleting or rebuilding the flow to troubleshoot a DNS problem.

Preserve DMARC and approved reporting

Inspect the visible From domain's direct policy and any applicable inherited policy. A missing child-domain TXT record does not mean the domain has no protection. Preserve established enforcement, alignment modes and report destinations. Do not replace a working policy with p=none or weaken alignment just to obtain a green test. Current DMARC requirements

If no applicable policy exists, arrange a separate owner-approved monitoring rollout with the appropriate DNS administrator and a plan to review all legitimate senders. Map the policy owner correctly: _dmarc.example.com becomes _dmarc in the example.com zone; _dmarc.mail.example.com becomes _dmarc.mail in its parent zone or _dmarc in a separately delegated mail.example.com zone. This transcript guide does not automatically create a new policy.

Aggregate-report recipients receive authentication reports, not quarantined email bodies. Compare the Organizational Domain of the report URI destination host with that of the domain where the policy was found, including an inherited policy. When they differ, the report-generating receiver checks DNS authorization for the external reporting destination. The same-Organizational-Domain exception uses that policy-found domain. DNS authorization does not replace the owner's approval to share report data. RFC 9990 section 4

Do not add failure reporting, unapproved recipients or obsolete percentage-rollout tags as part of enabling transcript email.

Test the actual native email without customer data

Use an approved isolated test skill and a synthetic conversation with no real customer information. Obtain approval for the test recipient and transcript content. Use a mailbox controlled by an authorized tester on an independent receiving system, and have the test participant explicitly accept the transcript offer. Do not use a real customer conversation, change its status or send its transcript for diagnostics.

The documented survey flow starts when the relevant conversation ends and its last skill matches the survey bot. Do not treat an editor preview as an end-to-end mail test. Exercise the actual intended native route in the safe test environment, without assigning a production skill or redeploying a production connector. Survey triggering and safe test-skill guidance

Inspect the full received headers and preserve a sanitized result. Use Authentication-Results produced inside the receiving service's known processing boundary, with its documented handling of externally supplied results. A familiar authserv-id string or a header's position alone does not prove trust. Ignore attacker-supplied result fields; obtain help from the receiving mail administrator if you cannot identify the trustworthy evaluation. Authentication-Results trust boundaries

Relaxed DKIM alignment compares Organizational Domains; strict alignment requires exact domain equality. SPF alignment separately compares MAIL FROM with From under aspf. A child envelope does not automatically satisfy strict alignment with its parent From. Do not promise strict alignment from a provider's generic configuration.

An SPF-only DMARC pass cannot validate this DKIM setup. Neither can an unrelated gateway's passing DKIM signature, a DNS lookup alone or delivery to the inbox. Retain the expected selector, signing domain, actual envelope identity, receiver results and timestamp without exposing transcript contents. See raw DKIM results versus aligned policy results.

Troubleshooting by the failed checkpoint

Stop if the change would require wider permissions, production routing changes or sharing real transcripts. Preserve previous records and account settings for an approved rollback. Never remove a key or shared DNS dependency merely because one test failed.