Identify the deployment and the final outbound sender
ManageEngine ServiceDesk Plus is not a single universal sending service with one SPF include. Start by identifying ServiceDesk Plus Cloud or the on-premises product, the instance, the deployed build where applicable, the configured outgoing service and the business workflow. Keep ServiceDesk Plus MSP, MSP Cloud and SupportCenter Plus outside this guide's asserted setup scope. Similar menus across those products do not establish interchangeable authentication settings.
For Cloud native mail, ManageEngine supplies an instance mailbox and supports a verified custom email address. For an external mail route, the configured mail service carries the message onward. The on-premises guide documents SMTP/SMTPS, Exchange Web Services and Microsoft Graph connection paths, whose controls vary. Cloud native mail guide and ServiceDesk Plus outgoing server guide.
Draw the route in plain language: requester-facing address, application instance, outbound server or API service, any downstream gateway, and controlled receiving mailbox. Record who administers each component. An inbound forwarding rule says where tickets arrive; it does not prove which service sends notifications. A portal custom URL likewise does not establish the email signing domain. Preserve current settings before changing either route, and identify which notification rules or group addresses depend on them.
Configure Cloud native mail only when that is the chosen route
In Cloud, the native service is configured under Setup > Mail Settings > Mail Server Settings. The provider documents an Activate step and an instance-specific support address. If native mail is already operating, an authentication repair should not casually deactivate or recreate the mailbox. If a migration is intended, treat incoming forwarding, ticket creation and outbound replies as one coordinated change with a rollback owner. Native service configuration.
For a custom address, use Setup > Mail Settings > Mail Addresses and New Email. The provider's sequence is domain verification using the displayed SPF and DKIM values, followed by the address-verification link. The DKIM material is domain-specific. After verification, the outgoing configuration selects the verified address in the Reply-To Address control. Copy the actual account values and complete the relevant verification state; do not import a selector or key from another organization. Custom-address verification and outgoing configuration.
Although the interface uses the label Reply-To Address, inspect both the actual From and Reply-To headers. Product labels are not a substitute for protocol evidence. The Cloud guide describes this control in its sender-address setup, while the on-premises guide describes field behavior differently across connection protocols. Record the observed result for the selected deployment rather than assuming one mapping applies to all editions.
Use documented Cloud labels and account-generated DNS
The April 8, 2026 Cloud release notes rename the DKIM configuration fields to Host/Name and TXT Value. Host/Name includes the selector in <selector>._domainkey form. Copy the current displayed values, then account for whether the DNS console appends the domain automatically. Do not add _domainkey twice because an older screenshot showed only a bare selector. ServiceDesk Plus Cloud release notes, DKIM Configuration.
For every proposed change, capture the full DNS owner, type, public value, affected domain and prior record. If the displayed SPF instruction resembles a complete policy, merge the required authorization with the existing legitimate senders instead of creating a duplicate policy or replacing corporate email authorization. Assess the effective DNS-lookup cost. Confirm that the published DNS answer belongs to the intended zone and data-center/account configuration before using the provider's verification action. SPF specification.
The reviewed sources do not establish a universal customer-controlled Return-Path option for Cloud native mail. Leave that capability unconfirmed unless current tenant or support evidence proves it. Do not create a bounce-domain MX record or borrow a Zoho product's SPF value merely because the organizations are related. Use the records shown for this ServiceDesk Plus deployment and inspect the envelope actually received.
Treat external and on-premises delivery as separate authentication work
For Cloud external mail, identify the actual outgoing mailbox service and the supported connection method in the current tenant. The older Cloud configuration guide describes external SMTP settings, but it does not prove that every historical authentication method remains supported. Validate the account's current method rather than enabling obsolete basic authentication to reproduce a screenshot. Cloud external mail settings.
For on-premises ServiceDesk Plus, an SDAdmin configures the selected outgoing protocol and server or API connection. The retained guide includes a sample-mail connectivity check and warns that a secondary mail server can remain in use after failover. If a secondary server is configured, include its sending identities in the acceptance plan rather than assuming the primary route always handles messages. Coordinate any return to the primary server as an operational change. Outgoing configuration and secondary-server behavior.
Connection authentication, such as OAuth, authorizes application access to a mailbox service. It does not itself publish SPF, enable DKIM signing or prove DMARC alignment. The administrator of the final sending service must verify those controls for the actual From and envelope identities. Request only the permissions needed for the approved integration. Keep passwords, tokens and client secrets out of DNS change tickets, screenshots and article evidence.
A successful sample mail establishes useful connectivity evidence, but a ticket reply, automated notification and custom-function message may have different defaults or routing. Test the business paths actually used. For on-premises changes, check whether mail fetching was temporarily stopped and restore it after the approved change so that authentication work does not silently prevent new tickets.
Check Cloud workflow rules before blaming DNS
The May 20, 2026 Cloud release notes describe recipient restrictions when the default native address is the sender for trial and newly configured Standard licenses. Non-login recipients can be skipped, or a message may not be sent when all recipients are non-login. Inspect system logs and the actual license/sender combination before diagnosing that symptom as an SPF problem. Cloud mail sending safeguards.
The same release history documents DRE sendmail offloading: custom-function email is treated as a system notification and uses the system sender rather than the function's supplied From value. Include custom functions in the workflow inventory and check the currently deployed behavior if a test shows an unexpected sender. Do not repair a system-sender mismatch by changing DNS for an address the application is no longer emitting. Cloud DRE sendmail behavior.
These application checks are separate from inbound filtering. An inbound message rejected before ticket creation does not prove an outbound authentication defect. Preserve the direction, timestamp and relevant log event in the incident record. Avoid disabling DMARC checks, broad allowlisting or relaxing the entire domain's policy as a diagnostic shortcut.
Complete the original received-message identity table
The required original identity table has not been executed here. Create a row for each tested deployment, instance, outgoing route, From domain and workflow. Include build or Cloud context, license where relevant, timestamp, ticket or test identifier, outgoing service, From, Reply-To, Return-Path, trusted receiver SPF domain/result, every DKIM d=/s= and result, DMARC result, alignment determination, recipient outcome and restricted evidence location. Distinguish an application refusal to send from a receiving server's authentication rejection.
Use synthetic tickets and controlled recipients. Check a requester reply, an automatic notification, any active group address and any material custom-function path. Where a documented failover route exists, test it only through an approved operational exercise. Verify that a reply returns to the intended ticket and that inbound forwarding does not create a loop or duplicate requests. Preserve original message sources while minimizing personal details in the review copy.
DMARC compares the visible From domain with a passing SPF or DKIM identity under the applicable alignment mode. A provider-domain DKIM pass or a branded help-desk URL alone does not prove alignment. Inspect all signatures and use the receiver's trusted results. DKIM specification and DMARC specification.
Recover the service while preserving domain protection
When no message is emitted, examine notification rules, recipient restrictions, sender verification and connection errors first. When delivery reaches the receiver but authentication fails, investigate the observed envelope or selector at the actual outbound service. If a gateway alters signed content, compare a controlled direct route with the affected path. If DNS passes but replies disappear, inspect forwarding and ticket-processing behavior separately.
Pause only the affected workflow where possible. Restore approved prior routing or DNS values when needed, then retest both outbound identity and inbound ticket handling. Do not replace the organization's enforced DMARC policy with a monitoring example as a universal recovery step. No tenant, server configuration, live DNS or received message was inspected here. Exact product/build confirmation, the original route-specific identity table, tenant-specific FAQ applicability and human mail-security SME approval remain open; this manuscript is an unpublished candidate.
Separate emission failure from authentication failure
For a proposed incident row, retain the workflow, sender selection, license/build context, application emission status, actual outgoing route and receiver evidence. If the application skipped a recipient, DNS changes cannot prove that a message was emitted. If the receiver rejected a transmitted message, retain the exact remote diagnostic. If authentication passes but a reply misses its ticket, investigate routing and threading separately. Leave unavailable evidence unknown rather than assigning the incident to SPF by default.