Hornetsecurity SPF, DKIM and DMARC setup, step by step

For an existing Hornetsecurity Spam and Malware Protection outbound route, publish the correct domain's DKIM CNAME pair, then activate DKIM signature for outgoing emails in the Control Panel. Incoming DKIM validation is a different control. SPF authorization also depends on whether your messages actually leave through the gateway. Hornetsecurity DKIM setup

This guide covers an already approved outbound deployment using ordinary public DNS. It does not set up mail routing, change MX, onboard Microsoft 365 connectors, configure inbound filtering, or migrate records into DMARC Manager.

On this page: Confirm the route and DNS branch first · Use SPF only for the actual outbound service · Publish the Hornetsecurity DKIM pair · Activate outbound signing separately · Keep DMARC Manager and policy changes outside this setup · Verify a real message on the intended route · Troubleshooting without broadening access · Frequently asked questions

Confirm the route and DNS branch first

Before making changes, have the administrator identify the existing outbound route, approved domain and From address, DNS authority, current authentication records and intended signing behavior. Preserve the previous DNS and configuration state. A subscription name alone is not proof that outbound mail traverses a particular gateway.

Inspect Email Security > Spam & Malware Protection > Settings in the Control Panel. The vendor uses its recommended MX entries to distinguish DKIM branches: names containing hornetsecurity or vade use the Hornetsecurity pair below; pp-tp identifies a different Proofpoint branch. This is an inspection step, not an instruction to change MX. Stop if the branch is ambiguous or does not match this guide. Choosing the correct DKIM records

The brand indicator chooses the documented key branch; it does not establish that a particular outbound message used the gateway. Verify that separately through the approved route configuration and later message evidence. Do not infer another product's complete setup from shared branding or corporate ownership.

Use existing authorized administration access. If your role cannot inspect or change the relevant controls, ask the existing administrator to carry out the approved step. Do not grant broader permissions, add a relay or change inbound protection merely to make this procedure available.

Use SPF only for the actual outbound service

For Spam and Malware Protection, Hornetsecurity documents this starting TXT policy:

v=spf1 include:spf.hornetsecurity.com ~all

For an existing 365 Total Protection deployment, its documented example includes Microsoft's authorization as well:

v=spf1 include:spf.protection.outlook.com include:spf.hornetsecurity.com ~all

These are product-scoped examples, not replacements for an existing multisender policy. The provider expressly excludes an IP/Hostname primary environment with no configured outbound relays from needing its SPF authorization. Inbound protection alone is not a reason to authorize outbound sending. Current Hornetsecurity SPF guidance

At the actual SPF policy owner, inspect all TXT values and identify those beginning v=spf1. Maintain one deliberate SPF policy, preserving other authorized senders and the approved terminal qualifier. If no policy exists, first establish the full sender inventory and correct owner. If multiple policies exist, resolve them instead of adding another.

SPF evaluates the SMTP MAIL FROM identity in normal mail flow, with HELO relevant for an empty reverse path. It does not authenticate Reply-To or automatically evaluate your website's apex. Inspect the actual envelope domain in a controlled message before claiming that a published policy applies. SPF identities and processing

Put authorized mechanisms before the terminal all; text after all cannot authorize another sender. Any all mechanism also suppresses redirect, so redirect-based policies need an intentional redesign rather than pasted additions. Check the ten DNS-lookup-causing-term limit, including nested evaluation. Counting visible includes alone is insufficient. Do not remove legitimate senders or manually flatten changing service addresses just to silence a lookup warning.

The Microsoft example is not an onboarding guide. Keep the already approved upstream connector and routing configuration unchanged, and retain existing upstream DKIM unless a separate approved design calls for a change. Adding a gateway signature is not permission to disable another working signer.

Publish the Hornetsecurity DKIM pair

Only for the confirmed Hornetsecurity/Vade record branch, publish both records for the approved domain:

Replace DOMAIN.TLD with the actual approved sending domain. Do not copy these into the excluded pp-tp branch or assume the parent domain's records cover a child sending domain. Official DKIM CNAME values

Publish at the authoritative DNS service, not simply the company that registered the domain or hosts the website. For a delegated child zone, work with the actual child-zone authority. Confirm the final fully qualified owner after the DNS editor applies its suffix rules; a full name entered into a relative-name field can create a doubled domain.

A CNAME cannot coexist with other record types at the same owner. If an owner is already used by another service, stop and coordinate a supported resolution rather than deleting it. Preserve unrelated DKIM selectors and all other sender records. The target is a hostname, not a URL, and this workflow does not involve generating or transmitting a private signing key.

Where the DNS service offers proxying or CNAME flattening, ensure the exact authentication aliases are served as the required DNS records. Do not globally disable website-related settings or overwrite routing to repair two authentication owners. For Cloudflare, settings can vary by plan, zone-wide configuration and individual record; inspect the applicable control rather than assuming a single switch fixes every case. Cloudflare CNAME flattening settings

Verify both authoritative answers, the alias targets and the available target public keys. A DNS management page saying “saved” is not proof that the authoritative zone serves the intended data. Keep evidence of the two exact owner-target pairs without publishing tenant screenshots or unrelated infrastructure details.

