Use the current Service Desk route
This catalogue entry uses the name Samanage. The implementation procedure here is scoped to the current SolarWinds Service Desk email settings, whose documented infrastructure still uses samanage.com names. Do not combine it with old Samanage screenshots or assume that a migration-era checklist describes the present account. Record the service, datacenter, account type, and responsible administrator before making a change.
The current first-party navigation differs by account organization. ITSM uses Setup > Account > Email settings. ESM has organization or service-provider context around those settings. Record which context you are viewing so a domain configured for one service provider is not assumed to cover every service provider. SolarWinds Service Desk email settings
Identify the messages whose reliability matters: agent replies, task-related messages, automatic incident notifications, and any distinct customer-facing route. Also record incoming ticket addresses and forwarding rules. Outbound authentication and inbound incident creation are different flows; changing one must not silently break the other.
Understand the authentication-dependent controls
The current guide documents domain authentication as a prerequisite for personalized email addresses and a custom reply email address. It distinguishes personalized names from personalized addresses. Automatic notifications are not affected in the same way as messages originating from user actions. Consequently, test the actual message categories rather than assuming that an agent's personalized display name describes every sender. SolarWinds Service Desk email settings
Build a list of agent-address domains and the fixed identities used by automated notifications. A help desk may contain agents from subsidiaries or contractors whose email domains have different owners. Do not authorize a domain just because one agent has that address. Confirm that the organization has permission to send as the identity and can complete the provider's verification process.
Treat the reply destination as a functional dependency. A support address may forward incoming mail to the Service Desk dropbox. A verified outgoing sender does not prove that the forwarding rule works or that replies are attached to the intended incident. Include a harmless reply test with a designated incident and ensure it does not notify real affected users.
Publish the generated three-record configuration
The current documented workflow is Email Settings > Email Authentication > Add custom domain. Add the approved domain, expand its DNS settings, and copy the three generated CNAME records. Publish them in authoritative DNS, return to the account, and use Verify. The expected successful state is Verified. SolarWinds Service Desk email settings
Use the live generated owners and targets, not fabricated selectors or a record set from another customer. For each entry, preserve the exact public value, associated domain, TTL, and change reference. Ask the DNS administrator to inspect pre-existing data at the same owner before making the change. A conflict is a reason to investigate the configuration, not permission to delete an unrelated key.
Check how the DNS console handles relative and complete names. A successful save can still create the wrong owner or target. Query the intended public names and follow their CNAME resolution as necessary. Record what is actually published and the time of observation. Provider verification and independent DNS evidence should describe the same record set.
If verification fails, compare those results with the current account's generated values. Confirm that the edited DNS service is authoritative and that caches have had an appropriate opportunity to expire. Do not repeatedly add the domain or overwrite records without understanding the existing state. Preserve the exact error and involve the service owner if the provider cannot recognize records that are correctly published.
Handle SPF and local receiving controls separately
SolarWinds documents include:_spf.samanage.com in its SPF example. Review its use against the actual envelope route and the organization's existing authorization. Do not replace the organization's whole policy or create multiple applicable SPF records. Account for nested DNS evaluation and preserve legitimate senders already using that owner. SolarWinds Service Desk email settings SPF RFC 7208
The provider also lists datacenter-specific receiving allowlists. Those controls concern acceptance by your own mail systems; they do not create a passing aligned signature for external recipients. Keep any proposed allowlist change with the security team and verify current regional values before use. Do not apply every region's addresses or broad URL exceptions as an automatic authentication repair.
In particular, a local security product can deliver a message because of an exception even when its authentication is wrong. Preserve the underlying authentication results, not just inbox placement. Changes to Safe Links, spam filtering, or attachment access can have wider security effects and require their own review. This guide does not prescribe bypassing those controls to make the test appear successful.
Do not reuse the 2025 migration schedule
SolarWinds' migration notice describes a transition whose second phase was dated March 16, 2025. It explains why unauthenticated accounts could lose custom reply behavior or retain personalized names without personalized addresses. Use that notice as historical diagnostic context, not as a current deadline or evidence that a particular tenant completed migration. SolarWinds email-service migration notice
If a longstanding account's reply address changed unexpectedly, compare the present settings with a recorded earlier configuration. Authentication status may be relevant, but do not assume it is the only cause. Ask the owner whether the account was restructured, a service provider was added, or an agent identity changed. Document the actual current route before restoring anything.
Old DNS records should be removed only after establishing that no active account, selector, or message route depends on them. The age of a migration notice is not enough to identify a safe deletion. Keep cleanup separate from the immediate task of obtaining a verified, working sender.
Verify agent messages and automatic notifications
Create an authorized test incident and exercise the in-scope user-action and automatic-notification paths. Capture the original message at a trusted receiver. Record the visible From address and display name separately, the Reply-To, envelope identity, all DKIM signing domains and selectors, and trusted authentication results. Include the service-provider context and event that generated the message.
Read DKIM d= and s= from the received message, and compare them with the published configuration. A selector's existence proves only that a record is available; the message must actually use a valid signature. Preserve all relevant signatures if the receiver sees more than one. DKIM RFC 6376
DMARC requires a passing aligned authentication path for the visible From domain. Reply-To and display names are not substitutes for that identity. An SPF pass for a provider envelope domain can coexist with a lack of SPF alignment, while aligned DKIM may still satisfy DMARC. Evaluate the actual message under the effective policy. DMARC RFC 9989
If one class passes and another fails, compare the sender identities before changing shared DNS. A user-action message can use an agent address while an automatic notification follows a different identity. If mail was not sent at all, examine the notification event and available delivery evidence first. Authentication records cannot fix an absent trigger or an intentionally suppressed destination.
Fictional example of a misleading display name
Fictional written case only: SW-01 assumes a user-action message displays Alex Support, but its actual From remains a provider service address. Reply-To is help@example.org; the exact provider address, DKIM and SPF results are unknown. The administrator should distinguish personalized names from authenticated personalized addresses, then test the agent action, automatic notification and reply-to-incident route separately. Do not change receiving allowlists to substitute for this evidence. No service account, incident or message was inspected.
Implementation worksheet and release limits
- Account context: Service Desk product, datacenter, ITSM or ESM, organization or service provider, and owner.
- Identity inventory: agent domains, automatic-notification From values, display-name settings, and reply addresses.
- DNS: all three generated CNAMEs, existing data, exact published names, TTLs, lookup time, and Verified status.
- Policy: SPF owner and authorized mechanisms, effective DMARC policy, and separately approved local receiving exceptions.
- Tests: incident reference, triggering action, receiver, From, Reply-To, envelope identity, DKIM d=/s= values, and alignment result.
- Recovery: prior supported settings, forwarding dependencies, notification pause owner, and cleanup review.
Live account configuration, migration state, DNS, received headers, and screenshots have not been checked. Visual review, human SME approval, and publication remain pending. This unpublished candidate covers the current documented Service Desk route; legacy configurations and untested service-provider contexts remain on hold.
Separate a passing message from enforcement readiness
RFC 9989 Section 7.4 requires valid DKIM for a domain publishing p=reject and cautions about indirect-mail interoperability. A single aligned SPF result does not by itself justify a reject-policy rollout. Review all legitimate routes and policy ownership separately from this provider setup.