BombBomb SPF, DKIM and DMARC setup, step by step

On this page: Choose the sending route · Custom-domain setup · SPF · DKIM · DMARC · Verification · Troubleshooting · FAQs

BombBomb's documented custom-domain authentication is support-assisted. Teams should ask its deliverability team for the DNS records appropriate to their account, publish those exact values, and obtain confirmation that the intended domain is active. Do not assume that every BombBomb message uses your own domain: its documented Send On Behalf Of mode rewrites the From address, while the Engage Outlook integration sends through Outlook. BombBomb self-authentication, Engage Outlook route

This guide focuses on BombBomb's documented Classic sending and support-assisted custom-domain workflow. It distinguishes the verified Engage Outlook route but does not assume all newer Engage email features use Classic's settings. No customer account, DNS change, live DNS lookup or delivery test was performed.

Choose the correct BombBomb sending route

Send On Behalf Of: the visible From domain changes

BombBomb documents an automatically applied mode in which the From address moves to send.bbemaildelivery.com, while the display name and Reply-To remain unchanged. A familiar sender name therefore does not prove that the message's From address is on your domain. BombBomb's identity-handling explanation

Inspect the full address rather than the name shown in the inbox. In this mode, a DMARC pass for the rewritten provider domain is not evidence that your business domain has custom DKIM. The unchanged Reply-To can preserve replies without making that address the identity DMARC evaluates.

Custom-domain sending: eligibility and values come from BombBomb

BombBomb's SPF/DKIM help page says most accounts use its own DKIM signing and that Teams accounts support custom DKIM. Its self-authentication page directs team requests to delivery@bombbomb.com. Confirm eligibility for the actual product and account before planning DNS work; the documentation is not a promise that every plan has the same controls. BombBomb account scope

Engage through Outlook: authenticate the mailbox service

The documented Engage Outlook integration requires an administrator to enable Account Settings → Permissions → Email Integration → Outlook before users connect their mailbox through Quick Send. Its support page lists Core, Core + Copilot and Enterprise. Confirm availability for the actual account rather than assuming every Engage user has this route.

The integration sends through Outlook's servers and stores messages in Outlook Sent Items. Its From field uses the connected Outlook address. Authenticate the underlying mailbox domain with its mail administrator; adding BombBomb-specific DNS does not authenticate this separate route. A Sent Items entry is useful route evidence, but inspect the received headers too. Engage Outlook integration

For a connected organizational Microsoft 365 mailbox, use the Microsoft 365 authentication guide with that tenant’s administrator. This applies to the documented Outlook transport, not BombBomb Classic’s custom-domain records.

If your account uses another Engage email feature, obtain that feature's current domain-authentication instructions. Do not infer its sending infrastructure from a shared video thumbnail, brand name or interface.

Prepare a support-assisted custom-domain setup

Before requesting records, list the business domains and subdomains that should remain visible to recipients. Identify the DNS administrator and export the current zone. Save existing SPF policies, DKIM selectors, DMARC policies, MX records and TTLs. Include other marketing, corporate-mail and transactional senders in that inventory.

Ask BombBomb to confirm:

1. Which account, product and sending features the custom-domain setup covers.
2. The exact visible From and envelope/bounce domains it will use.
3. Every required DNS owner, type, value and any MX priority.
4. The DKIM selectors and expected signing domain.
5. How it will verify publication and confirm activation.
6. Whether any sender-address rewrite remains after activation.

This is an information checklist, not a claim that every account exposes those fields in a self-service screen. Keep private keys, passwords and login tokens out of DNS and support correspondence. The provider should supply public record values, not ask you to invent a matching key.

BombBomb's current custom DNS article distinguishes bounce MX, SPF TXT and DKIM CNAME records. Its example names and values illustrate their purposes; they are not a tenant-specific installation bundle. Understanding BombBomb custom DNS entries

Configure SPF at the actual envelope domain

SPF authorizes sending hosts for the SMTP MAIL FROM domain, usually visible as the Return-Path after delivery. It does not directly authenticate the address displayed in From. SPF can use HELO when the reverse path is empty. Use the actual identity from the provider's instructions and the received message, not an assumed root domain. SPF identity rules

