Scope the Cision Communications Cloud route
Cision's “Setting up SPF and DKIM” article, published on 7 October 2024, explicitly addresses Communications Cloud sending through an organization's domain. Its concrete implementation instructions describe support-assisted DKIM: the organization supplies the full sending domain, Cision prepares the authentication data, the domain's DNS administrator publishes the supplied CNAME records, and Cision verifies the result. This is the product route covered here. It is not a universal configuration for every Cision, Brandwatch, PR Newswire or agency integration. Current account applicability and actual generated records remain unverified. Cision setup guidance
Start by naming the account, the Communications Cloud message category and the domain proposed for the visible From address. Record whether the organization owns that domain or uses a client's identity. The person operating a campaign may not control its DNS, and a commercial relationship does not automatically authorize publishing authentication records. Identify the domain owner and obtain the appropriate change approval before any implementation step. This guide proposes that review; no account or customer domain has been accessed.
Agree on the domain before requesting authentication
The provider says it needs the full domain to be used and allows the ordinary organizational domain or a separately arranged subdomain. Treat that choice as a scope decision, not a cosmetic label. A subdomain can help document a distinct route, but it still requires an owner, a DNS publication plan and a review of the identities actually used by outgoing messages. Do not invent a particular subdomain name or assume the provider will authenticate every descendant of the chosen domain. Cision setup guidance
Prepare a concise internal handoff identifying the approved sending domain, business owner, Cision account context and DNS operator. Keep private credentials and message content out of that handoff. The subsequent support exchange should request the current records for the precise account and domain, rather than ask whether a copied example looks plausible. This manuscript supplies no Cision selector, CNAME target or record count because the retained instructions do not establish reusable values.
The guide describes Cision preparing authentication on its side before the customer publishes the records. That ordering matters: a DNS administrator cannot complete the service-side provisioning merely by creating an arbitrary DKIM-looking name. Conversely, support preparing a record does not establish that the authoritative zone now serves it. Maintain separate checkpoints for provider preparation, authorized DNS publication and provider verification. Cision setup guidance
Handle agency and customer ownership explicitly
Cision specifically addresses agencies sending with a customer's email address. It says the customer's IT organization must publish the authentication in the customer's DNS. If that is not possible, the provider recommends using the agency's own domain instead. This is a meaningful identity change, not a workaround that preserves the customer's original authenticated identity. Obtain approval for the address recipients will see and for how replies should be handled. Cision setup guidance
Create one ownership row per customer domain. Include the authorized requester, DNS approver, responsible account and offboarding contact. Avoid grouping several unrelated customers under a single assumed authorization. When an engagement ends, review which authentication dependencies remain active and coordinate their retirement with the provider and domain owner. Do not delete records while another approved route still depends on them. These are proposed lifecycle controls, not assertions about a particular Cision tenant's automation.
Publish the supplied records without guessing
The DNS operator should compare each supplied CNAME owner and target with the intended complete domain names. Record the fully qualified owner separately from the string entered into the DNS editor. Editors differ in whether they append the zone suffix or expect a complete name. A record that looks visually familiar can still be published under the wrong owner if the suffix is repeated. Keep the approved source instructions with the proposed change rather than reconstructing them from memory. RFC 1035, section 5.1
For DKIM, the message's selector and signing domain guide the receiver to the public verification material. A record's presence does not itself prove that a message was signed, that the corresponding key was used or that the signature survived subsequent processing. The proposed acceptance plan therefore links the provider's record set to actual received-message identities when authorized evidence becomes available. Do not substitute an arbitrary selector lookup for examining the signature on the intended route. RFC 6376, sections 3.5 and 3.6.2.2
The Cision article's title mentions SPF, but its concrete setup sequence does not supply a general SPF include or tenant-specific envelope configuration. Do not fill that gap with values from another Cision product or an unrelated third-party recipe. Request applicable sender authorization information for the actual route and reconcile it with the domain's existing legitimate senders. The broader catalogue configuration requirement remains open until those details and implementation evidence are established.
Keep SPF, DKIM and DMARC identities separate
SPF evaluates the applicable SMTP MAIL FROM or HELO identity, rather than directly validating the visible author address. Publish SPF as TXT and maintain one applicable policy for the identity. Adding another independent SPF policy does not merge permissions and can produce a permanent error. Where a new authorization is proposed, review the evaluated dependency path and DNS-querying term limit rather than counting only the includes visible in the first record. RFC 7208, sections 2.3–2.4, 3.1–3.3 and 4.6.4
DKIM verification establishes a signature result associated with its signing domain. DMARC then considers whether a qualifying passing SPF or DKIM identifier aligns with the visible From domain. These assessments should remain separate columns in the acceptance record. A provider verification status is not a received-message DMARC result, and a passing but unrelated signature is not sufficient by itself. RFC 6376, section 3.5 RFC 9989, section 4.4
Do not interpret a spam-folder outcome as proof that authentication is the only defect. Authentication can contribute useful evidence while reputation, content, recipient behavior and local filtering decisions still affect treatment. Cision's deliverability discussion should not become a guarantee that publishing its records places every press communication in an inbox. Likewise, an authenticated domain does not establish that the message's factual assertions or business request are safe. RFC 9989, section 2.4
Fictional diagnosis: the client domain was never approved
Consider a fictional agency, Harbor Press Office, preparing Communications Cloud announcements for a client. The campaign operator selects the client's visible address but sends the DNS request to the agency's own administrator. That administrator can edit the agency zone, not the client's. A proposed completion note says authentication is ready because a similarly named record exists in the agency domain. This is an invented review scenario, not an observed incident or a test result.
The review identifies the ownership mismatch before publication. The client either authorizes its own DNS team to implement the account-specific record set or approves a different sender identity using the agency domain. The team preserves the distinction in its campaign and reply plan. Provider verification and received-message evidence remain pending; nobody treats a record in the wrong administrative domain as proof of the requested identity.
Blank acceptance worksheet
- Communications Cloud account and message category: ____.
- Approved visible From domain and organizational owner: ____.
- Agency or customer-domain relationship and explicit approval: ____.
- Current provider applicability confirmation and date: ____.
- Provider-supplied CNAME owners, targets and request reference: ____.
- Authoritative DNS operator and intended complete names: ____.
- Existing sender dependencies and unresolved SPF route information: ____.
- Provider preparation, DNS publication and provider verification states: ____.
- Authorized received-message selector, signing domain and alignment evidence: ____.
- Remaining decisions, rollback owner and release approver: ____.
All entries are intentionally blank. Original implementation evidence, human/SME review, source applicability, production routes, visual/accessibility review and owner release remain open. No support request, DNS change, tenant test or message send has been performed for this draft.