Activate outbound signing separately

After publication, open Email Security > Spam & Malware Protection > Email Authentication and activate the outgoing DKIM-signature control. Hornetsecurity enables signing only for domains with valid DKIM settings and allows up to 72 hours for DNS caching effects. Confirm the actual account state; elapsed time is not proof of success. Outbound DKIM activation

Do not confuse this control with incoming DKIM validation, incoming DMARC validation or an SPF-check switch. Those govern receiving-side checks and are outside this change. The documentation's screenshot illustrates the distinct outbound toggle; it is not evidence that your account's domain is already valid or enabled.

If the domain cannot be enabled, inspect the exact DNS branch, authoritative records, suffix handling and cached results. Do not bypass the issue by weakening inbound checks or adding sender allowlists. If the records are correct but the account state remains unresolved, ask support to establish the missing domain/signing prerequisite before reporting completion.

Keep DMARC Manager and policy changes outside this setup

The vendor distinguishes ordinary public-DNS SPF from its separate DMARC Manager product. If records are already managed or delegated elsewhere, do not bypass that authority by adding conflicting public records. Establish the supported managed workflow with the owner instead. This guide does not purchase or activate that product. SPF versus DMARC Manager

Preserve the effective DMARC policy for the From domain, including inherited policy. Do not replace reject or quarantine with none, create a duplicate record or add a child policy solely to make a test pass. DMARC can pass through aligned SPF or aligned DKIM; both are useful to inspect, but neither a raw pass nor a green portal control is enough to establish alignment. DMARC specification

If no applicable policy exists, plan initial policy publication separately with the domain owner. Reporting destinations also need approval. Aggregate reports describe authentication activity; rua is not a destination for forwarding quarantined message bodies. For external report authorization, compare the Organizational Domain of the reporting URI destination host with the Organizational Domain of the domain where the DMARC policy was found, including an inherited policy. Different Organizational Domains require external report authorization; the same-Organizational-Domain exception uses that policy-found domain too. Aggregate reporting requirements

Verify a real message on the intended route

Send an explicitly authorized neutral test from the approved sender through the existing outbound path to a controlled mailbox. Do not send confidential content, contact real customers, change connectors or force a different route just to obtain a passing sample. Capture the route evidence and original received message privately.

Use authentication results produced by the receiving system you trust. Establish with its administrator which receiving gateway performs the checks and how externally supplied Authentication-Results headers are removed or segregated. A familiar authserv-id, a header's position or a line containing pass does not by itself establish trusted provenance. Authentication-Results security considerations

Require all of the following for the tested DKIM setup:

1. The actual From domain remains the approved branded identity, not an unexpected rewritten sender.
2. The message traversed the intended outbound gateway rather than bypassing it.
3. The intended Hornetsecurity signature passes DKIM, using its actual d= and selector.
4. That intended signature itself aligns with the approved From under the effective adkim mode.
5. The trusted receiver reports a DMARC pass for the actual From domain.
6. The actual SMTP MAIL FROM identity and SPF result are recorded and independently checked for errors.

For relaxed DKIM alignment, the signing domain and From domain share an Organizational Domain; strict alignment requires an exact match. SPF alignment compares MAIL FROM with From under the separate aspf mode. A child envelope domain does not automatically meet strict alignment with the parent From. DMARC alignment

An SPF-only DMARC pass cannot validate this DKIM configuration. Neither can a passing upstream Microsoft signature if the intended gateway signature is absent, failing or unaligned. Conversely, DKIM carrying DMARC does not erase SPF fail, temperror or permerror; diagnose them separately. See raw DKIM results versus aligned DKIM policy results.

A passing sample proves only the tested domain and route. Repeat controlled checks for materially different used paths before extending the claim. Successful authentication also does not guarantee inbox placement or prove a message is harmless.

Troubleshooting without broadening access

No intended DKIM signature: Check the actual outbound route, selected domain, record branch and outgoing signing control. Incoming validation cannot add an outgoing signature. Do not disable an upstream signer as a diagnostic shortcut.

DKIM fails: Compare the observed selector/domain with the published key path. Investigate stale DNS, wrong targets, conflicting records and downstream message modification. Preserve the original message privately; do not rotate keys blindly.

SPF fails or errors: Check the evaluated envelope owner, duplicate policies, syntax and lookup budget. Temporary DNS errors are different from authorization failures. An inbound MX record is not proof that outbound SPF should include the gateway.

DMARC fails despite raw passes: Verify the actual From, intended signing domain and alignment mode. Do not change the From or relax policy just to manufacture a passing result.

The account displays Proofpoint records: Stop using this branch. Obtain the correct product-specific record and activation workflow; do not publish both vendors' pairs speculatively.

A change must be reversed: Pause rollout and coordinate restoration of only the approved changed records/settings from the recorded prior state. Keep active selectors needed by queued messages and other services. Do not move MX, reset filtering or delete other authentication records. Retest after the approved correction.

For support, provide a sanitized timestamp, product/route description, exact relevant DNS owners and trusted authentication error. Do not include mailbox passwords, session tokens, private keys or confidential message content.