Bound the guide to Cvent’s documented SPF-only release
Cvent's Plan & Promote announcement for the June 3, 2026 release describes self-service setup for custom planner and envelope domains. The page is dated May 19, 2026 and explicitly labels the feature SPF Only. This guide covers that documented workflow. It does not assert that every Cvent product, account or later release has the same controls, and it does not convert a roadmap statement into a deployed DKIM feature. Current account applicability must be confirmed before implementation.
The official release announcement gives administrators a concrete sequence for adding domains, obtaining DNS records and verifying them. Its final notes say DKIM-based authentication is an upcoming phase. Consequently, this article can support a bounded SPF-based domain-setup guide while leaving broader DKIM implementation and current rollout status unresolved. A separate acceptance requirement must not be marked complete simply because the account can use a branded sender.
Define planner and envelope domains before entering them
The release distinguishes planner domains from envelope domains and allows a corresponding envelope domain to be added during setup. Treat those as different identity roles in the review. Record the intended visible author domain, the envelope domain supplied by the account workflow and the message categories that will use them. Do not assume the two names are identical or aligned merely because both belong to the same organization. Actual message evidence is needed to establish how the selected configuration is used.
Before creating a new configuration, identify the business owner, DNS owner and current account administrator. Inventory existing event communications that might depend on the same domain or envelope configuration. Include invitations, registration-related messages and other applicable categories only where the actual account uses them; this document does not assert a universal mapping of every Cvent feature. The proposed change should explain what is being added, which existing records could conflict and how a previous working configuration would be restored.
Follow the supplied domain and DNS workflow
The announced path is Admin, Data Lists, Planner Domain, then Add New Domain. After the domain is saved, Cvent supplies required DNS records described as CNAME/TXT. Use the exact issued names, types and values for the intended account and domain. The release does not provide a universal record count, fixed selector or reusable target, so none should be invented from another customer's configuration or an unrelated email platform.
Have the authoritative DNS administrator compare each proposed owner with the actual published name. Some editors append the zone suffix, and an input that looks fully qualified can accidentally produce a duplicated suffix. Existing CNAME and TXT data need a conflict review before adding or replacing records. Preserve the account-generated record set, approval and previous values in a controlled change record. A screenshot of the entry form is useful context, but it is not proof that the expected public records were published.
The announcement says to return to the domain setup page and verify after DNS changes have propagated. Verification is a provider check for this configuration. Record the actual result and time, along with unresolved errors. Do not call a pending state successful because the change was submitted, or assume a wrong record will become correct after waiting. The guide does not establish a universal propagation deadline, and this manuscript does not provide one.
Understand what SPF can establish
RFC 7208, section 2.4 identifies MAIL FROM as an SPF identity. SPF evaluates whether the sending host is authorized for that identity; it does not authenticate a planner's display name or automatically establish the visible author domain. A DNS verification token can also be a TXT record without being an SPF policy. Keep the purpose of each account-issued record explicit instead of treating every TXT value as interchangeable.
Review the complete applicable SPF policy and preserve legitimate senders. RFC 7208, sections 3.2 and 4.6.4 describe multiple SPF records and evaluated DNS-dependent term limits. A Cvent-generated instruction should be reconciled with the existing zone rather than pasted as a second competing policy. The release does not establish a universal Cvent include to add at every organizational root, so this article supplies none. The actual account's issued values and identity arrangement must govern the approved change.
Separate domain verification from DMARC alignment and DKIM
RFC 9989, section 4.4 explains the alignment relationship between the author domain and a passing authentication identity. A successful SPF result is not enough if the relevant domains do not align under the applicable mode. Conversely, DMARC does not universally require both SPF and DKIM to pass; a passing aligned mechanism can satisfy its authentication condition. Evaluate the actual identities rather than using a provider status label as a substitute for receiver evidence.
The June release's promised future DKIM phase must remain separate from the SPF-only workflow documented here. Do not manufacture selectors, signing-key steps or a claim that the feature is now deployed. Equally, do not turn the bounded source into a universal claim that Cvent cannot support DKIM in any product or later release. The defensible conclusion is narrower: this release document does not establish a current DKIM implementation procedure for the account being assessed.
Plan acceptance around real event-mail routes
A separately authorized acceptance exercise should use harmless test content and a known recipient, then inspect trusted receiver authentication results. Record the sending route, author domain, envelope domain, SPF result and alignment outcome. If a signature is present, record its actual domain and selector without assuming it came from the workflow described in this release. RFC 6376, section 3.5 defines those signature fields.
Different event or account configurations may need separate evidence. A successful sample for one planner domain should not automatically close acceptance for another. Keep DNS agreement, provider verification, message authentication and business delivery outcomes in separate fields. Authentication does not guarantee inbox placement, attendee attention or registration completion. No event email, tenant setting, external diagnostic upload or DNS query has been performed for this manuscript.
Fictional diagnosis: a roadmap sentence became an acceptance claim
A fictional conference team, Stonebridge Forum, completes the announced planner-domain workflow and sees a successful verification result. Its project checklist then marks both SPF and DKIM complete because a colleague remembers reading that DKIM was planned. The reviewer checks the release scope and finds that the documented procedure is explicitly SPF-only and that no actual signature evidence has been retained.
The proposed correction is to preserve the verified domain work while reopening the unsupported signing claim. The team should obtain current account-specific documentation and authorized message evidence before deciding whether an additional DKIM configuration is available or required. It should not delete a functioning domain setup or add guessed selector records. This fictional example demonstrates evidence separation, not an observed Cvent defect or real tenant incident.
Blank acceptance worksheet and open release gates
- Cvent product, account and applicability of the June 3 release: ______
- Planner domain, envelope domain and intended message categories: ______
- Issued CNAME/TXT set and purpose of each record: ______
- Authoritative DNS owner, conflicts and approved change reference: ______
- Complete SPF policy and dependency-review evidence: ______
- Provider verification state and observation time: ______
- Trusted message-level identities and alignment results: ______
- Separate current DKIM documentation or unresolved implementation scope: ______
- Rollback owner, remaining exceptions and release decision: ______
Original implementation evidence, human subject-matter review, current source applicability, production-route testing, visual accessibility and owner release remain open. The broader catalogue requirement remains subject to those gates. This guide establishes a documentary, SPF-only release scope and does not claim a completed tenant deployment or a verified present-day DKIM rollout.