Source review dated 8 November 2026. This is documentary guidance; account, DNS and received-message acceptance tests below have not been executed.
Identify the deployment and the outbound path
NoSpamProxy Cloud and NoSpamProxy Server have different authentication procedures. Cloud exposes domain-specific DNS configuration and provider-managed DKIM CNAMEs. Server generates or imports keys, activates them for corporate domains and applies signing through rules. Do not combine these into one universal set of records. This article's Server instructions are grounded in the version 16 documentation; older installations require their matching guide. NoSpamProxy Cloud: Setting up the DNS configuration NoSpamProxy Server 16: DKIM keys NoSpamProxy Server 16: Apply DKIM signature
Record whether the deployment includes Protection, Encryption, a standalone Encryption TCP-proxy route, or another configuration. Trace the real outbound path from mailbox or application through the gateway to the external recipient. An inbound-protection deployment does not by itself prove that every outbound application uses NoSpamProxy. Include any bypass connector or alternate relay in the inventory.
Authentication must be verified after the final content-changing stage. A footer, attachment transformation or other gateway action can make a message differ from its pre-gateway form. The practical acceptance question is whether the recipient can validate an aligned signature on the delivered message, not whether the gateway has a key configured.
Configure Cloud using the domain-specific DNS view
The Cloud guide uses Identities > Corporate domains, the selected domain and Show DNS configuration. It supplies a verification TXT value, an SPF expression and four permanent DKIM CNAME entries. For a new deployment, its sequence establishes the DKIM records before the MX change. The verification TXT may be removed after successful verification, whereas the DKIM entries are intended to remain. NoSpamProxy Cloud: Setting up the DNS configuration
Copy each issued owner, record type and value into the worksheet. Check the domain and tenant before publishing. An MX migration changes inbound delivery and is a separate approved operation; do not repeat it merely because an already-deployed domain needs an authentication correction. Preserve existing TXT verification records and other senders' selectors unless they are explicitly part of the change.
The same Cloud guide excludes ordinary MX, DKIM and SPF onboarding changes for standalone Encryption without Protection, while specifying include:_spf.proxy.cloud.nospamproxy.com for the standalone Encryption TCP-proxy case. That exception is route-specific. It is not an SPF prescription for every Cloud or Server installation. Confirm the licensed and configured path before applying it. NoSpamProxy Cloud: Setting up the DNS configuration
For the ordinary Cloud route, use the SPF expression shown for that domain rather than guessing a generic include. Merge it into the correct existing policy and evaluate the full dependency path. An SPF record at the visible From domain helps only when that is the relevant evaluated envelope domain; record the real Return-Path identity during testing. SPF RFC 7208
Complete all Server signing prerequisites
For Server 16, the key workflow is Identities > Email authentication > DKIM keys, then Add. The administrator supplies a domain and selector, publishes the two entries generated by the wizard and checks verification. The guide describes 2048-bit RSA generation by default. Creating the key is not enough: it must also be activated for the corporate domain. NoSpamProxy Server 16: DKIM keys
Select the appropriate key in that corporate domain's DKIM configuration. When the key domain differs, the activation guide can require an additional generated DNS entry. It also calls out internal DNS resolution: if the Intranet Role's resolver cannot resolve the public entries, those entries must be available there as documented. A successful public lookup does not prove the gateway's configured resolver sees the same data. NoSpamProxy Server 16: Activating DKIM
Finally, ensure the applicable outbound rule includes Apply DKIM signature. The action is documented for Local senders. A valid key and corporate-domain selection will not compensate for a message taking a rule path that never applies signing. Record the rule matched by the test and its relevant actions, rather than assuming a default rule covers every source. NoSpamProxy Server 16: Apply DKIM signature
Keep private key exports and backups out of DNS worksheets and public tickets. Store them only in an approved secret-management location. Preserve an old public selector while messages legitimately signed with it may still arrive and while the planned rotation requires it. Do not overwrite another active service's selector to make a wizard validation turn green.
Test special content and rules separately
The Cloud rules documentation describes restrictions for client-encrypted and already digitally signed messages: its default outbound rule rejects client-encrypted messages and states that already digitally signed messages cannot receive an additional DKIM signature. Confirm exactly how the configured route handles those message classes. A harmless plain-text success does not certify protected-content workflows. NoSpamProxy Cloud: Rules
For Server, test the rules that actually process the relevant mail classes. Include only necessary harmless samples, such as a basic message and a permitted attachment workflow; do not use confidential content or modify production signing/encryption settings just to manufacture a test. If a message cannot receive the desired signature, determine whether another supported aligned path survives and document the residual limitation.
DMARC requires a passing aligned SPF or DKIM identity. An unaligned gateway-domain SPF pass is not enough by itself. Conversely, a passing aligned signature can satisfy DMARC even when another signature fails. Save all signature identities and the trusted receiver verdict rather than reducing a multi-signature message to one undifferentiated DKIM label. DKIM RFC 6376 DMARC RFC 9989
Reusable deployment and signing worksheet
Complete this worksheet for each distinct outbound route. Leave irrelevant branch fields marked not applicable, with a reason.
- Deployment: Cloud / Server. Server version or Cloud tenant: ______.
- Licensed/configured modules and TCP-proxy use: ______.
- Outbound source, connector, gateway and final recipient path: ______.
- Visible From domain, intended envelope domain and signing domain: ______.
- Cloud verification status and TXT owner/value: ______.
- Cloud four issued DKIM owners/targets and current authoritative answers: ______.
- Cloud SPF expression or confirmed standalone TCP-proxy exception: ______.
- Server selector/key domain and generated DNS entries: ______.
- Server corporate-domain activation and any additional alias: ______.
- Server internal resolver answer versus public authoritative answer: ______ / ______.
- Matched outbound rule, Local sender classification and Apply DKIM action: ______.
- Content class: ordinary / attachment transformation / digitally signed / encrypted / other ______.
- Received Return-Path; every DKIM d/s; trusted SPF/DKIM/DMARC results: ______.
- Passing aligned identity and any unsupported message class: ______.
- Decision: release this route / fix DNS / fix activation / fix rule match / resolve content limitation / hold.
- Previous DNS and rule configuration, recovery owner, trigger and reviewer: ______.
Fictional worked diagnosis
This is an invented Server 16 scenario, not observed customer evidence. An administrator generates a key for example.org, publishes the wizard's entries and activates the key for the corporate domain. A public lookup resolves correctly, but the received test message has no DKIM-Signature. The team initially suspects DNS caching.
The worksheet shows that the message matched a special outbound rule without Apply DKIM signature. The proposed correction is to review that rule's purpose and, if authorized and appropriate for the message class, add the signing action at the supported stage. A new test must confirm the rule match and a passing aligned signature at the recipient. Republishing the same DNS key would not fix the missing action. If only the gateway's internal resolver failed, that would be a different branch requiring resolver evidence rather than a rule change.
Accept the complete path and keep a recovery plan
Save authoritative DNS responses and the gateway's validation results separately. Send through each selected connector and rule path, retain the raw received message, and compare its authentication identities with the intended domain. Test reply and bounce behavior where the change could affect them. A successful inbound reputation check is not proof that the outbound signing path works.
Recover using the saved records and rule configuration under a named operator. Coordinate key activation with DNS restoration; restoring an old key record while the gateway uses a new private key can make signatures fail. For Cloud, retain permanent delegations needed for key management. For Server, preserve approved key backups without exposing secret material.
No live Cloud or Server account walkthrough, visual verification, authoritative before/after test, rule trace or independent received-message test was performed. Human SME approval remains open. Module exceptions, content limitations and Server-version boundaries must be confirmed against the actual deployment before release.