Identify the Bullhorn product and mail route
Bullhorn publishes different email guidance for different products. This guide uses its ATS documentation for SPF and mass-mail DKIM, not the separate Bullhorn Automation domain workflow. The SPF article explicitly covers ATS and Back Office; the DKIM article describes ATS and enabling DKIM on mass mails. Do not assume that one configuration covers every Bullhorn-branded product or every email integration.
Start with an inventory of the actual application, account, sending domain and message category. Separate mass mail generated through the documented route from messages sent through a connected mailbox or another product. Record who owns the domain and who can confirm the application's configuration. A recruitment team may use several sending tools under one brand, so the product name alone is not enough to select DNS instructions.
The retained public articles were reviewed on November 9, 2026, but their body text does not provide a reliable revision date. Confirm current account applicability before implementation. The site also carries a general notice about possible functionality limitations; this manuscript does not turn that notice into a claim that a particular tenant is affected. No account state or current service incident was investigated here.
Use the documented SPF include rather than guessed IP addresses
Bullhorn's SPF guide specifies include:_spf.bullhornmail.com rather than supplying a fixed sending-IP list. It explains that this approach avoids customers having to update individual addresses whenever its infrastructure changes. Use that documented dependency only for the intended supported route. Do not derive outbound authorization from a website address, an inbound mail exchanger or a third-party list of historic infrastructure. Bullhorn SPF instructions
Before editing, preserve the existing complete policy and identify other legitimate senders. The provider distinguishes an existing TXT policy from a domain that has no SPF policy. Its sample for an existing record contains a placeholder for the previous authorizations. That placeholder is explanatory text, not something to publish literally. Merge the approved include into the actual policy without inserting another version marker or losing other required mechanisms.
The sample's soft-fail ending is not permission to weaken an existing policy without review. Record whether the proposed change preserves the current terminal qualifier and what happens to senders that do not match. A change ticket should explain the intended addition, not merely attach a generic sample. The organization's policy owner remains responsible for the complete resulting authorization.
Assess the complete SPF policy and its identity
RFC 7208, section 3.2 prohibits multiple records that would cause more than one SPF policy to be selected. Publishing a second policy alongside the first is not a way to preserve existing senders. Section 3.3 permits multiple character strings within one TXT record, which is a different concept from multiple competing policies. A provider's compact include does not remove all possible record-size or evaluation constraints.
Section 4.6.4 limits evaluated DNS-dependent terms, including nested evaluation. Review the full path that a receiver may follow, not just the number of visible includes or DNS packets. A cached answer does not make an evaluated term disappear from the protocol budget. Keep lookup-limit faults, syntax errors and a valid nonmatching result separate because they require different corrective actions.
SPF uses the SMTP identities described by the specification. RFC 7208, section 2.4 explains MAIL FROM, including empty reverse-path handling. The address displayed by the ATS editor does not by itself establish the identity used for SPF evaluation. A later authorized message review should compare the actual envelope domain with the owner where the policy was published.
Prepare the ATS mass-mail DKIM alias
The DKIM guide says to use Bullhorn's SPF configuration before enabling DKIM on mass mails. It specifies a CNAME under bh._domainkey at the customer's domain, pointing to bh._domainkey.bullhornmail.com. Preserve this as a documented provider prerequisite and alias, not a TXT key copied from an unrelated product. Confirm the exact owner for the approved domain and the current account route before publication. Bullhorn DKIM and DMARC instructions
DNS panels differ in how they append the domain suffix. A panel expecting a relative bh._domainkey label may create an incorrect duplicated name if a full hostname is entered without checking its rules. Conversely, stripping the domain from an interface that needs a full owner can publish the wrong record. Record the intended fully qualified owner and compare it with the resulting public record through an authorized process.
Review existing data at the proposed alias before replacing it. The selector name may already be used by a prior setup, and an uncoordinated change can affect active mail. Keep the exact CNAME target in the approved change rather than inventing an IP address or flattening the alias. No private key needs to be obtained from Bullhorn for this documented customer-side step.
Keep support activation separate from DNS publication
After saving the CNAME, the guide instructs the customer to contact Bullhorn Support and request DKIM enablement for mass mails. Bullhorn completes the provider-side process. A DNS record therefore represents preparation for signing, not proof that the account has started signing. Do not invent an administrator-side activation control or close the task simply because the alias exists. Bullhorn DKIM instructions
A proposed support handoff should state the account, domain and mass-mail scope, with references to approved publication evidence. It does not need candidate resumes, client correspondence or authentication secrets. No support message was sent for this manuscript. Retain actual completion confirmation when an authorized operator performs the process, and keep any unresolved account restrictions visible.
RFC 6376, section 3.5 defines the signing domain and selector carried in the message signature. A separately authorized harmless sample should establish those fields and a trusted receiver's verification result. The correct alias alone cannot show that a particular message was signed by the intended domain or that an unrelated Bullhorn route uses the same configuration.
Review DMARC without replacing organizational policy blindly
Bullhorn's guide offers p=none when no DMARC record exists and says no additional setup change is needed when one already exists. Treat that as the provider's setup guidance, not proof that every existing policy is valid or compatible with the intended mail stream. Review the actual policy and legitimate-sender inventory before making a domain-wide change. Do not replace a working enforcement policy simply to match the example.
RFC 9989, section 4.4 explains alignment between the visible author domain and a passing authentication identity. A passing aligned SPF result or passing aligned DKIM result can satisfy the authentication condition. That protocol rule does not waive Bullhorn's documented SPF prerequisite for its mass-mail DKIM workflow. Authentication also does not guarantee acceptance, inbox placement or the safety of a recruitment message.
Fictional diagnosis and blank acceptance worksheet
A fictional staffing company, Juniper Talent, publishes the documented DKIM alias but never asks support to enable mass-mail signing. Its team marks DNS complete and mistakenly assumes that all messages from every Bullhorn product are covered. The proposed review separates the ATS mass-mail route from another automation product, requests authorized provider completion and leaves received-message acceptance open. This is a fictional scenario with no actual tenant action, support ticket or query result.
- Product, account, message category and current applicability: ______
- Intended author domain and actual envelope identity: ______
- Existing SPF preserved and documented include reviewed: ______
- Complete policy syntax, character strings and evaluation budget: ______
- Exact DKIM CNAME owner, target and conflict review: ______
- Support request scope and provider activation confirmation: ______
- Authorized signature, alignment and receiver evidence: ______
- DMARC policy owner, remaining exceptions and release decision: ______
Original implementation evidence, human review, source applicability, production routes, visual accessibility and owner release remain open. No account, DNS, support or sending action was performed.