SolarWinds Service Desk SPF, DKIM and DMARC setup, step by step

To authenticate a custom sending domain in SolarWinds Service Desk, add it under Email Authentication, publish the three CNAME records generated for that domain, and return to select Verify. Review the current SPF authorization separately, then test both user-action and automatic notifications. A Verified label does not prove that every message has the intended branded DKIM signature or DMARC alignment. Current Service Desk email settings.

This guide is based on published documentation. No Service Desk account, DNS zone, incident, notification or delivered message was tested or changed.

Confirm the product, account and notification class

This is the cloud Service Desk workflow, not SolarWinds Web Help Desk, Mail Assure or a generic SMTP-server setup. Do not copy records from another SolarWinds product merely because the brand matches.

Identify the ITSM or ESM account context, datacenter, custom domain and administrator. ITSM navigation is Setup > Account > Email settings. ESM places that path under the Organization or Service Provider context. Service Desk navigation.

Build an acceptance inventory before editing DNS:

• A user-originated comment, reply or assignment notification.
• An automatic notification not triggered by a user action.
• Each materially different agent email domain or service-provider context.
• The internal support address, forwarding rule and intended reply destination.
• Any datacenter-specific receiving-security exception already in use.

Do not assume these routes share one visible identity. Authentication and ticket continuity must be assessed separately. A successful agent-reply test does not certify an automatic-notification path.

Obtain and verify the account-generated CNAMEs

In Email Authentication, select + Add custom domain, enter the organization's domain and add it. Expand its DNS Settings, copy all three generated CNAME owner/target pairs, publish them, then select Verify. The documented state changes from Not verified to Verified; publication and verification can take up to 48 hours. Custom-domain procedure.

Use the exact current account values. Do not replace them with invented selectors, another tenant's targets, old screenshots or a standalone DKIM key you generated elsewhere. Record each row's purpose where the interface labels it, and ask Support if a role or required owner is unclear.

The CNAMEs publish the provider's required DNS delegation, while the sending service controls the corresponding signing operation. A visible public key does not establish that a particular message used it. Capture the d= domain and s= selector from the eventual message to link DNS evidence to the actual signature. DKIM verification model.

Before publication, export the affected DNS records. Record the exact proposed diff, account context, DNS owner and rollback owner. Leave unrelated DKIM selectors, domain-verification tokens, MX records and mailbox-provider policies intact.

Translate names safely for apex, child and delegated zones

The following is a naming illustration only; none of these selectors is a SolarWinds value:

Example generated full owner: selector1._domainkey.support.example.com
In example.com zone: selector1._domainkey.support
In delegated support.example.com zone: selector1._domainkey

Example generated full owner: selector2._domainkey.example.com
In example.com zone: selector2._domainkey
Target: copy the exact generated target, not an example target

If the editor expects a fully qualified name, use it. If it appends the zone automatically, use the matching relative label. A doubled suffix publishes the record somewhere the intended verifier will never query.

Check for existing data at each generated owner. A CNAME cannot coexist there with another ordinary record such as TXT or MX. Do not delete a conflicting sender's record or create a second incompatible alias; ask the relevant owners and Support for a supported solution. A child delegation also matters: update the zone actually authoritative for that name.

Where a DNS provider offers HTTP proxying, keep email-authentication aliases as ordinary DNS records rather than web-proxied endpoints. Verify the public CNAME response against the generated target, not merely the DNS panel's saved state.

Configure SPF at the domain actually being evaluated

The current official guide gives this SPF example:

v=spf1 include:_spf.samanage.com ~all

It directs administrators sending from their domain to add the TXT record identified in DNS Settings. Confirm the exact owner and current account instructions before using the example. Do not substitute older regional IP-only recipes or copy recipient allow-list addresses into SPF. Service Desk SPF guidance.

The example is not a replacement for a domain's complete existing policy. At an owner already publishing SPF, merge the approved mechanism before the terminal all, retain all legitimate senders, preserve the terminal qualifier, and keep only one v=spf1 record. Do not create a second policy. Evaluate nested includes and redirects against SPF's ten DNS-querying-term limit. SPF publication and lookup limits.

