Bullhorn SPF, DKIM and DMARC setup, step by step

For Bullhorn ATS mass mail, add include:_spf.bullhornmail.com to the appropriate existing SPF policy, publish the CNAME bh._domainkey pointing to bh._domainkey.bullhornmail.com, and ask Bullhorn Support to enable DKIM. Then verify a new message: the intended branded signature must pass DKIM and align with its visible From domain. DNS publication alone does not complete the setup. Bullhorn SPF instructions and mass-mail DKIM instructions.

No Bullhorn account, customer DNS, support request or delivered message was tested for this guide.

First identify which Bullhorn product sends the message

The official SPF procedure covers Bullhorn ATS and Bullhorn Back Office. The DKIM procedure specifically describes enabling DKIM on ATS mass mails. Do not extend that DKIM recipe automatically to Bullhorn Automation, Onboarding365, Adapt, a connected Microsoft 365 mailbox, or every Back Office notification. Those are separate sending paths until their own configuration and headers establish otherwise. Official SPF scope.

Before changing DNS, record the product, tenant, message type, intended From address and domain administrator. Decide whether the domain will be an apex such as example.com or a child such as recruiting.example.com. Confirm that Bullhorn Support will enable the chosen domain for the intended mass-mail route. An application's sender-address field is not evidence that signing is already active.

For a staffing organization, separate an ATS campaign from a recruiter sending directly through their normal mailbox. Keep both in the legitimate-sender inventory, but do not change the mailbox's working authentication while preparing the ATS route. This is a mail-authentication change, not a reason to send candidate information or launch a campaign during setup.

Keep the three message identities separate

• From domain: the address recipients see, such as recruiter@example.com.
• SPF identity: the SMTP MAIL FROM domain, commonly reflected in Return-Path after delivery. SPF checks whether the connecting server may send for that domain, not simply for the visible From address.
• DKIM identity: the signature's d= domain and s= selector. Receivers look for its public key under s._domainkey.d.

DMARC requires either a passing aligned SPF identity or a passing aligned DKIM identity. Relaxed alignment permits the same organizational domain; strict alignment requires the exact domain. An unrelated provider-owned domain does not align merely because its signature passes. SPF identities, DKIM signature fields, and DMARC alignment.

For example, if the intended visible From is recruiter@example.com, a passing intended signature with d=mail.example.com aligns under relaxed adkim=r when both share the same Organizational Domain, but not under strict adkim=s. A passing signature with d=example.com matches under both modes. These are identity examples, not claims about the identifiers a particular Bullhorn tenant emits. See raw DKIM results versus aligned DKIM policy results for why a cryptographic pass alone is insufficient.

This guide's acceptance test is deliberately stronger than “some mechanism made DMARC pass”: verify that the branded DKIM configuration you requested actually works. An aligned SPF pass can mask missing DKIM activation.

Add the current Bullhorn SPF authorization safely

Bullhorn currently documents this mechanism instead of a fixed list of outbound IP addresses:

include:_spf.bullhornmail.com

Use the maintained include rather than old outbound-host lists. Bullhorn's current SPF procedure also makes SPF preparation a prerequisite for the linked mass-mail DKIM workflow.

1. Export the existing DNS records and identify the exact owner to be changed.
2. Find its current TXT policy beginning v=spf1. Preserve unrelated TXT verification records.
3. Merge the Bullhorn mechanism into that policy before its terminal all mechanism. Keep other authorized senders and the existing qualifier unless the policy owner explicitly approves a change.
4. Evaluate the complete policy, including nested dependencies. SPF permits at most ten evaluated DNS-querying mechanisms/modifiers; the count is not just the visible number of includes.
5. Publish one SPF policy at that owner. Do not add a second v=spf1 TXT record alongside the first.

Before merging, inspect any redirect= modifier. It is ignored whenever an all mechanism is present anywhere in the policy; mechanisms after a matching all are unreachable. Do not add an all that unintentionally disables an existing redirected authorization policy. The terminal qualifier expresses an SPF result, not a guarantee of delivery or rejection. SPF evaluation and redirect rules.

For a domain with no existing SPF policy and no other authorized sources, Bullhorn's documented starting example is:

v=spf1 include:_spf.bullhornmail.com ~all

That example is not a replacement for a shared corporate policy. Multiple quoted character strings inside one TXT record can be valid; two competing SPF records are not. An include does not exempt a policy from lookup or DNS-size constraints. SPF record rules and limits.

If the actual MAIL FROM belongs to Bullhorn rather than your domain, an SPF pass there does not become aligned because you edited your apex. Preserve the documented provider prerequisite, but record the real envelope identity and rely on a verified branded DKIM path for DMARC where appropriate. The cited ATS instructions do not document a universal custom Return-Path switch; do not invent one.

