SpamExperts SPF, DKIM and DMARC setup, step by step

For Spam Experts Hosted Cloud outbound filtering, add the applicable Hosted Cloud authorization to the existing SPF policy. If the sending server does not already sign with DKIM, generate a domain-level key, publish its public TXT record, and assign that exact selector to the outgoing authentication method actually used by the sender. Generating a key without assigning the selector does not activate filter signing.

Already-signed messages are a different branch: preserve their existing DKIM configuration and verify the signature after Spam Experts transit. Do not strip an upstream signature to force the gateway to add another. DKIM signing is unavailable for a re-authenticating user, according to the product documentation.

This guide assumes an already-provisioned, authorized Hosted Cloud outgoing route. It does not onboard a relay, create credentials, configure Local Cloud, or cover N-able Mail Assure.

On this page: Identify the product and exact outgoing method · Choose the correct DKIM branch first · Generate the domain’s public DKIM record · Publish the key in authoritative DNS · Activate the selector on the actual outgoing method · Add Hosted Cloud SPF without replacing other senders · Verify the exact production path at the receiver · Troubleshoot the layer that failed · Frequently asked questions

Identify the product and exact outgoing method

Spam Experts and Mail Assure have similar-looking controls but different product instructions and SPF authorizations. Use the Spam Experts Hosted Cloud SPF documentation, not another product’s include value.

Confirm these details with the mail administrator before changing DNS or signing:

• The service is Spam Experts Hosted Cloud with outgoing filtering already in use, not inbound-only filtering or a privately managed Local Cloud cluster.
• The exact domain, intended visible From address and actual SMTP MAIL FROM domain are known.
• The sending server’s existing outgoing authentication method is identified, including any other domains sharing it.
• The administrator can access the intended domain’s Domain Level Control Panel and the relevant outgoing authentication entry.
• The DNS administrator controls the authoritative zone or can coordinate with the delegated namespace owner.
• The owner has approved the precise DNS and signing changes, not a general migration of mail routing.

The Outgoing Users/Authentication Methods page distinguishes an authenticating IP or range, authenticating domain, and authenticating user. Those are routing and authentication choices, not interchangeable labels. An IP binding may be shared by multiple senders; a domain authentication entry is not the same as an individual user’s entry. Do not create a broader IP range, change credentials or switch methods merely to match this tutorial.

Save the current public records, selectors, method settings and TTLs. Preserve other legitimate senders and existing direct or inherited DMARC policies and reporting destinations. Changes to MX, nameservers, DNSSEC, connectors or inbound filtering are outside this authentication task.

Choose the correct DKIM branch first

The official Set up DKIM guide says that domains already signing with DKIM should keep that configuration: Spam Experts forwards those signed messages. For an unsigned route, the administrator can choose signing on the upstream mail server or signing with Spam Experts.

If the upstream server already signs: preserve its key and signing configuration. Test that intended upstream signature through the real Hosted Cloud path. Do not assume that a missing additional gateway signature is a fault, and do not delete or disable an existing signature to create one. If the upstream signature is unaligned or broken, repair that supported route with its administrator rather than silently replacing it.

If the route is unsigned and gateway signing is approved: follow the generation, publication and selector-assignment steps below. Acceptance must specifically prove that newly configured gateway signature works.

If the route uses a re-authenticating user: stop this gateway-signing branch. The DKIM Certificate Generation documentation explicitly says signing is unavailable for that method. Ask the service administrator about a supported signing arrangement. Do not silently replace authentication methods, weaken credentials or claim a DNS-only fix.

Generate the domain’s public DKIM record

For the approved unsigned route:

1. Open the intended domain’s Domain Level Control Panel.
2. Select Outgoing → DKIM.
3. Choose 2048 bits, the documentation’s recommended key length when supported by the DNS service. If the editor cannot accept the value, coordinate supported TXT handling rather than automatically reducing key strength.
4. Choose a valid, nonconflicting selector for this domain. Record it exactly, including spelling. Do not reuse a selector whose DNS key is still needed by another sender.
5. Select Generate and save new private/public pair.
6. Copy the complete public value displayed by the product and the corresponding DNS owner. The example key in a guide is not your account’s key.