Record the envelope MAIL FROM domain independently of the visible From. SPF tests that envelope domain on ordinary messages. If the actual envelope remains provider-owned, adding a customer-apex include does not turn it into customer-aligned SPF. Conversely, a customer child envelope is not covered automatically by its parent's SPF record. Treat custom Return-Path availability and exact behavior as account questions to resolve, not features to invent.

This distinction prevents a common false diagnosis: spf=pass can be valid but nonaligned with the visible From. That is different from SPF failure. Branded DKIM can supply DMARC alignment when the envelope is not aligned, but it does not excuse an actual SPF configuration error.

Separate branding, Reply-To and incoming-ticket controls

Service Desk distinguishes Personalized email names, Personalized email addresses and Reply email address. Address personalization and Reply email address require domain authentication. Personalization affects user-originated actions, not unrelated automatic notifications, and does not change Reply-To. Identity-setting behavior.

Review each observed field on its own:

• Display name: a reader-recognition choice, not an authenticated domain.
• From address: the identity DMARC evaluates.
• Reply-To: the destination for an ordinary reply.
• Envelope/Return-Path: the SPF and delivery-error identity.
• DKIM d=: the domain that cryptographically signs the message.

When an automatic message does not show the agent's address, first check the notification class. Do not delete working authentication records to correct a setting that does not apply to that class.

Incoming address/domain lists control incident and comment creation. They do not prove outgoing SPF or DKIM. Suppression can prevent delivery independently of otherwise correct authentication. Review the associated email-log reason before deciding whether a suppressed destination should be restored. These are separate workflow/security decisions, not automatic DNS fixes. Incoming controls and suppression.

Confirm that replies to the chosen support address follow the intended forwarding/dropbox route and arrive on the correct ticket. Use an authorized test ticket with harmless content; do not expose customer incidents to public diagnostic tools.

Keep datacenter allow-listing separate from sender authorization

SolarWinds publishes receiving allow-list guidance for US, EU and AU datacenters. Refer to the current table for the account's region instead of assuming old IPs remain applicable. Current datacenter table.

A receiving allow-list exception only changes what a particular receiving environment permits. It does not publish SPF, activate DKIM or demonstrate DMARC alignment. Keep the purpose, affected system and security owner of any exception in the change record.

Likewise, a Safe Links exception is a link-processing security decision, not an authentication prerequisite to apply indiscriminately. Investigate a particular failure with the security team; do not broadly disable scanning or relax incoming-ticket restrictions to make a test appear successful.

Verify public DNS and provider status

These commands use fictional names. Substitute the generated CNAME owners and actual authoritative nameserver. Repeat the CNAME query for all three account-generated rows, not just these two naming examples:

dig +short NS example.com
dig +short NS support.example.com
dig @ns1.example.net CNAME selector1._domainkey.support.example.com +noall +answer
dig @ns1.example.net CNAME selector2._domainkey.example.com +noall +answer
dig CNAME selector1._domainkey.support.example.com +noall +answer
dig TXT selector1._domainkey.support.example.com +noall +answer
dig TXT example.com +noall +answer
dig TXT support.example.com +noall +answer
dig TXT _dmarc.example.com +noall +answer
dig TXT _dmarc.support.example.com +noall +answer

The authoritative answers should match the approved owner/target pairs. Follow each relevant DKIM alias through to a usable public key. Query SPF at the actual envelope owner and check the complete policy. An empty NS response for a child can simply mean it is not separately delegated; establish the authority before choosing a server.

If authoritative answers are correct but a recursive resolver still returns old data, account for TTL and negative caching. If the authoritative response is wrong, waiting will not repair it. Investigate missing records, duplicate suffixes, CNAME collisions, unresolved targets or DNSSEC-related SERVFAIL with the DNS owner.

Return to Service Desk's domain verification control after publication. Retain the status and timestamp, but keep message acceptance open until the real notification routes have been checked.

Require branded DKIM and route-specific message evidence

Have an authorized administrator generate harmless examples of both a user-action notification and an automatic notification. Receive them at controlled external mailboxes and save the original source from the final receiving system.

