Spamhero SPF, DKIM and DMARC setup, step by step

To authenticate SpamHero outbound mail, authorize the correct direct-account or reseller sending service in your existing SPF policy, then enable DKIM in Outbound > Outbound Settings. Publish the CNAME records displayed there if you want SpamHero to sign with your own domain. Without those CNAMEs, enabled DKIM uses an internal domain. Finish by checking public DNS and a delivered message for a passing, aligned custom-domain signature and dmarc=pass. SpamHero authentication instructions.

This guide covers SpamHero Outbound SMTP, not inbound spam filtering alone. No customer account, DNS change or sending test was performed.

Confirm the outbound route and prerequisites

SpamHero describes three ways to use its outbound service: individual email clients, a dedicated mail server relaying through SpamHero, and a Microsoft 365 outbound connector. A domain's inbound MX records do not establish which of these routes its outgoing mail takes. Outbound service overview.

Before changing authentication, gather:

• Administrative access to the correct SpamHero account and sending domain, with Outbound SMTP available.
• Whether the account is direct or managed through a reseller.
• The DNS provider authoritative for the relevant domain or delegated subdomain, and permission to make the specific changes.
• The actual source application or mailbox, relay configuration and any alternate route.
• The intended visible From domain, envelope sender domain and DKIM signing domain.
• A copy of existing SPF, DKIM and DMARC records, plus the operator responsible for recovery.

SpamHero's overview lists outbound support for Standard, Enterprise and Reseller plans; check your account's current entitlement and limits rather than interpreting a visible inbound dashboard as proof of outbound access. Follow the linked routing instructions for the chosen connection method before testing authentication. Do not invent an SMTP hostname, password or connector condition from a DNS example. Service availability and route choices.

For a Microsoft 365 source, retain its separate authentication configuration where applicable. The raw DKIM versus aligned DKIM guide explains why each passing signature needs its own identity comparison. A signature added before SpamHero is useful only if it still validates after the complete route.

Configure the correct SPF policy

Direct accounts and resellers use different instructions

For a direct account, SpamHero documents this authorization term:

include:spf.spamhero.com

Resellers must instead obtain the SPF include shown in their reseller control panel. Do not assume the public direct-account term is appropriate for a white-label route. SpamHero SPF setup.

SPF normally evaluates the domain in the SMTP MAIL FROM, commonly reflected in the delivered Return-Path. It does not authenticate the visible From address directly. Confirm that domain before selecting the DNS owner to edit. An update at example.com will not automatically repair a policy evaluated at bounce.example.com. Null-envelope messages are a separate case in which SPF uses the HELO identity. SPF identities, RFC 7208.

Merge authorization without replacing other senders

If the evaluated owner already has an SPF TXT policy, edit that policy rather than creating another v=spf1 record. Add the applicable term in the intended evaluation position before its terminating all; preserve legitimate senders and the existing termination unless a separate policy review approves changing it. Any all mechanism makes redirect ignored regardless of qualifier. Preserve a redirect-only policy’s intended control flow rather than appending all or concatenating complete policies. SPF precedence

When no policy exists, build one from the full inventory of actual senders. SpamHero's published starter includes an a mechanism; that would authorize addresses resolving for the evaluated domain and should not be included without a reason. A website's address is not automatically an outbound mail server. Do not use another organization's example IP or a reseller value guessed from its brand name.

There must be one SPF policy per DNS owner, although unrelated TXT records can coexist. SPF permits at most ten evaluated DNS-dependent terms, including nested include and redirect dependencies. Count the whole evaluation, not just visible includes; a, mx, ptr and exists also consume this budget. ip4, ip6 and all do not. Avoid a static copy of today's provider IPs as an improvised flattening fix. SPF publication and processing limits.

Enable custom-domain DKIM

In the intended domain's SpamHero control panel:

1. Open Outbound > Outbound Settings.
2. Under Other settings, enable Enable DKIM signing for outbound messages.
3. Copy every displayed custom-domain CNAME owner and target.
4. Publish those exact records in the authoritative DNS zone.
5. Revisit the account and confirm the saved signing setting and displayed DNS requirements, then perform the message tests below.

SpamHero distinguishes internal-domain signing from custom-domain signing: the CNAME step makes the latter possible. Its public page does not establish a universal selector, universal CNAME target or a separate verification-button name. Use the actual account values and controls. Official DKIM workflow.

For an issued owner shaped like SELECTOR._domainkey.example.com, enter SELECTOR._domainkey only if the DNS editor appends example.com. Otherwise use the full name. SELECTOR is a placeholder, not a suggested SpamHero selector. Check the saved answer for doubled suffixes such as example.com.example.com.

For an account-issued signing domain news.example.com, map the full owner SELECTOR._domainkey.news.example.com to SELECTOR._domainkey.news in the parent example.com zone, SELECTOR._domainkey in a delegated news.example.com zone, or SELECTOR in a delegated _domainkey.news.example.com zone. These are illustrative mappings, not issued selectors. Preserve the account’s exact target and existing NS delegation.

A CNAME cannot share its exact owner with ordinary TXT, A or MX data. Investigate a collision before replacing anything; another sender may depend on that owner. Keep unrelated selectors. Publish a CNAME as a CNAME, not as TXT containing its target. Do not generate your own public key for a provider-managed CNAME route.

Required authentication aliases must remain DNS-only and unflattened. In Cloudflare, turn the affected record’s Flatten control off where available and ensure applicable whole-zone settings preserve the literal CNAME answer. Flatten-all overrides record-level choices. Mandatory apex or same-zone flattening may have no off switch: if required answers cannot be preserved, stop and arrange a supported configuration with the DNS operator and SpamHero. Do not disable unrelated website proxying or change DNSSEC as a workaround. Cloudflare flattening controls and verification guidance