BombBomb's custom-DNS explanation places SPF on an illustrative bounce subdomain. The _spf.example.com include shown there is a placeholder. The reviewed current official pages do not establish include:bbemaildelivery.com as a universal customer instruction, even though older third-party tutorials publish it. Obtain current values for your setup rather than installing either string on that basis. BombBomb custom-DNS example

Apply the issued instruction with these safeguards:

• Publish one SPF TXT policy at each relevant owner. A second v=spf1 record can produce a permanent error.
• If a policy already exists at that owner, merge the confirmed authorization before its terminal all; retain legitimate senders and the intended qualifier.
• A bounce subdomain has its own policy. Publishing at the parent does not make that policy inherit downward.
• Review an existing redirect= policy deliberately rather than applying a simple merge mechanically.
• Evaluate the complete policy against the 10 DNS-query-causing-term limit, including nested includes. Do not hard-code provider IPs as an unmanaged workaround.

These are protocol safeguards, not BombBomb-specific record values. SPF publication and lookup limits

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

Keep bounce MX separate from inbox MX

A custom bounce MX directs delivery-failure messages to the provider. It is not an instruction to move your employees' incoming email. Use only the exact owner and priority issued for the bounce domain. Do not replace an existing MX set at the business root because an example mentions an MX record. BombBomb bounce-routing explanation

Before activation, obtain routing-owner approval of the bounce design separately from the provider-issued packet. Compare the complete approved set of fully qualified MX owner, numeric priority and target hostname at both the authoritative DNS server and a recursive resolver. Stop on missing or unexpected entries; preserve corporate mailbox routing and resolve the discrepancy with its owner rather than accepting a merely nonempty answer. MX owner and preference semantics.

Publish the issued DKIM CNAMEs and confirm signing

BombBomb documents CNAME-based custom DKIM, pointing to its managed public key. Obtain the actual selector owners and targets for your domain; s1 and the example target in its explanatory article are not universal instructions. BombBomb managed DKIM

For each issued record:

1. Check whether the owner already exists. If it belongs to another service, ask for a non-conflicting selector instead of deleting it.
2. Enter the record as CNAME, not TXT. Keep the full target exactly as issued.
3. Check your DNS host's suffix behavior. For example, an owner ending in ._domainkey.example.com may require only the relative part within an example.com zone.
4. Verify the published name and target, then ask BombBomb to confirm the domain is active for the intended sending route.
5. Inspect a newly delivered message for the expected DKIM signing domain and selector.

At Cloudflare, publish these authentication CNAMEs as DNS only, not proxied, and avoid flattening the verification records. Flattening can return addresses instead of the required CNAME and make verification fail. Keep unrelated web records and protections unchanged. Cloudflare proxy guidance, verification and CNAME flattening

Keep the required literal CNAME answer: turn relevant per-record Flatten off where available and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, apex CNAMEs are flattened by default and same-zone targets are flattened regardless of that setting; flatten-all cannot be overridden per record. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration without breaking other services or removing NS delegation. These are DNS-host behaviors, not controls assumed in the sending provider. Cloudflare flattening controls and limits.

A CNAME generally cannot share its owner with other record types. DKIM receivers locate the key using the message's s= selector and d= domain, forming selector._domainkey.signing-domain. A record can look valid while pointing to the wrong account's key. CNAME constraints, DKIM lookup rules

For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.

Do not assume DNS publication alone activates signing. The reviewed public instructions do not describe a universal self-service activation button. Get account-specific completion confirmation and retain the delivered-message evidence.

Check DMARC against the address recipients actually see

DMARC needs an aligned SPF pass or an aligned DKIM pass. Relaxed alignment allows the authenticated domain and visible From domain to share an organizational domain. Strict alignment requires exact equality. A provider-domain authentication pass is insufficient when the visible From remains your unrelated business domain. Conversely, rewritten provider-domain mail is evaluated against that rewritten From domain. DMARC alignment

