Confirm the product and account context
SolarWinds Service Desk's Email settings guide covers outgoing and incoming email configuration for the cloud Service Desk product. It is not a guide to the separate Web Help Desk product or to a generic SolarWinds SMTP server. Confirm the account, datacenter and whether the organization uses the ITSM or ESM navigation context before planning changes.
The documentation gives Setup > Account > Email settings for ITSM and an organization or service-provider context for ESM. Record which administrative scope owns the intended sender domain. A shared company name does not establish that a domain belongs to every service provider or organization configured in the platform.
This manuscript describes the documented workflow and proposed verification. It does not claim access to a live account, a current tenant entitlement, an actual DNS change or a successful notification. The original implementation and production-release requirements remain open. Service Desk Email settings
Generate and publish the custom-domain records
Under Email Authentication, the guide directs the administrator to add a custom domain. The new entry initially appears as Not verified. Expanding its DNS Settings reveals three CNAME records. Publish those account-generated records, return to Email Settings and select Verify for the domain. The documented successful state is Verified.
Retain the exact names and targets from the selected account. Do not substitute records from another environment or an older migration announcement. Review the authoritative zone and existing data at each owner name before approving the change. The DNS editor may append the zone automatically, so compare the intended final names with the interface conventions rather than blindly pasting a suffix.
The provider discusses a possible publication and verification delay. Treat that as timing guidance, not evidence that an incorrect record will eventually pass. Record the time and actual outcome of the check, then investigate the specific unmatched name or target if it remains unresolved. Email setup Step 1
Keep datacenter controls separate from domain authentication
The guide includes datacenter-specific IP and domain allowances as a separate setup step. It lists different values for US, EU and AU accounts. Do not apply an old or unrelated datacenter's list as a universal recommendation, and do not treat allow-listing as a substitute for authenticating the sender identity.
Any proposed filtering exception needs a security review of its scope and intended traffic. This manuscript does not change a firewall, mail gateway or mailbox policy, and it does not recommend disabling authentication checks to force delivery. The useful evidence is the actual account location and the approved purpose of any exception, not a claim that every recipient should trust a vendor's traffic unconditionally.
Likewise, controls for who may create incidents or comments by email concern incoming workflow access. They do not establish the SPF or DKIM result of outgoing notifications. Keep inbound access decisions and outbound authentication in separate acceptance rows. Email setup Step 2; Blocked and allowed addresses
Review the documented SPF policy in context
For sending from the organization's domain, the guide instructs administrators to add the TXT record shown under DNS Settings and illustrates include:_spf.samanage.com. Use the actual account instructions and review the complete affected policy rather than replacing existing authorization with an isolated example.
SPF evaluates its specified SMTP identities, not an agent's friendly display name. Multiple selected SPF records cause an error, so a shared domain needs a coherent policy that preserves legitimate sources. Review the evaluation limit on DNS-dependent terms and any nested dependencies before approving a change.
The guide also discusses DMARC, but a published policy is not proof that every Service Desk message aligns. An authorized received-message sample is needed to compare the visible author domain with a passing authentication identity. Do not weaken an existing organization-wide policy just to simplify a service-desk rollout. Address other email standards; RFC 7208, section 2.4; RFC 7208, section 3.2; RFC 7208, section 4.6.4; RFC 9989, section 4.4
Distinguish personalized names, addresses and replies
The provider documents several separate settings. Personalized email names affect the name used for user-originated actions, while personalized email addresses affect the From address for such actions after authentication. The guide says automatic notifications not originating from user actions are unaffected by those settings. It also says those settings do not change Reply-To.
This distinction should shape the acceptance plan. A sample produced by an agent comment does not automatically prove the sender identity of a scheduled or automatic notification. A familiar name is not a domain identity, and a working reply destination does not establish DKIM alignment. Record each field and message category separately.
The Reply email address feature has its own purpose, including consistency when forwarding rules are used. Review the intended customer or employee reply path without confusing that workflow check with cryptographic validation. If the sender or reply path differs from expectations, inspect the selected setting and category before changing otherwise correct DNS. Personalized email names; Personalized email addresses; Reply email address
Acceptance worksheet for service-management operations
Use this original proposed worksheet to make account, notification and security boundaries explicit.
- Product scope: Service Desk account, datacenter, ITSM or ESM context and authorized administrator.
- Domain request: intended sender domain, exact generated CNAME names/targets and current DNS owner.
- Policy review: complete affected SPF policy and the organization's DMARC alignment expectations.
- Security exceptions: separately approved datacenter-specific allowances, if needed, with their purpose and owner.
- Message classes: at least the materially different user-action and automatic-notification paths identified for later acceptance.
- Visible identity: From address, friendly name and Reply-To recorded as different fields.
- Verification: provider status and timestamp, plus minimized authorized message evidence with trusted receiver results.
- Release: unresolved current-applicability questions, rollback owner and production approval.
The worksheet is blank planning guidance. No account, inbound list, DNS zone or security setting has been changed, and no incident or notification has been created to test it.
Fictional diagnosis: an automatic notification did not personalize
A fictional IT team verifies its domain and enables personalized addresses. An agent's comment uses the expected From identity, but an automatic notification does not look the same. The team initially assumes the DKIM configuration has failed because the visual sender differs.
The proposed investigation first identifies whether the message originated from a user action or an automatic process. The reviewer then compares the actual address fields and trusted authentication results instead of treating appearance as proof. Reply-To is reviewed independently because its behavior is controlled separately.
The resulting handover distinguishes the documented personalization scope from authentication acceptance and identifies any unverified routes. It does not delete the working CNAME records or broaden incoming allow-lists to repair a cosmetic misunderstanding. This scenario is fictional and contains no executed test or allegation about a real Service Desk deployment.