Only the public DKIM TXT value belongs in DNS. Preserve the full tagged value, including the generated p= data. Keep the private key in the service’s protected signing system; never put it in a URL, DNS record, ticket or third-party key generator. Local Cloud command-line procedures are not part of this Hosted Cloud workflow.

Generation is not signing activation. Keep the selected key, public record and outgoing method linked in your change notes so that the next steps apply to the same domain and selector.

Publish the key in authoritative DNS

The owner has this structure, with both placeholders replaced by the actual configured values:

SELECTOR._domainkey.SIGNING-DOMAIN

Publish a TXT record with the complete account-generated public value, not a copied tutorial value or only the first visible line of the key. Long TXT data may be represented as multiple quoted character strings within one record; the DNS editor must preserve their concatenated value. Do not split the key into multiple separate TXT records or truncate it to fit a field.

For example, if the actual issued owner were SELECTOR._domainkey.mail.example.com, an editor for the example.com zone might require the relative name SELECTOR._domainkey.mail. An editor for a separately delegated mail.example.com zone might require SELECTOR._domainkey. If _domainkey.mail.example.com is delegated separately, its administrator must publish the record. These are owner-mapping examples, not production selectors.

Confirm whether the DNS interface accepts full names, automatically appends the zone, or requires a trailing dot. Avoid a doubled domain suffix. Preserve existing NS delegations and other selectors. If the owner is already a CNAME, do not add conflicting TXT there or delete a shared alias blindly; arrange a nonconflicting supported selector with the service administrator.

Check the authoritative DNS answer and then a recursive resolver after relevant positive or negative cache expiry. Do not treat a fixed “24-hour” interval as a guarantee. Record publication and validation times. A resolving key proves the public DNS state at that point, not successful signing.

Activate the selector on the actual outgoing method

Return to Outgoing → Manage Outgoing Users/Authentication. Locate the entry actually used by the sending server, not merely an entry with a similar domain or display name. Edit its DKIM Selector to the exact selector used during key generation and persist the change using the interface’s save operation. Reopen the entry to confirm the stored value.

The official DKIM instructions explicitly warn that without this selector assignment the filter does not sign. They also say the assignment can affect domains sending through that outgoing authentication, assuming those messages do not already have their own DKIM signature. Consequently, assignment is not merely copying harmless text: review the affected sender/domain scope and obtain approval before changing a shared method.

Do not apply the selector to all users “to be safe.” A key and owner appropriate for one domain do not establish valid signing for every domain on a shared connection. If the relationship between domain, authentication binding and actual signer is unclear, stop and ask the provider to confirm the supported mapping. Do not infer a universal d= value from the login name.

For an existing upstream-signed route, do not perform this assignment just to force an additional signature. Preserve the supported upstream branch and validate its final result instead.

Add Hosted Cloud SPF without replacing other senders

The documented general Hosted Cloud mechanism is:

include:spf.antispamcloud.com

Use that exact spelling. It is an SPF mechanism, not a second complete record. SPF evaluates the actual SMTP MAIL FROM domain, or HELO in the applicable null-reverse-path case, rather than automatically evaluating the visible From domain. Identify the real evaluated owner before changing apex DNS. If a provider-owned envelope domain is evaluated, ask which customer-domain policy is applicable rather than assuming an apex edit creates alignment.

At the applicable authoritative owner, locate the single TXT policy beginning v=spf1. It may start with ip4, a, or another mechanism rather than include. Preserve legitimate existing senders and approved qualifiers. Add the applicable authorization where it will be evaluated, before a terminating all; appending it after all does not authorize anything.

An all mechanism anywhere in an SPF policy makes redirect= ineffective. A redirected policy therefore needs deliberate integration by the administrator, not mechanical concatenation. Validate the ten evaluated DNS-dependent term limit, including nested mechanisms and redirects, rather than counting only top-level includes. These behaviors are specified in RFC 7208.

The provider’s sole-route example is:

v=spf1 include:spf.antispamcloud.com -all

