Separate the documented identity models
The official Set-up self-authentication / custom DKIM article in the Knowledge Base for BombBomb Classic, dated May 2, 2025 and reviewed for this manuscript on November 8, 2026, describes two approaches. One is an automatically implemented Send On Behalf Of system that changes the message's From address. The other is a custom DKIM option for teams using their own domain, arranged with the deliverability department.
The source links separately to BombBomb Engage; this guide does not establish that the Classic instructions apply to Engage. Confirm the account product before using this workflow.
These approaches should not be presented as equivalent DNS recipes. The first changes which address appears as the message author; the second requires account-specific work to establish a custom signing arrangement. Identify which approach applies to the account and which sending route is under review before proposing any changes.
This guide deliberately covers the publicly documented workflow boundary. It does not supply a guessed selector, SPF include, public key or account setting. The catalogue's broader implementation and received-message requirements remain open until account-specific instructions and authorized operational evidence exist. BombBomb custom DKIM guidance
Understand the From-address change without confusing replies
The documented Send On Behalf Of solution alters the From address to a provider-controlled delivery-domain address. BombBomb says that the Reply-To address and From name remain the same. Those fields serve different purposes: a familiar display name or unchanged reply destination does not mean the original author address remains the authentication identity.
The acceptance record should therefore capture the actual From address as a domain-bearing identity, not just the friendly name shown by a mail application. Record Reply-To separately so customer-service expectations can be checked without treating reply routing as proof of DMARC alignment. The provider article includes an illustrative rewritten address; do not treat that illustration as a template that predicts every account's exact address.
The article describes the behavior as a default implementation, but a documentary statement cannot establish what a specific historical message contained. Verify representative authorized mail from the relevant route before making a customer-facing claim about its visible sender or authentication results. Solution 1 and Pro Tip; RFC 9989, section 4.4
Determine whether the custom-domain option fits the team
The provider describes custom DKIM as an option for users of a custom email domain and directs teams interested in self-authentication to its deliverability department. A domain that belongs to a public mailbox provider is not a domain the customer can authorize by publishing DNS. Establish domain control and the business owner before requesting a custom arrangement.
Inventory the account or team, intended sender domain, affected mail categories and people responsible for DNS. The source recommends involving IT because configuration requires deeper administrative involvement. That recommendation is not permission to share administrator passwords or private signing material with a support address. Prepare a minimal request describing the intended route and ask for the applicable configuration requirements through the organization's approved support channel.
Do not assert universal plan eligibility or invent a self-service screen. The public article provides a contact-assisted route, not a complete entitlement matrix or a reusable DNS procedure for every BombBomb product. Solution 2: Custom DKIM Setup
Turn provider instructions into an approved change plan
The documented contact for team custom DKIM assistance is delivery@bombbomb.com. This manuscript does not send that request. Once the organization chooses to proceed and receives account-specific guidance, the proposed review should capture the exact domain, record types, owner names, values, activation steps and any implications for existing sending behavior.
Before publication, compare those instructions with existing DNS and active signing dependencies. A selector already in use by another route must not be overwritten merely because a new support request contains a similarly named record. Preserve a recoverable before-state, assign an authorized DNS owner and identify how the change will be reviewed.
Ask the provider to clarify any missing activation or verification step rather than filling gaps with another vendor's recipe. A public article that says contact support does not establish whether a particular account will use TXT keys, aliases, a particular selector or a particular envelope domain. The honest implementation boundary is to retain these as unresolved account requirements until supplied. Support-assisted custom DKIM; RFC 6376, section 3.5
Verify authentication independently of marketing assurances
The provider article uses broad language about compliance and avoiding blocks. The operational acceptance should be narrower. A valid DKIM signature establishes a signing-domain assertion under the protocol; DMARC additionally evaluates alignment with the author domain. Neither proves that recipients will receive the message in their inbox, trust its content or consider the business request legitimate.
For an authorized representative message, retain the visible From domain, DKIM d= domain, selector, and trusted receiver authentication results. Record the sending route and time so an older default-route message is not confused with a later custom-domain configuration. If multiple signatures are present, evaluate the relevant valid aligned signature rather than assuming the first displayed one is decisive.
SPF is a separate check using SMTP identities. Do not add a guessed BombBomb mechanism to an organization's root policy as an automatic companion to a custom DKIM request. Obtain current route-specific guidance where needed. A completed support conversation and a verified received message are separate pieces of evidence. RFC 9989, section 4.4; RFC 7208, section 2.4; RFC 6376, section 3.5
Acceptance worksheet for sender-identity review
Use this proposed worksheet to prevent a familiar display name from masking an unreviewed identity change.
- Account scope: identify the BombBomb team, sending route and message categories included in the review.
- Identity model: record whether the documented default rewrite or a support-assisted custom-domain configuration is intended.
- User experience: retain the actual From address, From name and Reply-To separately, with the communications owner's expectations.
- Custom-domain prerequisites: identify the domain owner, DNS administrator and account-specific support reference.
- Proposed records: preserve exact provider-issued values and activation instructions, leaving unknown fields explicitly open.
- Message evidence: retain a minimized authorized sample and the trusted authentication and alignment assessment for that route.
- Release and retirement: name the reviewer, rollback owner and process for removing obsolete dependencies after active use ends.
The worksheet is an original control design. It is not a completed support request, account audit, DNS lookup or mail test.
Fictional diagnosis: a familiar name conceals a changed address
A fictional property-services team sees the same staff member's display name and receives replies normally after a provider change. It concludes that its original company-domain From address must still be used. A reviewer asks for the actual address fields and finds that the example under discussion uses a rewritten delivery-domain author address, while Reply-To still points to the staff member.
The proposed correction is to document the chosen identity model and decide whether the team wants to pursue the provider's custom DKIM route. It does not label the message a spoof solely because the author address differs from Reply-To, and it does not claim that a custom-domain setup already exists. Any future change still requires provider instructions, authorized publication and received-message acceptance. This scenario is fictional and is not an allegation about a real BombBomb account.