For example, a bounce identity at bb.example.com can align with example.com under relaxed SPF alignment, but not strict aspf=s. A passing DKIM signature with d=example.com can satisfy DMARC for From example.com even when SPF does not align. These are illustrative identity relationships, not statements about the configuration of your account.

Preserve an existing DMARC policy, including inherited policy and strict-alignment choices. Do not downgrade reject or quarantine to solve an incomplete sender setup. For a domain without applicable established policy, a monitored first record might be:

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

Replace the example domain and use an approved reporting mailbox. This template is only for a new monitoring deployment after reviewing all legitimate senders, not a policy replacement. Use one policy at the intended owner and confirm external report-destination authorization when applicable. DMARC aggregate reporting

For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names. 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 that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.

Current DMARC is defined by RFC 9989; the old pct tag is obsolete. Plan enforcement using observed sender coverage rather than assuming a percentage tag stages it. Failure reports may expose message details, so assess privacy before enabling them. Current policy standard, failure-report considerations

Verify the DNS and a newly delivered BombBomb message

These are read-only command patterns, not results from this review. Replace example.com, the bounce name, selector and authoritative nameserver with the identities issued for your route:

dig +short NS example.com
dig @ns1.dns-host.example TXT bb.example.com
dig +short MX bb.example.com
dig +short CNAME selector._domainkey.example.com
dig +short TXT selector._domainkey.example.com
dig +short TXT _dmarc.example.com

Compare authoritative DNS with a recursive resolver. Check the SPF owner actually used, all required CNAME targets and the correct bounce MX priority. A DKIM TXT lookup should follow the alias to the managed key. Previous TTLs explain temporarily cached answers; incorrect delegation, a duplicated zone suffix or a conflicting owner requires a correction, not just waiting.

After activation, send a controlled message through the actual feature being authenticated. Save the raw source and use the receiving service's trusted Authentication-Results. Header trust boundary

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

A useful verification worksheet records:

• Route: Classic native sending, support-authenticated custom domain, or connected Outlook.
• Visible identity: full From address, display name and Reply-To separately.
• SPF evidence: smtp.mailfrom, result and whether that domain aligns.
• DKIM evidence: result, header.d and the signature's selector.
• DMARC evidence: dmarc=pass for the actual visible From, with the passing aligned method identified.
• Operational evidence: replies go where intended and bounce handling remains configured.

For custom-domain acceptance, confirm the intended business domain remains in From and the expected branded DKIM signature passes and aligns under the domain's active adkim setting. An SPF-only DMARC pass is not proof that the custom DKIM setup works. Investigate actual SPF errors independently, even when aligned DKIM supplies the DMARC pass. A provider-domain DMARC pass after an unexpected rewrite is a different outcome. Repeat for other users or sending features rather than extrapolating from one message. Authentication does not guarantee inbox placement.

Troubleshoot common BombBomb outcomes

Recipients see a BombBomb domain: inspect the actual From address and account route. The documented rewrite preserves the display name and Reply-To, so a normal-looking inbox name can conceal the change. Ask whether custom-domain activation covers that sender.

SPF and DKIM pass but DMARC fails: check the authenticated domains, not only their pass labels. Neither may align with the visible business From.

DKIM CNAME exists but messages use the provider's signature: ask BombBomb to confirm eligibility, activation and domain coverage. Publishing a customer-domain record does not make every account use it.

SPF fails while DKIM passes: confirm the actual envelope domain and final sending IP. A fail or softfail can indicate an unauthorized route or missing authorization; permerror can indicate duplicate SPF policies, invalid syntax or excess DNS-query terms; temperror indicates a transient evaluation problem such as DNS availability. Validate the original sending path before adding an IP seen only after forwarding.

DNS host reports a conflict: preserve the existing owner until its service is identified. Request an alternative selector or bounce label where appropriate.

Outlook-routed messages fail authentication: investigate the underlying mailbox service and sending domain. Do not apply Classic's bounce records to a Microsoft route merely because the video was selected in BombBomb.

Messages authenticate but bounce or reach spam: retain the bounce code, recipient-side result, timestamp and message ID. Check sender reputation, content and recipient policy separately. Share only the evidence needed for support diagnosis.