Jive SPF, DKIM and DMARC setup, step by step

Authenticate Jive notification email by first identifying Jive Cloud or Jive Hosted, then applying the matching SPF authorization and requesting domain-specific DKIM records from Jive Support. Hosted uses a public-key TXT record; Cloud uses supplied CNAME records. Finish with a newly delivered notification whose intended branded DKIM signature passes and aligns with its visible From domain. A DNS lookup or a different passing signature is not sufficient. Jive’s authentication setup.

This guide covers the Jive Software community/intranet notification service, not similarly named communications products. It retains both Cloud and Hosted branches. Self-managed SMTP arrangements need their actual mail-server instructions rather than an assumed Cloud record.

Employee mail through Microsoft 365 is a separate sending route; retain its configuration and use the Microsoft 365 authentication guide for that service rather than treating these application records as its configuration.

No customer account, DNS configuration or delivered message was tested for this guide.

Before you change DNS: identify the Jive sending route

Write down the instance, deployment model, service region, notification type and each visible From domain. Obtain confirmation from the account owner or Support. A US office does not establish that its instance uses the US Cloud sending infrastructure.

Jive notifications depend on application settings and user preferences as well as email delivery. Its email-notification documentation describes the notification service and support-managed custom-domain records. A missing notification can therefore be a generation problem, a delivery problem or both. Email notifications in Jive.

Keep these identities separate:

The examples describe identities, not a promise that Jive offers a particular custom Return-Path. Ask Support what MAIL FROM the exact route uses and whether it is customer-configurable. Adding Jive to example.com cannot fix SPF alignment when the receiver actually authenticates an unrelated envelope domain. SPF identities, DMARC alignment.

Before implementation, export the affected DNS records, identify their owners and arrange a rollback that includes Jive’s signing configuration. DNS rollback alone cannot repair a private/public-key mismatch introduced on the sending side.

Configure the SPF authorization for the correct deployment

Jive’s current setup page publishes these additions. They are mechanisms to merge, not complete replacement records. Confirm applicability to the instance before using them. Official Cloud and Hosted SPF instructions.

Jive Cloud: US

ip4:204.93.64.116 ip4:204.93.64.117 ip4:192.250.208.112 ip4:192.250.208.113 include:sendgrid.net

Jive Cloud: EU

ip4:204.93.80.116 ip4:204.93.80.117 ip4:204.93.95.57 include:sendgrid.net

Jive Hosted

include:sendgrid.net include:spf.jivesoftware.com

The Hosted paragraph contains a qualification about SendGrid that also refers to Cloud migration. Do not interpret it as permission to remove include:sendgrid.net whenever DKIM starts passing. Have Support confirm the active route and whether removal is appropriate; also check that another application does not still depend on it.

Merge safely at the evaluated owner

1. Determine the actual MAIL FROM domain and who manages its SPF. Do not edit a provider-owned domain.
2. Retrieve all TXT records at that owner and identify the single policy beginning v=spf1.
3. Preserve existing authorized senders and the existing terminal policy. Insert only the applicable, approved mechanisms before the terminal all.
4. Check nested lookup paths. SPF permits at most ten DNS-querying mechanisms/modifiers during an evaluation, including nested dependencies. A short-looking record can exceed that limit.
5. If the baseline uses redirect= or other advanced rules, review its evaluation order rather than appending a generic all that changes its behavior.

Do not create a second SPF record at the same owner. Multiple policies cause permerror; unrelated TXT records may remain. ip4 mechanisms do not consume DNS lookups, but include and its nested dependencies can. SPF record selection and limits.

If the existing SPF policy uses redirect=, reconcile its authorizations and terminal behavior with the DNS owner before changing it. Any all mechanism makes redirect ignored regardless of their order. Do not append all automatically: preserve the redirected senders and approved policy semantics through a reviewed design. SPF all and redirect processing.

A limited example, assuming Google Workspace is the only existing sender, Jive Hosted is confirmed, and Support confirms both Hosted mechanisms are needed:

Before: v=spf1 include:_spf.google.com ~all
After: v=spf1 include:_spf.google.com include:sendgrid.net include:spf.jivesoftware.com ~all

This preserves the illustrative baseline’s ~all. It is not an instruction to soften an existing -all, authorize Google on another domain or replace a more complex policy. Validate the resulting live lookup path before adoption.

Request and activate branded DKIM with Jive Support