Publish the DKIM CNAME at the correct owner

For an approved signing domain of example.com, the documented alias has this shape:

Type: CNAME
Full owner: bh._domainkey.example.com
Target: bh._domainkey.bullhornmail.com

This is a CNAME delegation to Bullhorn's public-key location, not a TXT record containing the target hostname. Bullhorn operates the signing side; the customer does not publish or request its private key. Follow the official mass-mail DKIM record, not an unrelated product's generated selector.

The DNS zone controls the label entered in the panel:

• In the example.com zone, signing as example.com normally uses relative owner bh._domainkey.
• In that same zone, signing as recruiting.example.com uses relative owner bh._domainkey.recruiting.
• If recruiting.example.com is a separately delegated DNS zone, the relative owner there is bh._domainkey.
• If _domainkey.example.com is separately delegated, publish relative owner bh in that authoritative zone to create bh._domainkey.example.com. For a delegated _domainkey.recruiting.example.com zone, bh likewise creates the child signing owner. Preserve existing NS authority and other selectors; an edit in the parent zone is not a substitute for editing the authoritative delegated zone.

These are owner-name examples, not proof Bullhorn has activated either domain. The intended full owner must remain bh._domainkey.<approved-signing-domain>. Check whether the panel appends the zone automatically so it does not create example.com.example.com.

Inspect existing data at the exact selector before saving. A CNAME cannot coexist with ordinary TXT, A, MX or another competing alias at that same owner. Do not delete another service's record to make room; ask the relevant owners to resolve the collision. Other DKIM selectors elsewhere in the zone can remain. The CNAME restriction concerns the exact owner, not the entire _domainkey namespace. DNS alias rules.

Keep the DKIM CNAME DNS-only and unflattened where your DNS host provides proxy or flattening controls. In Cloudflare, choose DNS only and turn the relevant per-record Flatten option off when available. Zone-wide flatten-all overrides per-record control: it must not suppress the issued literal alias. Turn that setting off if applicable only after coordinating affected services with the zone owner; stop if this cannot be done safely. Cloudflare flattens apex CNAMEs by default and same-zone targets regardless of the setting. The documented bh owner is not the zone apex and its Bullhorn target is external to these example zones, but if a proposed layout triggers mandatory flattening that cannot preserve the required CNAME answer, stop and arrange a supported layout. Do not invent a bypass, replace the alias with an A record or remove an NS delegation. A dashboard alias is insufficient if public DNS returns an IP instead. Cloudflare CNAME verification controls and flattening controls and exceptions.

No apex MX change is part of this documented Bullhorn procedure. Changing inbound-mail routing would be a separate, potentially disruptive action.

Ask Bullhorn to activate mass-mail signing

After the alias resolves correctly, contact Bullhorn Support with the tenant, approved sending domain and request to enable DKIM on mass mails. Include the public owner/target and verification time, not candidate records, passwords or private keys. Bullhorn completes the provider-side enablement. Activation requirement.

Keep the support confirmation separate from DNS evidence. Bullhorn's SPF guidance allows roughly 24–48 hours for DNS propagation, but elapsed time is not proof of signing activation. If the alias is correct and a new message is unsigned, investigate activation and route selection before repeatedly changing DNS.

Retain the existing DMARC policy and reporting

Check the policy applicable to the visible From domain, including inherited organizational policy for a subdomain. Do not replace p=quarantine or p=reject with a generic setup example, remove existing report destinations, or create a duplicate DMARC policy.

If no applicable policy exists and the domain owner chooses an initial monitored rollout, a TXT record can take this illustrative form at _dmarc.example.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

For that apex owner, a panel operating on example.com normally uses relative name _dmarc. If an approved first policy instead belongs at _dmarc.recruiting.example.com, enter _dmarc.recruiting in the parent zone or _dmarc in the separately delegated recruiting.example.com zone. Check the full resulting owner; do not create a child policy merely to bypass existing inherited protection.

Replace the address with an approved, working report destination. When its destination host has a different Organizational Domain from the domain where the DMARC policy was found, the report-generating receiver must check the required DNS authorization. Destinations within the same Organizational Domain are excepted; a different hostname alone does not make a destination external. The reporting provider supplies any necessary authorization record, and protocol authorization does not replace the policy owner's privacy and data-sharing approval. Aggregate-report destination authorization, RFC 9990 section 4. Reports can contain operational information, so choose recipients deliberately. p=none requests monitoring rather than enforcement; it does not prevent spoofed mail from arriving.

