Establish that mail actually uses the outbound service
SpamHero's SPF and DKIM guide explicitly concerns its Outbound SMTP service. The page is dated November 6, 2026 and was reviewed for this manuscript on November 9, 2026. Its outbound overview distinguishes ways to route outgoing mail through the service. An organization using SpamHero only for incoming filtering should not assume that its outbound messages are automatically covered.
Record the account, domain, source mail system and intended relay path. Identify whether the organization is a direct customer or works through a reseller, because the documented SPF instructions distinguish those cases. Also record which mail categories bypass the relay, if any; a working route for one source does not establish all senders in the organization.
This is documentary guidance and a proposed acceptance process. No relay credentials, account settings, connectors or DNS records have been created or changed. Current-account applicability and the broader catalogue implementation requirement remain open. Outbound authentication guide; Outbound service overview
Apply the appropriate SPF instruction to one complete policy
For a direct account with an existing SPF policy, the guide instructs administrators to add include:spf.spamhero.com before the terminating all mechanism. It explicitly tells resellers to use the include published in the reseller area instead. That distinction should remain visible in the change request rather than being lost when an example is copied.
The page also provides a starting policy for a domain without SPF, including an a mechanism and softfail termination. Do not treat that starting point as an automatic authorization decision for every organization. Review whether each proposed mechanism represents an intended sender and account for other legitimate outbound services.
Multiple selected SPF records produce an error, so do not create a separate policy merely for SpamHero when one already exists. Preserve mechanism ordering and review nested DNS-dependent evaluation terms. A successful text edit is not proof that the relevant message path is authorized or aligned. Enabling SPF; RFC 7208, section 3.2; RFC 7208, section 4.6.4
Distinguish DKIM enablement from custom-domain signing
The provider's documented path is Outbound > Outbound Settings. Under Other settings, select Enable DKIM signing for outbound messages. The guide then describes optional displayed CNAME records: configuring them causes the service to sign using the customer's domain; otherwise it signs using an internal domain.
This distinction is central to acceptance. A message may carry a valid signature while using an identity different from the organization's visible author domain. Record whether the intended outcome is merely provider signing or custom-domain signing, and retain the exact account-displayed aliases for the latter. Do not invent a selector or assume another customer's targets apply.
Before publication, compare the issued names with existing records and the actual DNS editor's suffix behavior. Review conflicts and preserve a before-state. The public guide supplies the workflow, but it does not prove that any account's signing toggle is enabled or that its aliases have been published. Enabling DKIM
Keep inbound filtering and outbound authorization separate
Receiving mail through a filtering gateway and sending mail through an outbound relay are different paths. The proposed inventory should show both where relevant, but the outbound authentication change must be justified by the sending path. Do not add sender authorization merely because a provider's IP address appears on an incoming hop.
SPF evaluates the connecting sender against the policy for its specified SMTP identity, including MAIL FROM. The visible From address is not automatically the policy lookup domain. DMARC adds an alignment comparison with the author domain, so a passing result for an unrelated service identity may not satisfy the organization's intended outcome.
If a mail system already signs messages before relay, preserve and inspect the resulting signatures rather than assuming they remain valid through every transformation. The proposed acceptance should identify the final signed content and trusted receiver outcomes. This manuscript does not disable inbound checks or change security controls to make a message pass. RFC 7208, section 2.4; RFC 6376, section 3.5; RFC 9989, section 4.4
Verify the received route and its identities
The proposed final check is an authorized representative message that actually traversed the intended outbound route. Retain a minimized header extract with its author domain, envelope identity where available, DKIM signing domain and selector, and trusted receiving-system results. Record the sending time and source system so another path's evidence cannot be substituted accidentally.
Compare the observed signing domain with the intended custom-domain configuration. If it remains an internal service domain, review whether the account's displayed aliases and signing setup match the proposed design. Do not conclude that all authentication failed solely because one signature is unaligned; examine the relevant passing identities under DMARC's rules.
Separate authentication acceptance from relay delivery events, inbox placement and recipient engagement. The provider's deliverability language is not a guarantee that every destination will accept or display the message. Likewise, an authenticated message does not establish that its business request is legitimate. RFC 9989, section 4.4; Custom versus internal signing
Acceptance worksheet for an outbound-relay handover
Use this original proposed worksheet to connect the source system, account type and final received identity.
- Route scope: account, direct or reseller relationship, source mail system and actual outbound relay path.
- Coverage: message categories included, bypass routes and accountable owners for any exceptions.
- SPF request: correct direct or reseller include, complete affected policy and preserved legitimate sources.
- DKIM intent: internal-domain or custom-domain signing, relevant account setting and exact displayed CNAME records.
- DNS review: intended owner names, alias targets, existing conflicts and approved publication scope.
- Message evidence: authorized sample, route timestamp, author and signing domains, selector and trusted results.
- Security controls: confirmation that inbound filtering, connectors and credentials were not changed outside the approved task.
- Release: reviewer, rollback owner and unresolved current-account or production evidence.
This worksheet is blank planning guidance. It contains no passwords, API secrets, real message bodies or executed verification results.
Fictional diagnosis: DKIM passed for an internal domain
A fictional organization enables outbound DKIM and sees a passing DKIM result on a sample. It announces that its own domain is now authenticated without comparing the signature's signing domain with the visible author address. The sample instead shows an internal service identity.
The proposed review distinguishes successful provider signing from the desired custom-domain alignment. The team checks the documented CNAME step and the actual account values, while preserving the existing SPF policy and unrelated senders. It also verifies that the sample traversed the intended outbound relay rather than another mail source.
No policy is weakened simply to change the dashboard appearance, and no inbound filtering rule is altered to repair an outbound configuration gap. The final handover records the evidence that still needs to be gathered after an authorized change. This is a fictional diagnosis, not a real SpamHero incident or an executed mail test.