The documented provisioning request needs the email domain and a selector of exactly three characters. Hosted administrators can check the relevant Server Admin Email setting under Admin Console → System → Settings → Email Server. Cloud customers cannot access that setting and should ask Support to identify it. Request a 2048-bit key for Hosted; Jive’s page describes 1024-bit as its default and 2048-bit as available on request. Jive’s infrastructure team performs the sending-side work and supplies public DNS entries. Jive DKIM provisioning.

Prepare a support request containing:

• Instance and confirmed Cloud/Hosted branch, plus region.
• Intended From domain and requested branded DKIM d= domain.
• Proposed unused three-character selector, subject to Support’s confirmation.
• Request for every exact owner, record type, public value or target, and applicable TTL guidance.
• Request for confirmation of when signing is active and which notification streams use it.
• Existing-selector dependencies and a rotation or rollback plan, if replacing a key.

Do not send account credentials or publish a private key. The signer keeps private key material; DNS exposes only the public verification material. DKIM key retrieval.

Hosted: publish the supplied TXT key

Use the complete public value from Support. Never copy the key printed in a documentation example or generate an unrelated pair online: Jive must possess the matching private key.

For a fictional agreed selector jmx and signing domain example.com, the full owner is jmx._domainkey.example.com. The three-character selector alone is not the record owner.

A long key can be encoded as multiple quoted character strings within one TXT resource record. Preserve the concatenated value exactly. Follow the DNS host’s input syntax; some interfaces split long values automatically. Do not create separate TXT records for separate pieces of the key. DNS TXT encoding.

Cloud: publish every supplied CNAME

Copy each Support-issued owner and target unchanged. Do not convert CNAME delegation to a TXT record, reuse another instance’s target or derive a target from a familiar SendGrid pattern. Confirm the full generated names, even if they differ from a simple selector example.

A CNAME cannot coexist with ordinary TXT or other data at the same owner. Stop and reconcile a collision instead of deleting an active record. If using Cloudflare, authentication CNAMEs need DNS-only resolution without flattening that hides the CNAME. CNAME rules, Cloudflare’s verification guidance.

For Jive Cloud's supplied aliases only, apply these DNS-host safeguards; the Hosted direct-TXT key does not require CNAME processing. Where the issued authentication or return-path records require literal CNAME answers, use DNS-only aliases returning the exact targets, without an HTTP proxy or flattening hiding them. Turn the relevant per-record Flatten control off when available and ensure applicable zone settings preserve those aliases. Cloudflare documents that flatten-all cannot be overridden per record, apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are conditional DNS-host behaviors, not assumed controls in every panel. If mandatory apex/same-zone behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration with the DNS owner and sender. Do not blindly change the whole zone or remove an existing delegation. CNAME verification, flattening controls and limits.

After publication, give Support the DNS evidence and obtain confirmation of the sending-side configuration. Do not regard a support request, a published key or a successful public lookup as proof that the intended notification stream is already signing.

Publish at the correct DNS owner, including delegated subdomains

An editor’s relative-name field is relative to the zone being edited. These examples explain naming only; use the owner actually issued for the account.

If community.example.com is delegated by NS records, publish its records at the delegated provider. A plausible record entered in the parent’s interface may not be authoritative. If the editor expects an FQDN, enter the full owner using that interface’s convention. Avoid producing jmx._domainkey.example.com.example.com. DNS zones and names, Cloudflare on delegated verification.

If _domainkey.community.example.com is separately delegated, the full example owner jmx._domainkey.community.example.com uses relative jmx in that zone. Keep that NS delegation and active selectors intact, and coordinate publication with its actual operator. A full-name field takes the full issued owner. DNS zone boundaries.

Keep DMARC policy and reporting under the domain owner’s control

DMARC needs an authenticated identifier aligned with the visible From domain. Relaxed alignment permits a shared organizational domain; strict alignment requires an exact match. For From: community@example.com, d=example.com matches both modes, while d=community.example.com matches relaxed but not strict DKIM alignment. An unrelated signing domain matches neither. DMARC identifier alignment.

Keep any existing DMARC record, reporting destinations and policy. Check both a subdomain’s policy and inherited policy where applicable. If there is no established policy and the owner approves an initial monitoring rollout, this is an illustrative record, not a ready-to-publish value:

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the mailbox with an approved working report destination. Aggregate reporting helps identify sending sources and authentication/alignment failures over time; it is not a delivery receipt for every notification.

