Treat the BlueHornet instructions as a historical route
The source for this guide is BlueHornet Networks' three-page white paper, “Email Authentication: An Informational Primer and How-To,” copyrighted 2013. It describes a client-managed DNS arrangement with provider-assisted DKIM provisioning. This is a historical implementation reference, not confirmation that the same account controls, infrastructure, support process or service availability apply today. It must not be substituted for instructions for a successor platform merely because of a corporate relationship. The actual account and current product applicability remain open. BlueHornet white paper, pages 1–3
The useful operational distinction in that paper is the division of responsibility. The customer identifies the sending domain and account context, BlueHornet generates the relevant authentication material, the customer publishes the supplied DNS data, and the provider completes its side of setup. A responsible review can preserve that dependency chain without claiming an old example is a current ready-to-paste configuration. No account access, support exchange, DNS publication or message test has occurred for this draft.
Identify the intended domain and existing CNAME use
The historical instructions ask the customer to identify the domains intended for sending. They explicitly say those domains cannot be the same as the CNAME used with BlueHornet. Preserve that provider constraint when assessing this documented route. Do not silently treat a tracking alias, web-facing hostname and signing identity as interchangeable merely because they share the organization's domain suffix. BlueHornet white paper, “Setting up DKIM,” page 2
Prepare an identity inventory before requesting any change. Record the exact sending domain, visible From domain, intended reply address, existing CNAME use and responsible owner. If several business units or agencies share the account, identify which domain owner approves each route. A campaign operator's ability to select an address does not by itself establish authority to publish records in that domain's DNS.
The inventory should also identify existing selectors and other services using the same namespace. Avoid overwriting a working authentication dependency while trying to recreate the historical illustration. The actual supported record owner and value must come from the applicable service configuration, not from a diagram or a record seen on someone else's domain. Any unresolved difference between the historical instructions and current account behavior belongs in the release decision.
Keep provider provisioning and DNS publication separate
The white paper directs the customer to supply the domain or domains and associated BlueHornet username to a Deliverability Management Services or account-management representative. It then describes the provider generating key parts, the customer entering the supplied data in the zone, and the customer notifying the contact so BlueHornet can finish DKIM setup. The provider's stated completion interval is historical information, not a current service-level promise. BlueHornet white paper, pages 2–3
For a proposed implementation, bind the account reference, approved domain, supplied public DNS data and change approval in one controlled record. Do not include passwords or private keys in the worksheet. The source's account-username handoff is not permission to send credentials or contact a third party without the domain owner's authorization. This article describes a process to review, not an instruction already executed on the reader's behalf.
A public DKIM record and an enabled signer establish different facts. The signature identifies its signing domain and selector; the receiver uses that information to find verification material. A published record cannot make an application sign, and an application-side setting cannot guarantee that DNS serves the correct public material. The acceptance plan must retain both responsibilities and eventually connect them through an actual authorized message observation. RFC 6376, sections 3.5 and 3.6.2.2
Do not turn the illustration into reusable DNS data
The historical PDF contains a DNS-editor screenshot and illustrative domains. Those are examples, not generated values for the reader's account. Obtain the supported current owner, record type and complete public value before planning publication. Preserve the fully qualified name separately from the string entered in a DNS editor, since a provider may append a zone suffix or interpret relative input differently. BlueHornet white paper, page 3 RFC 1035, section 5.1
TXT records can contain multiple character strings. A long public-key value may appear wrapped or split without representing several separate records. Review the logical value and record boundaries rather than assuming visual formatting is the wire representation. Conversely, a truncated screenshot cannot supply missing key material. Never reconstruct a public key from the visible beginning of an example. RFC 1035, section 3.3.14
Reassess the old SPF and Sender ID framing
The white paper's SPF instructions appear under “Setting Up Sender ID.” They include an example authorization for BlueHornet and explain that an existing SPF policy should be extended rather than replaced. That preservation principle is useful, but the historical framing is not a complete statement of today's SPF or DMARC semantics. The screenshot and prose also illustrate different final all qualifiers; neither should silently decide the organization's current policy. BlueHornet white paper, page 3
Use the current applicable SPF rules when reviewing a proposed record. SPF evaluates the relevant SMTP MAIL FROM identity or HELO identity, not simply the visible From address. Publish SPF as TXT, maintain one applicable policy, and review the evaluated DNS-querying terms across nested dependencies. Adding another independent policy does not merge permissions. The ten-term evaluation limit is not merely a count of network requests or top-level include strings. RFC 7208, sections 2.3–2.4, 3.1–3.3 and 4.6.4
Do not assume the old example's authorization remains applicable to a current tenant or another product. Confirm the actual outbound route and approved egress information. Likewise, do not adopt historical claims about mailbox-provider image loading, complaint thresholds or processing speed as present-day benefits. They are not necessary to explain the configuration responsibility and do not establish a delivery guarantee.
Require message evidence beyond provider completion
When separately authorized evidence is available, review a message from each in-scope route. Record its visible From domain, relevant envelope identity, DKIM signing domain and selector, and the receiver's authentication results. DMARC requires a qualifying aligned passing SPF or DKIM result. A valid signature for an unrelated domain or an SPF pass for an unaligned identity does not by itself establish DMARC success. RFC 9989, section 4.4
The white paper itself warns that authentication is not a guaranteed path to the inbox. Preserve that limitation. Authentication does not replace reputation assessment, recipient preferences or other receiver decisions, and it does not prove a message's business request is safe. A publication record, a provider completion message and a received-message result should remain separate evidence items. BlueHornet white paper, “Why Authenticate?,” page 1 RFC 9989, section 2.4
Fictional diagnosis: an old diagram mistaken for current approval
In a fictional company, Brookline Events, an administrator finds the 2013 white paper while preparing a mail-platform review. A colleague proposes copying its selector and SPF example into the live zone and treating the old completion interval as a launch commitment. The proposed sender domain is also the hostname already used for the platform's CNAME. No such incident or test has been observed; this is a fictional acceptance exercise.
The reviewer stops at the missing applicability evidence. The team identifies the actual account product, resolves the documented hostname constraint and obtains current supported public record data before proposing changes. It preserves other authorized senders and keeps the provider-completion and message-verification tasks open. The historical document informs questions and responsibilities; it does not authorize a new deployment by itself.
Blank historical-route acceptance worksheet
- Actual product/account and applicability of the 2013 workflow: ____.
- Approved sending domain, visible From domain and domain owner: ____.
- Existing BlueHornet CNAME use and constraint resolution: ____.
- Authorized provider contact and nonsecret account reference: ____.
- Current supplied public record owners, types and complete values: ____.
- Existing SPF policy and legitimate senders retained: ____.
- DNS operator, change approval and rollback record: ____.
- Provider provisioning, publication and completion evidence: ____.
- Authorized received-message identities and alignment result: ____.
- Unresolved historical/current differences and release approver: ____.
The worksheet is blank. Original evidence, human/SME review, source applicability, production routes, visual/accessibility review and owner release remain open. No current service capability, tenant execution or successful authentication result is claimed.