Coordinate any shared zone-level flattening change with the DNS owner and owners of other affected services. If _domainkey or a child below it is legitimately delegated, publish through that delegated authority; do not remove its NS records merely to satisfy a verifier that queried the parent zone. Confirm the public DNS path rather than replacing a working delegation.

Preserve DMARC and check alignment

DMARC compares the visible From domain with an authenticated domain. It passes when SPF passes and aligns, or DKIM passes and aligns. Relaxed alignment requires the same Organizational Domain; strict alignment requires an exact domain match. Inspect aspf and adkim in the applicable policy. A passing signature for an unrelated internal SpamHero domain is not aligned with your brand. Current DMARC specification, RFC 9989.

For example, a message from person@example.com signed with d=mail.example.com can have relaxed DKIM alignment but not strict alignment. A passing d=example.com aligns in both modes. A signature for an unrelated service domain has neither. These examples explain the comparison; they are not claims about SpamHero's actual account-issued identities.

Keep an established DMARC policy and reporting configuration intact. Do not replace p=reject or p=quarantine with p=none simply to onboard a sender. First query _dmarc.FROM-DOMAIN; if the exact From domain has no record, assess the applicable parent-domain policy and inheritance before adding a subdomain override. Publish no more than one DMARC policy at the selected owner.

For From: person@example.com, the full policy owner is _dmarc.example.com, entered as _dmarc in the example.com zone. For From: person@mail.example.com, an explicit child policy would be _dmarc.mail.example.com: enter _dmarc.mail in an editor for the example.com zone, or _dmarc in a delegated mail.example.com zone. Use the full name only when the editor expects it; @ is not the DMARC owner. Check the saved full hostname before proceeding.

Only when there is no direct or applicable inherited DMARC policy at all, including p=none, obtain domain-owner approval of the monitoring plan before creating a first policy. At the applicable owner described above, publish one TXT value, matching the native first-policy shape:

v=DMARC1; p=none

This minimal value does not request reports. Add the actual rua=mailto: destination supplied by an approved reporting service or provisioned mailbox if aggregate reporting is wanted; do not copy another domain’s address. When the report destination has a different Organizational Domain from the policy domain, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain is excepted; a different hostname alone does not trigger it. Obtain the service’s issued authorization rather than guessing. RFC 9990 section 4

Protocol authorization is separate from owner approval to share reports: review recipient, privacy, access, retention and analysis responsibility. Failure reports may expose message or personal information, so do not enable ruf casually. Current RFC 9989 removes pct; do not design a percentage-based rollout around it. Preserve existing policy and review every legitimate route before enforcement. DMARC policy and failure-report privacy

Verify DNS and a real delivered message

First inspect the published records

Run these read-only examples after replacing every uppercase placeholder with your own observed value. DNS-ZONE means the authoritative zone, not necessarily the full record owner.

dig +short NS DNS-ZONE
dig @AUTHORITATIVE-NS +short TXT ENVELOPE-DOMAIN
dig @AUTHORITATIVE-NS +short CNAME ISSUED-DKIM-OWNER
dig +short TXT ISSUED-DKIM-OWNER
dig +short TXT _dmarc.FROM-DOMAIN

Repeat the CNAME and key queries for every issued owner. Expect the exact supplied alias target and a resolvable public key behind it. A recursive TXT response can include the alias followed by its target's TXT data. Multiple component strings within one DKIM TXT record concatenate without inserted spaces into one logical value, not separate keys. Preserve the complete tagged key. DKIM TXT representation Check the single SPF policy at the actual envelope domain and any inherited DMARC policy separately.

Compare authoritative responses with an independent recursive resolver. Correct authoritative data with older cached data may require waiting for relevant TTLs, including negative caching. A wrong authoritative owner or target will not correct itself with time. These lookups do not prove that SpamHero is using the key or that a message passes SPF.

Then test each real outbound route

Send a harmless representative message through the intended client, mail server or Microsoft 365 connector to an external mailbox you control. For each route, keep the timestamp, source and relay-log correlation, raw delivered headers and these observations:

Use recipient-controlled diagnostics or authentication headers whose provenance is established by the receiving administrator's trust boundary, including documented or administrator-confirmed removal or isolation of externally supplied authentication headers, or obtain an authenticated receiver trace. A familiar authserv-id or header position alone is not proof of trust. If provenance is unclear, leave acceptance pending and obtain a provenance-established receiving-service diagnostic result instead of relying on an arbitrary Authentication-Results line or an old result copied through forwarding. Authentication-Results security guidance.

For this custom-DKIM setup, aligned SPF alone is not completion: require the intended branded DKIM pass and alignment as well as trusted DMARC pass. A rewritten provider From does not establish the intended brand’s authentication. DMARC can legitimately pass through DKIM when forwarding breaks SPF, but investigate a direct-route SPF error separately. Record any forwarded-message test as a distinct route. Authentication also does not guarantee inbox placement or prove that message content is safe.

Troubleshoot the result, not just the dashboard

SpamHero explicitly distinguishes downstream inbound SPF problems from a domain's outbound SPF policy. Do not disable inbound authentication or expand trusted networks as a shortcut for an outbound DKIM problem. Inbound SPF handoff explanation.

Recovery and ongoing maintenance

Before a change, retain complete affected records, TTLs, account settings and relay configuration. If the new route fails, pause that route or restore the last known-good configuration through the responsible administrator. Do not weaken domain-wide DMARC to conceal a single sender failure.

Keep provider-managed CNAMEs while the service needs them, and do not remove another active sender's selectors. On departure, first prove the replacement route works and account for queued mail; then remove only obsolete authorization and delegation. Protect SMTP credentials and keep private information out of public diagnostic tickets. Retest after a reseller migration, connector change, DNS move or content-processing change.