NoSpamProxy Cloud and NoSpamProxy Server use different authentication workflows. Cloud supplies a domain-specific SPF expression and four permanent DKIM CNAMEs. Server 16 requires generated or imported keys, corporate-domain activation and an Apply DKIM signature action on the relevant outbound rule. Choose the deployment first, publish its actual DNS values, and verify a passing aligned signature on delivered mail. Cloud DNS configuration, Server DKIM keys, Server signing action.
The Server procedure below is for the version 16 documentation, not a universal instruction for every historical release. No customer account, rule, DNS record or message was tested or changed.
On this page
- Choose the product, module and sending route
- Configure NoSpamProxy Cloud
- Configure NoSpamProxy Server 16
- Build SPF for the actual outbound system
- Keep DMARC policy and alignment intact
- Verify DNS, signing and the final message
- Troubleshooting and recovery
- Frequently asked questions
Choose the product, module and sending route
Record the Cloud tenant or Server version, licensed modules, corporate domain, source mail system, gateway and final outbound relay. Explicitly identify Protection, standalone Encryption without Protection and any TCP-proxy use. Those distinctions change DNS requirements; the words “NoSpamProxy” alone are not enough to choose an SPF include.
Also identify applications and alternate connectors that bypass the gateway. An inbound reputation filter that checks other people's SPF, DKIM and DMARC does not configure your own outbound signer. For Microsoft 365 connectors and application routes, use our Microsoft 365 route-mapping guide alongside this authentication guide.
Before proceeding, have:
- Authorized administrative access to the correct tenant or Server configuration.
- DNS access to the actual authoritative zone and a record export for recovery.
- An inventory of existing SPF authorizations, active DKIM selectors and applicable DMARC policies.
- The intended visible From, envelope sender and signing domains for each route.
- A responsible operator for routing, signing and key recovery.
- A harmless test plan covering ordinary mail and any relevant signed, encrypted or transformed content.
The target is the message after all gateway processing. A key that validates in a dashboard is not evidence that a final recipient can validate a signature after a disclaimer or attachment change.
Configure NoSpamProxy Cloud
Obtain the selected domain's records
Open Identities > Corporate domains, choose the domain and select Show DNS configuration. The Cloud guide supplies an ownership-verification TXT value, an SPF expression and four DKIM CNAME entries. Copy the complete record owners, types and targets from that domain's current view. Do not derive a tenant value from the corporate name. Cloud DNS setup.
Publish the verification TXT separately from SPF. Merge the issued SPF expression into the appropriate existing SPF policy as explained below. Publish all four CNAMEs permanently. The guide permits removing the ownership TXT after successful verification, but that permission does not extend to removing the DKIM CNAMEs.
For a new full Cloud deployment, the documented sequence establishes the CNAMEs and accounts for their previous TTL before the MX migration. An MX change affects inbound delivery. Do not repeat it just to repair authentication on a domain already deployed, and do not replace a mailbox provider's MX records outside an approved routing migration. Cloud record sequence.
For an actual initial inbound migration only, the routing owner must separately approve the full MX owner, every numeric priority and every target. Reconcile the complete issued set with that approved plan, compare the complete approved set at authoritative and recursive DNS before activation, and stop on a mismatch. A DNS packet alone is not permission to reroute incoming mail; preserve unrelated mailbox routes.
Respect the standalone Encryption exceptions
The same official guide says ordinary MX, DKIM and SPF onboarding entries are unnecessary for standalone Encryption without Protection. It separately specifies include:_spf.proxy.cloud.nospamproxy.com when that standalone module uses the Cloud TCP proxy. Treat this as an explicit branch, not a default include for all customers. In that branch, identify the actual supported signing system rather than inventing Cloud DKIM setup requirements. Module-specific Cloud requirements.
Check the Cloud rule and message class
Cloud applies managed rules according to their scope and otherwise uses its standard rules. Its documented default outbound rule rejects client-encrypted messages and says already digitally signed messages cannot receive an additional DKIM signature. Test those production classes separately; a plain-text result is not evidence for encrypted mail. Do not switch off content protection to obtain a convenient test result. Cloud rules and outbound restrictions.
Cloud DNS setup does not use the Server key-generation wizard or Server's local signing-action workflow. Confirm domain validation and the applicable Cloud rule, then use recipient evidence to establish that the intended signature is actually being added.
Configure NoSpamProxy Server 16
1. Generate the key and publish its issued records
In Identities > Email authentication > DKIM keys, select Add, specify the key's domain and an unused selector, and proceed through the wizard. Publish the two entries it displays, using each supplied record type and value, then finish and confirm key verification. NoSpamProxy documents 2048-bit RSA generation by default. Server activation and key-size guidance. Do not copy an article's sample key or reduce the size simply because a DNS editor wraps a long value. Server 16 key management.
A selector identifies a key; it is not a password. Check that its complete DNS owner does not collide with another active sender. Only public records belong in DNS. Private-key exports and backups must remain in an approved restricted location, not a shared change worksheet or support-ticket attachment.
2. Activate the verified key for the corporate domain
Open the intended corporate domain's DomainKeys Identified Mail configuration, activate DKIM and select the verified key. The key-management guide identifies Corporate domains as the activation location. If the installed navigation differs, use the matching version's help rather than applying the setting to an unrelated user object.
When the selected key's domain differs from the corporate domain, NoSpamProxy can display an additional necessary DNS entry. Publish that issued entry and restart the key-selection step after DNS is available. Do not assume a key generated for one domain automatically covers another. The activation guide also calls for at least 24 hours after DNS changes before checking and applying them; waiting does not replace verification of the authoritative answers. Server DKIM activation.
If the Intranet Role uses an internal resolver that cannot resolve the Internet entries, the official procedure requires those entries on that internal DNS server too. Public DNS success alone cannot prove that the gateway sees the necessary data. Keep internal and external answers consistent; do not create an unrelated replacement public zone.
3. Apply signing on the correct outbound rule
Ensure the rule that processes the route includes Apply DKIM signature. The action is documented for Local senders. Record the actual matched rule and sender classification for the test message. Key creation and corporate-domain activation do not substitute for a signing action on that message's rule path. Server signing action.
Review the supported action order and any later transformations. Test through the entire production route, including downstream relays. This guide does not prescribe moving an action arbitrarily between rules or suppressing encryption to make DKIM pass.
Build SPF for the actual outbound system
Choose authorization according to the route:
| Deployment branch | SPF input to review |
|---|---|
| Ordinary NoSpamProxy Cloud | Expression issued in that corporate domain's DNS configuration |
| Standalone Cloud Encryption using its TCP proxy | Documented include:_spf.proxy.cloud.nospamproxy.com exception |
| NoSpamProxy Server using its documented TCP proxy | include:_spf.proxy.nospamproxy.com, which is a different hostname |
| Server delivering directly or through another relay | Actual public outbound IPs or the final relay's current documented authorization, not an assumed Cloud include |
The Server TCP-proxy guide requires a valid software maintenance contract for that feature. It also explains that the proxy becomes the sending system and therefore must be authorized. A Server installation hosted in a cloud virtual machine remains Server; its hosting location does not turn it into NoSpamProxy Cloud. Server TCP proxy and SPF.
SPF normally checks the SMTP MAIL FROM domain, visible as the delivered Return-Path in common cases. Edit the policy at that evaluated domain, not automatically the visible From domain. A null envelope uses the HELO identity for SPF and should be tested separately where relevant. SPF identities.
Keep one SPF policy per owner. Merge authorized sources into that policy, preserve the existing termination and legitimate senders, and review any redirect= delegation. Do not add a second v=spf1 TXT record. There is a maximum of ten evaluated DNS-dependent terms, including nested include and redirect paths and applicable a, mx, ptr and exists terms. Counting only top-level includes misses dependencies. Do not convert provider includes into an unmanaged static IP list. SPF DNS limits.
If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.
Keep DMARC policy and alignment intact
DMARC passes if at least one of SPF or DKIM both passes and aligns with the visible From domain. Relaxed alignment compares Organizational Domains; strict alignment requires an exact domain match. Check the applicable policy's aspf and adkim. A passing gateway signature for an unrelated domain does not authenticate your visible From for DMARC. RFC 9989, current DMARC specification.
Preserve existing enforcement, reporting and unrelated senders. Query _dmarc under the exact From domain and examine applicable parent-policy inheritance before adding a subdomain-specific record. Do not replace an existing p=reject with p=none as a gateway repair.
For From addresses at example.com, the full DMARC owner is _dmarc.example.com. For From addresses at mail.example.com, an explicit child policy is _dmarc.mail.example.com. The relative name is _dmarc.mail in the parent example.com zone, or _dmarc in a delegated mail.example.com zone. Check the saved full name; DMARC does not belong at @.
Only when there is no established applicable policy and a monitored rollout is appropriate should a new p=none policy be considered. Use one DMARC record at the selected owner and an approved monitored rua destination. For external reporting, obtain the destination provider's required authorization rather than guessing a reporting record. Aggregate reports expose infrastructure information; failure reports can disclose message data, so add ruf only after a privacy review. RFC 9989 removes pct, so do not rely on a new percentage-based policy rollout. DMARC policy, report authorization, failure reporting.
Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4. Only when no direct or applicable inherited policy exists and the domain owner approves initial monitoring, an illustrative first record is TXT with value v=DMARC1; p=none. This requests no reports by itself; add rua only for a provisioned, approved destination after checking the reporting rule below. For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names.
Verify DNS, signing and the final message
Resolve the exact issued owners
Use the authoritative DNS host, not an old DNS account. For a supplied owner like SELECTOR._domainkey.example.com, enter a relative SELECTOR._domainkey only where the editor appends the domain. Preserve the actual record type. A long TXT public key may appear as adjacent quoted chunks within one logical TXT record; do not create several competing records or alter the key bytes. DKIM key records.
For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.
A CNAME cannot coexist with ordinary TXT, A or MX records at its exact owner. Resolve collisions deliberately instead of deleting unrelated authentication. If the DNS host provides proxying or flattening, keep authentication aliases DNS-only and disable any record-level or zone-wide flattening that would hide these non-apex CNAMEs. Leave unrelated website and apex-only settings alone. Cloudflare proxy behavior, flattening controls.
Coordinate shared zone-level flattening changes with the DNS owner and other affected services. Preserve legitimate _domainkey or child-zone NS delegation and publish through its authoritative service. Do not remove delegation to make a parent-zone edit or a verifier succeed; confirm the actual public resolution path instead.
Keep the required literal CNAME answer: turn relevant per-record Flatten off where available and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, apex CNAMEs are flattened by default and same-zone targets are flattened regardless of that setting; flatten-all cannot be overridden per record. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration without breaking other services or removing NS delegation. These are DNS-host behaviors, not controls assumed in the sending provider. Cloudflare flattening controls and limits.
Replace the uppercase placeholders before running these read-only commands:
dig +short NS DNS-ZONE
dig @AUTHORITATIVE-NS +short TXT ENVELOPE-DOMAIN
dig @AUTHORITATIVE-NS +short CNAME ISSUED-CNAME-OWNER
dig +short TXT ISSUED-DKIM-OWNER
dig +short TXT _dmarc.FROM-DOMAIN
For Cloud, repeat alias checks for all four issued owners and follow each alias to its public-key response. For Server, check both wizard-issued records plus any additional corporate-domain entry. Use the supplied type; the CNAME query is only for an issued CNAME. Also compare the Intranet Role's configured resolver:
dig @INTERNAL-RESOLVER +short TXT ISSUED-DKIM-OWNER
Expect the complete matching public data, not merely a nonempty response. Compare with an independent recursive resolver. TTL and negative caching can explain stale recursive answers after an authoritative correction; a wrong authoritative value needs fixing, not more waiting.
Require route-specific acceptance
Send an authorized harmless sample through each actual source and gateway path to an external mailbox you control. Include relevant attachment transformations, signed mail or encrypted workflows as separate cases. Save the timestamp, route/rule evidence and minimized raw received headers.
| Check | Required evidence |
|---|---|
| Product and route | Correct Cloud tenant/module or Server version; actual outbound path and any TCP proxy identified |
| Provider state | Cloud domain validation, or Server verified key plus domain activation plus matched signing rule |
| Custom DKIM | Expected branded d= and issued s= with receiver dkim=pass and alignment to From |
| SPF | Actual envelope domain and connecting IP; spf=pass expected for a correctly authorized direct route, with alignment evaluated separately |
| DMARC | Trusted receiver reports dmarc=pass for the intended From domain |
| Content exceptions | Every relevant supported class tested; unresolved signing limitations explicitly recorded rather than covered by a plain-text result |
Use recipient-controlled diagnostics or authentication headers with provenance established by the receiving administrator's trust boundary, including its handling of externally supplied authentication headers. A familiar authserv-id or header position alone does not establish trust. If provenance is uncertain, obtain the receiving service's diagnostic result rather than accepting an arbitrary Authentication-Results line. Inspect all signatures separately. Authentication-Results security guidance.
For a route whose goal is custom-domain DKIM, aligned SPF alone is not completion. Require branded DKIM pass and alignment plus DMARC pass. A forwarding route may fail SPF while aligned DKIM passes DMARC; investigate a genuine direct-route SPF error separately. For standalone Encryption branches that do not use the ordinary Cloud DKIM workflow, record which other supported signer or aligned SPF path provides DMARC, without claiming Cloud DKIM was configured. Authentication does not guarantee inbox placement.
Troubleshooting and recovery
| Observed problem | Most useful next check |
|---|---|
| Cloud has fewer than four required aliases | Reopen that domain's DNS view; compare all issued owners and permanent targets |
| Server key verifies but mail has no signature | Corporate-domain activation, Local sender classification and the exact matched Apply DKIM signature rule |
| Public DNS works but Server verification fails | Intranet Role resolver, split DNS and additional entry needed for a different key domain |
| DKIM key is found but signature fails | Wrong active key, stale selector answer or message alteration after signing |
| Protected-content mail behaves differently | Cloud rule restriction or Server rule/content path; do not extrapolate from ordinary mail |
SPF fail or softfail |
Actual envelope domain, final public sending IP, Cloud versus Server TCP-proxy value and alternate route |
SPF permerror |
Duplicate policies, syntax, loops and the full ten-term dependency budget |
SPF temperror |
DNS timeout or transient resolution failure, not necessarily missing authorization |
| Passing authentication but DMARC fails | Unaligned domains or strict-mode mismatch; inspect actual From and all passing identities |
Retain the previous DNS and rule configuration before deployment. If a change breaks the intended path, stop that rollout and restore a coordinated known-good signer, records and routing through the responsible operator. Restoring an old public key while the gateway still uses a new private key will not repair signatures.
For key rotation, use an approved overlap plan that accounts for caches and queued mail. Keep old public selectors while legitimate messages may need them. Preserve Cloud's permanent management CNAMEs, and store Server key backups securely. Do not disable inbound protection or weaken domain-wide DMARC to hide a signing fault.