For each class, record the expected and observed From, display name, Reply-To, MAIL FROM/Return-Path, sending IP, each DKIM d= and s=, and trusted receiver-added Authentication-Results. Do not infer these results from a copied email body or an untrusted upstream header.

The custom-domain route is accepted only when:

1. The intended branded DKIM signature has dkim=pass and aligns with the visible From domain.
2. The receiver reports dmarc=pass for the expected From identity.
3. SPF's actual result is understood and errors have been resolved or explicitly held for investigation.
4. The observed identity matches the agreed notification class, and replies follow the intended support workflow.

DMARC can pass through either aligned SPF or aligned DKIM. Requiring intended branded DKIM here is an operational commissioning standard, not an assertion that DMARC always requires both mechanisms. A provider-owned passing signature does not substitute for the configured branded signature. DMARC alignment rules.

Do not classify spf=fail, softfail, none, temperror or permerror as merely “not aligned.” Investigate the envelope owner, authorization, duplicate policies, lookup limits and DNS availability. A message with aligned DKIM can still pass DMARC despite a genuine SPF problem; repair that problem. Compare direct versus forwarded delivery before changing SPF to authorize an intermediary.

Preserve DMARC policy and monitor reporting

Review the DMARC policy effective for the actual From domain, including applicable parent and subdomain controls. Relaxed adkim or aspf alignment permits the same Organizational Domain; strict mode requires an exact domain match for that mechanism. p=reject describes disposition, not alignment mode.

Retain existing policies and reporting recipients. Do not create a second DMARC TXT record or reduce enforcement for the whole company to conceal a Service Desk issue. If neither a direct nor an inherited policy exists and a monitored initial rollout is appropriate, this fictional example illustrates the format:

For the apex example.com, the full DMARC owner is _dmarc.example.com, usually entered as _dmarc in that zone. For a From domain of support.example.com, the full owner is _dmarc.support.example.com: enter _dmarc.support in the parent example.com zone, or _dmarc in a separately delegated support.example.com zone. Use the full owner instead where the editor requires it, and never create a new child policy merely to override an inherited policy without the domain owner's approval.

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

The report mailbox must exist and be approved. When using an external reporting service, follow its destination-authorization requirements. Aggregate reports help identify sources and alignment patterns, but their delays and incomplete receiver coverage mean they are not notification receipts. DMARC aggregate reporting.

Domain-wide enforcement needs an inventory beyond this application. Review other senders, forwarding and valid DKIM before adopting a reject policy; one passing Service Desk message is not sufficient. DMARC operational considerations.

Troubleshooting and recovery

• Domain remains Not verified: compare all three generated pairs with authoritative DNS. Check the account context, suffix handling, collisions and cached negative answers.
• Personalized address or Reply email address option is missing: check whether domain authentication is complete in the correct account context.
• Automatic mail is not personalized: compare notification classes before changing DNS; inspect actual authentication separately.
• DKIM passes under an unexpected provider domain: keep the branded route open. Compare the current account's generated package with the signature and ask Support to confirm signing activation.
• DKIM fails with a correct DNS key: investigate the exact selector, stale keys and modifications after signing, including gateways that alter bodies.
• SPF errors coexist with DMARC pass: fix the actual SPF or DNS defect. Do not use the DMARC pass as proof every component is healthy.
• Mail is absent despite valid authentication: examine suppression, bounce details, receiver logs and placement. Avoid blindly removing suppression or broadening security exceptions.

Fictional example: an agent comment uses the intended From, while an automatic notification has a different address. The administrator should first classify the event and compare its trusted headers. If the automatic path is expected to use the custom identity but lacks aligned branded DKIM, hold that path for Support review; the successful comment cannot certify it.

For rollback, restore only approved affected records or supported application settings. Preserve unrelated sender policies and selectors needed by queued messages. Keep authentication repair, incoming-ticket security and reply routing as separate changes with separate owners.

Related route guidance

If the organization also sends application mail through Microsoft 365, review that separate route using the Microsoft 365 connectors, SMTP relay and direct-send guide. Those Microsoft 365 settings do not configure Service Desk; the distinction helps preserve the other legitimate senders sharing a domain.