For a first policy at full owner _dmarc.example.com, a relative-name field in zone example.com takes _dmarc. For a deliberately approved child policy at _dmarc.community.example.com, use _dmarc.community in the parent zone or _dmarc in a separately delegated community.example.com zone. A full-name field takes the complete owner. These examples do not authorize overriding an inherited policy.

Compare the Organizational Domain of the aggregate-report URI's host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as the policy domain is excepted; a different hostname alone does not make it external. Obtain the reporting operator's exact authorization instructions when required. This protocol check is separate from the domain owner's approval to share report data; agree access, retention and privacy. RFC 9990 section 4.

Do not downgrade an established quarantine or reject policy to troubleshoot one Jive stream. Review all legitimate senders and indirect delivery paths before stronger enforcement. Current DMARC guidance requires valid DKIM rather than relying solely on SPF for domains publishing p=reject. DMARC interoperability.

Verify DNS, then test the actual notification

DNS acceptance

These are read-only command examples. Replace the illustrative domains and selector with the approved values. The SPF query must use the actual evaluated MAIL FROM domain, not automatically example.com.

dig +short NS example.com
dig +short TXT example.com
dig +short TXT jmx._domainkey.example.com
dig +short CNAME jmx._domainkey.example.com
dig +short TXT _dmarc.example.com

Use the TXT DKIM query for Hosted and the actual generated CNAME owners for Cloud. Query authoritative nameservers and at least one independent resolver. For a delegated child, locate its NS delegation and query that authority. A Cloud CNAME must match the issued target and resolve to the intended public key; Hosted must return the exact key as one logical TXT record. Compare concatenated TXT strings, not visual line wrapping.

An empty answer requires checking owner, type, delegation and resolver response. SERVFAIL is an error, not proof of absence. Review TTL and negative caching. Jive’s DKIM-failure guidance allows up to 24 hours for DNS propagation and recommends checking again after a few hours. That allowance does not repair an incorrect owner or key, and it does not replace confirmation that the intended signer is active.

Delivered-message acceptance

Use an authorized test user and a harmless notification event. Jive documents an @mention in a dummy blog post as one way to generate a specimen. Test relevant additional notification streams separately rather than resetting real users’ passwords merely to test mail. Jive’s notification test.

Inspect raw headers at a controlled external receiver. Trust its own Authentication-Results, not an arbitrary header inserted earlier. Record From, MAIL FROM, each DKIM d= and s=, SPF result, DKIM results, DMARC result, Message-ID and UTC time. Authentication-Results trust boundaries.

Establish which results were generated inside the receiving service's known processing boundary and how it removes, ignores or distinguishes externally supplied Authentication-Results. Use receiver-controlled diagnostics or have the receiving-mail administrator confirm its documented handling. A familiar authserv-id string or header position alone is not proof. Ignore attacker-supplied or otherwise untrusted fields; obtain authenticated receiving-system evidence when provenance is uncertain. Receiver-result trust.

Accept the branded setup only when:

• The specimen came from the intended Jive instance and notification route.
• The intended branded DKIM signature reports dkim=pass and aligns under the effective adkim mode.
• The receiver reports dmarc=pass, with an identified aligned authentication path.
• SPF authenticates the intended envelope route, or any non-pass is investigated and its cause resolved or explicitly documented for an indirect route. A provider-owned SPF pass may be unaligned; that is different from an actual SPF error.
• Direct-path SPF fail, softfail, permerror or temperror remains an open defect until explained and retested. An aligned DKIM pass must not hide it.

DMARC technically permits either aligned SPF or aligned DKIM. Requiring the configured branded DKIM to work is a stricter setup acceptance criterion, not a claim that DMARC universally requires both.

Keep the approved branded From unchanged. A rewrite to a provider From or an unrelated passing signature is not successful Jive brand authentication. For SPF fail or softfail, compare the actual connecting server and envelope identity with the approved route and authorization; the separate temporary/permanent error checks below still apply even when DKIM passes.

Troubleshooting Jive authentication

Jive’s key/failure guidance directs customers to Support for replacement material and DNS formatting checks. A DNS public key does not intrinsically expire on a fixed schedule; distinguish a signature’s expiration, provider rotation and a missing key before replacing records.

A proxy’s changed connecting IP can explain an SPF mismatch. It does not, by itself, break DKIM. For DKIM, examine the public key and whether signed content was modified. Do not broadly bypass Mimecast or another security gateway just because an article mentions allowlisting. Any routing or trust change needs its own security review. DKIM verification.