Use that complete policy only when the owner has confirmed it authorizes every legitimate sender at the evaluated owner and approves the final qualifier. Having no current SPF record does not prove there are no other senders. Do not replace a working multi-sender policy with this example, duplicate v=spf1 records, or copy sample IP addresses and generic a mechanisms into production. -all produces an SPF fail for unmatched senders, not a guarantee that every receiver will reject them.

When a regional include is appropriate

The Hosted Cloud documentation discourages regional restriction unless necessary. If the owner requires it, use only the region actually selected for that domain’s service, confirmed with the administrator:

Do not infer the service region from office location or select several regions as a precaution. Do not retain the unrestricted include and expect an additional regional include to narrow it. A region change requires provider coordination; changing SPF alone does not move the service. Local Cloud cluster IP policies and reseller-branded SPF wrappers are separate configurations, not substitutes for this Hosted Cloud recipe.

Verify the exact production path at the receiver

With the owner’s approval, send a non-sensitive message through the actual configured MTA and outgoing authentication method to a controlled, valid external recipient. Use the intended branded From. Do not bypass the filter, change production routing solely for a test, or send customer data to public testing inboxes.

Use authentication results generated inside the receiving service’s known processing boundary, following that service’s documented handling of externally supplied Authentication-Results. A familiar authserv-id, header position or pasted “pass” is not proof that a trusted receiver generated it. Ignore untrusted injected fields; ask the receiving administrator if the provenance is unclear. See RFC 8601.

Record the visible From domain, actual MAIL FROM domain, DKIM d= and s=, and trusted SPF, DKIM and DMARC results. Apply the correct branch:

• New gateway signing: the intended Spam Experts-generated signature must pass and align with the intended visible From. Verify that its selector matches the generated and assigned selector. Require trusted dmarc=pass; a pass achieved only through SPF does not prove the new DKIM configuration works.
• Existing upstream signing: the intended upstream signature must survive the real gateway transit, pass and align with the intended From, with trusted dmarc=pass. Do not mark a nonexistent new gateway signature as configured or required.

In both branches, the intended visible From must remain unchanged. A provider rewrite may authenticate a different identity, not the requested brand. Diagnose SPF separately even if aligned DKIM gives a DMARC pass.

Under relaxed alignment, the relevant DKIM d= or SPF MAIL FROM domain shares the visible From domain’s Organizational Domain. Under strict alignment, the respective domain must exactly match the visible From domain. A child envelope domain does not automatically satisfy strict SPF alignment. RFC 9989 defines the policy relationship. EmailAuth’s raw DKIM versus aligned DKIM results explains why a cryptographic pass alone is insufficient.

Troubleshoot the layer that failed

DNS key exists, but unsigned mail has no gateway signature. Confirm the exact outgoing entry’s persisted selector, selected domain and actual route. Check whether the entry is a re-authenticating user. Publishing a key does not overcome that documented limitation.

Mail has an upstream signature but no additional gateway signature. That can be the documented preservation behavior. Validate the intended upstream signature instead of stripping it or repeatedly generating keys.

DKIM fails. Compare the message’s selector and signing domain with authoritative DNS. Check full key integrity, wrong-zone publication, conflicts and stale caches. Investigate modifications to signed headers or body during transit. Do not overwrite an active selector until the cause is known.

SPF fails. Check the receiver’s connecting IP and actual evaluated MAIL FROM owner, reachable include, configured region and complete policy. An apex change cannot fix a different evaluated domain.

SPF returns temperror or permerror. Investigate temporary DNS availability for temperror; fix structural problems such as multiple policies or exceeded evaluation limits for permerror. Neither is an ordinary authorization fail. Resolve these independently even when DKIM currently allows DMARC to pass.

Authentication passes but DMARC fails. Compare the identities and active alignment modes. Preserve direct and inherited DMARC policy and authorized report destinations while fixing the sender; do not downgrade to monitoring, duplicate policy or add an unapproved reporting recipient. This guide does not create a new DMARC reporting arrangement.

Authentication works but delivery is poor. Investigate the actual rejection, reputation, recipient policy, content and filtering decisions. SPF/DKIM success does not guarantee acceptance or inbox placement. Do not add blanket allowlists or weaken inbound protection.