Use reports to look for unexpected Bullhorn paths, missing branded signatures and changes in sending IPs. Do not enforce a domain-wide policy based on one ATS test while other legitimate senders remain unreviewed. In particular, RFC 9989 requires valid DKIM for domains publishing p=reject; a single SPF-only result is not an enforcement-readiness plan. DMARC policy and deployment guidance.

Verify public DNS before checking delivery

The following commands are read-only examples. Replace example.com with the approved domain and use the actual MAIL FROM domain for the SPF query. They have not been run against a customer domain here.

dig TXT example.com
dig CNAME bh._domainkey.example.com
dig TXT bh._domainkey.bullhornmail.com
dig TXT _dmarc.example.com

Check full responses, not only a green indicator. Expected observations are one valid SPF policy at the relevant owner, the exact DKIM CNAME target, a usable public key through the alias, and the intended applicable DMARC policy. A timeout, SERVFAIL, NXDOMAIN and a valid answer containing no TXT record are different findings.

For a child From domain, also inspect _dmarc.<child-domain> and the applicable parent policy. If a subdomain is delegated, query the nameservers authoritative for that child. Compare authoritative answers with an independent recursive resolver after the relevant TTL has expired. A correct edit in an inactive DNS provider's dashboard will not change public answers.

Accept the setup only after an exact-route message test

An authorized administrator should generate a harmless new ATS mass-mail sample to controlled external recipients after support confirms activation. Do not use an employee's normal mailbox as a substitute. Avoid real candidate details, attachments or a production-wide mailing.

Open the raw headers and use the Authentication-Results inserted by the trusted receiving system. A message can contain untrusted or older results from other hops. A familiar authserv-id name or a header near the top is not sufficient proof of origin. Use the receiving service’s authenticated message view or its administrator-confirmed trust-boundary handling to identify the result actually added for this delivery. If that provenance is uncertain, leave acceptance open. Authentication-result trust and forged-header risks.

Record the following for each intended sender domain and route:

• UTC test time, product, message category and support activation reference.
• Visible From and receiver-evaluated header.from.
• Actual smtp.mailfrom, connecting IP and SPF result.
• Every DKIM d=/s= pair, and the receiver result for the intended branded signature.
• Effective alignment modes, DMARC result, and which aligned mechanism supplied the pass.

Pass criteria: the intended From is used, not rewritten to a provider address; the intended branded DKIM signature returns dkim=pass and aligns under the applicable adkim; DMARC returns pass; and SPF is evaluated for its actual identity without an unresolved authorization or processing error. If SPF passes on an unaligned provider domain, record that expected limitation separately. It is not an SPF authentication failure, provided branded DKIM supplies alignment.

If SPF returns fail, softfail, permerror or temperror, investigate it even when DKIM allows DMARC to pass. Do not relabel a real SPF error as harmless “nonalignment.” A direct-route test should not be signed off with an unexplained SPF fault. Forwarded copies can break SPF independently; compare an unforwarded sample before diagnosing the original sender.

Troubleshooting Bullhorn authentication

The alias exists, but the message has no branded signature. Check that Support enabled the exact domain and mass-mail route. Compare the test timestamp with activation, and confirm the message did not come from a connected mailbox or another Bullhorn product.

DKIM fails or the key is missing. Compare the message's s= and d= with the DNS owner queried. Check for a TXT record mistakenly used instead of the CNAME, a doubled domain suffix, selector collision or a nonresolving target. If DNS is correct, retain the header result and ask Support to investigate signing or content modification.

SPF fails or softfails. Use the actual smtp.mailfrom and observed connecting IP. Confirm the maintained include is present at the correct owner and investigate unexpected relays; do not authorize an unknown IP just to remove the failure.

SPF reports permerror. Repair duplicate policies, invalid syntax or an exceeded nested lookup budget. Review stale senders with their owners rather than flattening Bullhorn's changing infrastructure into an unmanaged IP list.

SPF reports temperror. Investigate temporary DNS failures or timeouts at the evaluated domain and its dependencies, then retest. More than ten evaluated DNS-querying terms is a permanent error, not a transient one. SPF result definitions.

DMARC passes but branded DKIM fails. SPF may be providing the aligned pass. The requested DKIM setup is still incomplete; repair it before closing the change.

External messages fail while internal delivery works. Internal gateways may have local handling exceptions. Compare external authentication rather than expanding allowlists or weakening the whole domain's policy.

Keep the configuration maintainable

Retain the approved DNS change, support completion and redacted acceptance evidence with a named owner. Retest after sender-domain changes, product migrations, relay changes or signing-key changes. Keep old verification keys while queued mail still needs them and coordinate removal with Bullhorn. Authentication troubleshooting should leave unrelated senders, inbound mail and established DMARC protection intact.