Start with the journey and broadcast identities
A Rejoiner account can send through automated journeys and scheduled broadcasts. Identify the workflows in use before requesting DNS changes. Record the brand, account owner, intended From address, monitored reply mailbox and a controlled test for each path. Use a test customer and harmless content rather than enrolling real shoppers or generating real purchases for diagnostic purposes.
Rejoiner's Email Settings documentation places default sender details under Settings and the Email tab. It distinguishes the display name, Sender From Address and Reply-to Address. Check these defaults against the actual message to be tested. A familiar display name does not establish which domain will be authenticated.
The reply mailbox serves a different purpose from the signing and envelope domains. Verify that replies reach the intended team, but do not treat a working Reply-to as authentication evidence. Keep the branding decision and the technical identity table together so the marketing owner can see what recipients will encounter.
Obtain the current account-specific record set
Rejoiner's authentication resource describes assistance with client authentication health. Its public material is useful background, but the sources reviewed do not provide a complete tenant-specific selector, key, SPF authorization, custom-envelope procedure or current activation sequence. Those details remain pending until supplied for the actual account.
Ask the account team for the approved sending domain, exact DNS record owners and types, public values, expected DKIM d=, envelope-domain behavior and any activation requirement. Confirm whether journeys and broadcasts use the same configuration. Request an explicit answer about custom envelope alignment rather than assuming that choosing a branded From automatically changes the Return-Path.
Do not generate a random DKIM key from a generic tutorial and publish it for Rejoiner. The service must possess the matching signing key and be configured to use the intended identity. Do not copy another customer's selector or infer an SPF include from an observed upstream provider. Configuration authority must come from the supported account instructions.
Choose and document the sending-domain boundary
Rejoiner's Google Postmaster Tools guide says the Sender Domain is normally a subdomain reserved for Rejoiner or marketing mail. Treat that as a documented pattern, not a mandatory hostname or proof of the current tenant's setup. Have the business and DNS owners approve the domain actually assigned to this program.
Write down how the visible From, signing domain and envelope domain relate. Under relaxed alignment, related domains may qualify differently than under strict alignment. Do not assume that creating a marketing subdomain guarantees compatibility with an existing strict policy. Resolve the identity design before configuring a new campaign address.
Keep website tracking names and monitoring-verification records separate from mail authentication. Rejoiner's Postmaster instructions describe a Google-issued TXT record to prove domain ownership for that monitoring service. Publishing that token neither activates Rejoiner DKIM nor supplies SPF authorization. Record each DNS entry's purpose so future cleanup does not confuse analytics access with sending permission.
Publish only the approved authentication records
Save a baseline of relevant DNS records, their complete names, types, values and TTLs. Include existing SPF, DKIM and DMARC dependencies for employee mail and other marketing tools. Confirm which zone contains the intended sender subdomain and whether the editor appends its suffix automatically.
Apply each issued record at the exact owner and type. Compare the resulting public answer with the provider's instruction, not only with the DNS editor's display. If a selector or alias conflicts with another service, seek a supported alternative rather than silently replacing the other provider's record. Keep the activation step and its timestamp with the change.
SPF under RFC 7208 evaluates the SMTP identity rather than the visible From alone. Where an SPF policy is required, retain a single policy at that owner and review the complete DNS-query cost, including nested dependencies. Do not expand the root domain's authorization merely because a generic authentication article recommends SPF.
Preserve the organization's existing DMARC policy, alignment modes and report destinations unless a separate approved change is justified. A new marketing program must fit the domain's authentication design. It should not silently weaken protection for employee mail or unrelated transactional services.
Rule out a message that was never sent
Before diagnosing missing DKIM, establish that the test produced an email. The Email Settings guide documents domain suppression and an account-wide frequency cap across journeys and broadcasts. Those controls can prevent a particular test recipient from receiving a new message. Review the relevant account evidence before changing DNS or repeatedly triggering the same customer event.
The same guide says account BCC applies to journey messages, not broadcasts, and warns that BCC engagement can skew reporting. Do not use a missing broadcast BCC as proof of delivery failure. Send to a controlled recipient through the actual route and preserve the delivery evidence without clicking tracking links unnecessarily.
If a workflow is suppressed, capped or never triggered, resolve that test condition through the appropriate owner. Authentication is evaluated on mail that reaches a receiver; an application-side decision not to send cannot be repaired by adding a DNS record. Keep this distinction visible in the issue log.
Read the headers for both workflows
After configuration is ready, send a controlled journey email and a controlled broadcast where both are in scope. Capture Message-ID, UTC time, From, Return-Path, every DKIM d= and s=, and the final receiving system's trusted authentication results. Record the journey or broadcast identifier so the evidence can be reproduced.
DKIM's specification defines the signing domain and selector. Inspect every signature and identify which one, if any, both passes and aligns with the visible From. Under RFC 9989, DMARC requires an aligned passing SPF or DKIM path. An unrelated provider-domain pass is insufficient by itself.
Save the authentication result separately from placement and engagement. A low open rate does not prove a DKIM failure, and one inbox placement does not certify the entire program. When a fresh message fails, compare its observed identities with the account-issued configuration before escalating with a redacted header and exact UTC time.
Rejoiner acceptance worksheet
Complete independent entries for journeys and broadcasts:
- Account, brand, route and business owner: ____.
- Intended From, reply mailbox and approved sending domain: ____.
- Provider record set and supported signing/envelope behavior: ____.
- Exact DNS owners, types, value references and activation time: ____.
- Existing DMARC policy and applicable alignment modes: ____.
- Controlled recipient, trigger, suppression and frequency checks: ____.
- Message-ID, UTC time and workflow identifier: ____.
- Return-Path, all DKIM d= and s=, trusted results: ____.
- Actual aligned mechanism and placement observation: ____.
- Recovery action, reviewer and outstanding capability questions: ____.
Keep Postmaster ownership verification in a separate monitoring row. It can support later reputation work but cannot complete the authentication acceptance fields.
Fictional diagnosis of an absent broadcast copy
Fictional example only: Juniper Outfitters receives journey BCC copies but no broadcast BCC, then proposes replacing its DKIM record. The administrator checks the documented BCC boundary and tests the broadcast using a controlled actual recipient. That copy shows aligned DKIM and a DMARC pass.
The team leaves DNS unchanged and corrects its evidence-collection method. It separately checks frequency and suppression controls for test recipients who receive nothing. No Juniper account or message was inspected; the example demonstrates why workflow evidence must precede an authentication repair.
Leave unresolved capabilities visible
Recheck after sender changes, new workflows, DNS migration or provider key updates. Account-specific DNS values, custom-envelope support, live tenant and header verification, visual review, human SME approval and publication remain pending. Public documentation supports the settings distinctions above but does not close those implementation gates.
Use product guidance without adopting broad protocol shortcuts
The general authentication resource is background, not an account-issued key or proof that authenticated mail is safe. Use protocol standards for identity evaluation and provider-issued instructions for configuration. The fictional passing broadcast is only an illustrative stipulated result, not a Rejoiner tenant test performed for this review.
Separate message acceptance from policy rollout
A passing aligned SPF result can satisfy a message evaluation, but does not alone justify moving an entire domain to reject. RFC 9989 Section 7.4 requires valid DKIM for domains publishing p=reject and warns about indirect-mail interoperability. Inventory all legitimate senders and indirect routes before the policy owner approves enforcement. No DNS change, tenant operation or received-message test was executed for this article.