Bullhorn Connexys SPF, DKIM and DMARC setup, step by step

FastForward documents an Email from organization feature that replaces its usual Connexys sender address with your own address. Its published instructions specify two sending IP ranges and a support activation step. That is a documented SPF and sender-identity workflow, not evidence of a complete branded DKIM setup. First confirm that your account uses FastForward and that support confirms this exact sending route; do not apply these instructions to Connexys on Salesforce, Bullhorn ATS or Bullhorn Back Office merely because the supplier is the same.

What this guide covers

This guide covers the FastForward feature, safe preparation of its documented SPF authorizations, support activation and receiver-side verification. It does not provide a DKIM selector or key, assert that DKIM is unavailable, or promise that SPF authorization alone satisfies your domain's authentication requirements. The public FastForward page does not establish DKIM record issuance, signing activation or the actual SMTP envelope domain for an individual account.

Bullhorn's FastForward instructions describe a support-enabled feature, not an Outlook or Lotus Notes transport integration. They list no visible publication or update date.

Confirm the product and current route first

Before editing DNS, record your FastForward account, the affected users and the intended visible From address. Ask your administrator to confirm that this is the FastForward sending service covered by the linked page. A Connexys-branded login or an email mentioning Bullhorn is not sufficient route identification.

Have support confirm the current applicability of the two published ranges, the actual envelope-sender domain used for the proposed feature, and whether a separate branded DKIM process exists for your account. If support supplies a newer route-specific packet, reconcile it with the published instructions before making a change. Do not combine authorizations from several Bullhorn products “to be safe.”

Keep a copy of the existing DNS records and the sender configuration. Confirm who controls the authoritative DNS zone and who can authorize the sender change. This is outbound email work: changing MX, nameservers, DNSSEC or security filtering is not a prerequisite established by the FastForward instructions.

The documented SPF values

FastForward's published ranges are:

The page also lists smtp.connexys.nl as an optional public hostname. A hostname alone does not define an SPF mechanism. Do not turn it into an include: or a: authorization without an explicit route-specific instruction. These are shared provider network ranges, not unique values generated for your organization.

The important question is where SPF is actually evaluated. SPF normally checks the SMTP MAIL FROM domain, not the visible From address. A null reverse-path uses the relevant HELO identity. The public page's instruction to authorize sending on behalf of your domain does not prove that every customer's envelope domain equals its visible From domain. Obtain that identity from support and confirm it from controlled receiver evidence before declaring authentication complete. SPF identity and processing rules.

If the evaluated domain belongs to the provider, do not attempt to publish its policy in your own DNS or claim that an apex change authenticates that provider domain. Resolve the route with support.

Prepare one correct SPF policy

At the confirmed SPF owner, inspect the existing TXT records. There must be one SPF policy beginning v=spf1, not a second SPF record for each service. Merge only the necessary authorizations into the existing policy while retaining legitimate senders and the existing qualifiers. Do not replace the whole record with a tutorial example.

These fragments illustrate the two documented network authorizations, not a complete policy to paste:

ip4:62.50.13.64/28 ip4:194.158.15.0/25

The DNS administrator should place the permitted mechanisms where the policy can evaluate them, before an existing terminal all mechanism when applicable. A policy using redirect= needs deliberate review; adding all causes redirect to be ignored. Preserve the intended policy rather than adding a new terminator by habit.

SPF permits at most ten evaluated DNS-dependent terms, including nested processing. That is not simply ten include entries. These literal ip4 mechanisms do not themselves require DNS lookups, but the rest of the policy can still exceed the budget. Audit the complete evaluated policy and any existing errors. An SPF qualifier also does not guarantee a particular recipient's delivery or rejection decision. SPF evaluation limits.

For owner mapping, mail.example.com is a placeholder, not a provider value. In the parent example.com zone its relative owner is mail; in a separately delegated mail.example.com zone it is that zone's apex, often represented by @. Use the DNS host's actual naming convention and preserve delegations. Do not publish at mail.example.com.example.com by entering a full name into a relative-only field.

Request activation after the agreed DNS preparation

The documented sequence is administrator preparation, a request to Connexys support for Email from organization, and support-side activation with notification. The official page gives support@connexys.com as the contact. Send only the necessary account and domain information through your approved support channel, not passwords or private signing keys.

Ask support to identify precisely which users and message routes are activated. The provider describes initial activation as free and warns that later changes, such as another email domain, may incur costs; confirm current commercial terms rather than treating this guide as a price commitment.

Do not consider DNS publication or a support acknowledgment equivalent to successful email authentication. Support's activation notice establishes a configuration milestone. The following message checks establish whether the intended route actually behaves correctly.

DKIM is an unresolved step, not a guessed record

The FastForward page does not supply a customer DKIM selector, public-key record, CNAME target or activation procedure. Do not copy a Bullhorn ATS bh selector, a Salesforce record, or a key from another tenant. Shared corporate ownership does not make those instructions valid for this product.

If support confirms a branded DKIM option, obtain its complete public DNS packet and signing activation requirements. Confirm the exact domain, selector, record type and owner, and preserve existing selectors and _domainkey delegations. Do not publish incomplete public keys or disclose private keys. A future CNAME-based packet also needs its DNS-host-specific conflict, proxy and flattening checks before implementation; this SPF-only guide is not that procedure.

If your acceptance criteria require branded DKIM, keep deployment open until that route is documented and verified. An SPF-based DMARC pass does not prove DKIM works.

Verify the actual message, not just DNS

After approved activation, an authorized tester should send a harmless message from the affected FastForward route to a controlled, valid recipient. No test messages were sent in preparing this article. Use an actual intended production path; a message sent separately through Microsoft 365 proves nothing about FastForward.

Inspect the receiving service's original message and authentication results produced inside its known processing boundary. Follow that service's documented handling of externally supplied Authentication-Results fields. A familiar authserv-id, header position or an attacker-inserted result is not trustworthy evidence on its own. Authentication-Results trust boundary.

Record the visible From, actual SMTP MAIL FROM identity, SPF result, every DKIM signature's d= domain and s= selector, and the trusted receiver's DMARC result. Also confirm that the visible sender is the intended address and that replies reach the expected inbox.

DMARC requires a passing SPF or DKIM identity aligned with the visible From under the applicable policy. Relaxed alignment uses the same Organizational Domain; strict alignment requires exact domain equality. Under current DMARC, Organizational Domain determination uses the DNS Tree Walk, not a universal “last two labels” rule. A passing child-domain identity does not automatically meet strict alignment. Current DMARC alignment.

If branded DKIM was separately configured, require the intended provider signature to pass and align with the intended visible From, plus trusted receiver dmarc=pass. Do not accept rewritten provider From or SPF-only DMARC success as proof of that DKIM task. EmailAuth's raw versus aligned DKIM results explains this distinction.

Preserve your existing direct or inherited DMARC policy and authorized reporting destinations. Do not weaken enforcement to make this feature appear to work. This guide does not create a new DMARC policy or add a reporting recipient.

Troubleshooting by observed result

Investigate SPF failures and errors even when aligned DKIM produces a DMARC pass. One successful mechanism should not hide a broken second mechanism.