Scope: identify the Jive deployment before editing DNS
Jive's setup guidance separates Cloud and Hosted installations. Its SPF instructions also distinguish US and EU Cloud routes. Treat that branching as a prerequisite: a familiar product name is not enough to select DNS data. This review concerns Jive notification email, not another product named Jive or a general outbound mail service. Jive setup
The administrator should first describe the business event that produces the message. A community notification, a password-related message and an application-generated digest may have different configuration or delivery dependencies. Record the exact installation, service owner, sending domain and expected recipients. Do not infer the deployment model from an email logo or from the organization's geographic headquarters. Obtain an authoritative account description before choosing a documented branch.
This is a proposed configuration and acceptance method. No Jive account has been accessed, no DNS record has been changed and no message has been sent for this article. Current applicability to a particular installation remains unverified. Documentation review cannot supply the original received-message evidence required for implementation acceptance.
Obtain the correct provider-generated material
The documented DKIM workflow uses support-generated public material: TXT for Hosted and CNAME records for Cloud. The requested selector must be exactly three characters. Supply the email domain; Cloud customers cannot access the cited Server Admin Email setting and should tell support. Jive performs its side of implementation, then supplies the customer's DNS entries. Its DMARC setup guidance places responsibility with the customer's IT team. Jive workflow
Prepare a request rather than inventing a key or selector. The proposed request should identify the existing installation and intended sending identity, ask which deployment branch applies, and request complete public DNS instructions. Never include a private signing key, account password or session token in a change worksheet. Provider assistance with signing does not authorize a separate administrator to change the organization's domain-wide policy.
Keep the supplied material attached to a specific change version. If a support reply later changes the record type, owner or target, stop the pending approval and reconcile the difference. A previous screenshot may still look plausible while describing another region, deployment or key generation. The DNS administrator needs complete current values, not an inferred pattern assembled from unrelated examples.
Preserve the existing SPF policy
SPF evaluates the appropriate SMTP identity, not simply the address a person sees in the message. Distinguish the MAIL FROM identity from the HELO identity when recording observations. A passing result for a provider-controlled envelope domain does not by itself establish alignment with the visible author domain. RFC 7208, sections 2.3 and 2.4
Before proposing an edit, obtain the complete existing policy and identify its owner. Preserve approved senders that are unrelated to this Jive deployment. Do not create a second SPF policy at the same owner to avoid understanding the first one. Review the resulting evaluation paths, including nested dependencies: the protocol's lookup-term limit is not a count of visible include strings or network packets. Caching does not provide permission to exceed that limit. RFC 7208, sections 3.2 and 4.6.4
The Jive page contains a route-dependent note about removing a SendGrid reference after DKIM setup. Do not apply that note as a universal removal instruction: establish the actual envelope path and any other sender dependency first. Jive SPF guidance
Write the intended change as a difference from the approved baseline. Record what is added, what is retained and what is proposed for removal. If ownership of an existing dependency is unknown, leave that question unresolved rather than silently deleting it. A successful edit in a DNS interface is evidence of an administrative action, not evidence that the complete mail population still authenticates.
Publish the exact owner and public value
For each proposed record, record the fully qualified owner independently of the DNS editor's display. Some editors accept relative labels while others display complete names. A master-file convention does not prove how a particular graphical interface handles the domain suffix. Confirm the resulting owner using the DNS provider's own rules before saving. RFC 1035, section 5.1
Keep the record type from the applicable provider instructions. Do not transform a CNAME delegation into a locally invented TXT key or replace a supplied public key with one from an example. For TXT data, distinguish character strings inside a single resource record from separate resource records. Splitting display text must preserve the intended bytes; adding an independent record is a different operation. RFC 1035, section 3.3.14
Treat an existing selector as a dependency requiring investigation. Identify the current signing flow before overwriting anything at that name. A proposed rollback should explain which DNS version can be restored and whether the provider has already changed its signer. Restoring old DNS without coordinating the signing side can create another mismatch rather than repairing the first one.
Verify the message, not just the record
The acceptance review should collect an authorized message from the actual application workflow and preserve trusted receiver results. Record its visible From domain, envelope identity, every DKIM signing domain and selector, and the receiver's authentication outcomes. DKIM binds a signature to a signing domain and selected message data; a DNS key's existence does not demonstrate that the application used it. RFC 6376, sections 3.5 and 3.6.2.2
Separate authentication success from alignment. DMARC can succeed through a qualifying aligned SPF path or a qualifying aligned DKIM path. Neither that success nor a provider confirmation guarantees inbox placement or proves that a business request in a message is safe. Evaluate the actual identifiers under the applicable alignment rules rather than interpreting two green dashboard labels as sufficient evidence. RFC 9989, sections 2.4 and 4.4
If an intermediary changes the delivery path, diagnose SPF and DKIM independently. A different connecting IP can affect SPF, but that fact alone does not explain a broken DKIM signature. Examine the relevant public key, signature and signed data before attributing failure. Do not respond by broadly bypassing security inspection. A narrowly approved routing correction requires its own evidence and owner decision.
Fictional diagnosis: the wrong deployment worksheet
Consider a fictional organization, Cedar Example, whose administrator prepares a TXT-key worksheet after reading instructions intended for Hosted installations. The account owner then produces a Cloud support response containing CNAME entries. No DNS change has yet been approved. The discrepancy is a deployment-branch error, not proof that either record format is universally wrong.
The review team withdraws the incomplete worksheet, records the account's confirmed route and asks the DNS owner to assess the complete supplied names and targets. It leaves existing selector records untouched until their owners are known. Only after a separately authorized implementation would the team gather a received message and compare its identities with the approved plan. This scenario is invented to illustrate a decision process; it contains no observed tenant result or executable customer values.
Blank acceptance worksheet and release decision
- Installation and deployment model: ______. Region and evidence owner: ______.
- Notification workflow and intended visible From domain: ______.
- Current support instruction date and applicable product scope: ______.
- Selector length confirmation and existing-selector dependency review: ______.
- Complete supplied record owners, types and public values: ______.
- Existing SPF baseline and approved change difference: ______.
- Envelope-domain expectation and lookup-path review: ______.
- DNS editor naming behavior and resulting public-owner evidence: ______.
- Provider-side implementation confirmation: ______.
- Authorized message reference and trusted receiver identity table: ______.
- Alignment outcome, remaining failure and rollback owner: ______.
- Independent reviewer, release owner and review date: ______.
Leave a field blank when evidence is absent. A blank is a useful control because it prevents documentary readiness from becoming a claim of operational completion. Original evidence, human SME review, source applicability, production routes, visual accessibility and owner release all remain open for this draft. Revisit the assessment when the deployment route, provider instructions, signing material or domain ownership changes.