Topdesk SPF, DKIM and DMARC setup, step by step

For email sent through TOPdesk SaaS mail servers, merge include:spf.topdesk.net into the existing SPF policy and request domain-specific DKIM signing through My TOPdesk. TOPdesk also recommends a domain restriction so only your approved TOPdesk environments can use the domain. If TOPdesk sends through your company's mail service instead, configure SPF and DKIM for that actual service rather than copying the SaaS records. TOPdesk sender-domain guidance, sending options.

This guide distinguishes SaaS outbound mail from customer-controlled SMTP, Microsoft Graph and Google Mail connections. It does not assume the SaaS authentication service applies to every self-hosted or Virtual Appliance installation. No account settings, DNS records, service requests or delivered messages were changed or tested.

Identify the outgoing mail route first

Open Settings > Functional Settings > Email module. Check whether TOPdesk uses its default SaaS outgoing server or Send emails via my company's mail server. Record that choice before asking the DNS administrator to authorize anything. The documented customer-mail connections are SMTP with basic authentication, Microsoft Graph with OAuth 2.0 and Google Mail with OAuth 2.0. TOPdesk recommends OAuth where supported. Outgoing email settings.

Authentication for an application connection and authentication of a delivered message solve different problems. A successful Graph, Google or SMTP connection can still send a message with the wrong From domain or an unaligned signature. Obtain generated domain records and signing activation from the mail service that actually delivers the message, then use the same receiver checks below. Do not switch a working mail route solely to obtain a simpler DNS recipe.

Inventory sender addresses and environments

TOPdesk's Default email of sender is used for automated messages when no logged-in user's address or template sender supplies an address, including relevant API and Action Management mail. Review manual notifications, automated actions and explicit template senders separately. A successful operator message may not represent a background workflow. Default-sender behavior.

Prepare a worksheet with:

• Every legitimate environment using the domain, including production, training and test systems.
• The complete visible From domains and expected reply addresses.
• The actual outgoing mail service for each environment.
• A DNS administrator, TOPdesk administrator and security approver.
• Current SPF, DKIM, DMARC and MX records, including child-zone delegation.
• A harmless manual and automated test for each distinct route.

Keep two similarly named controls separate. The email module's Allowed domains restricts recipient addresses. The domain restriction requested from TOPdesk controls which TOPdesk SaaS environments may send using your domain. A recipient restriction is not a DKIM setting or a sender-domain security boundary. Recipient restrictions, SaaS sender restriction.

Authorize TOPdesk SaaS with SPF

For the SaaS route, TOPdesk instructs customers to add include:spf.topdesk.net to the existing SPF policy. Use the maintained include rather than a snapshot of individual TOPdesk server IP addresses. Official SPF instructions.

If no SPF policy exists and TOPdesk SaaS is the only legitimate sending service for the exact owner, this illustrative starting value authorizes it:

v=spf1 include:spf.topdesk.net ~all

Do not overwrite an existing corporate policy with that example. Preserve its authorized senders and approved terminal qualifier, inserting the include before all. Do not add a, mx or ptr mechanically from an older example: each mechanism has consequences, and RFC 7208 discourages ptr. Review the complete policy rather than treating a copied sample as a sender inventory. SPF mechanisms, ptr guidance.

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

Publish only one SPF policy per owner and evaluate nested includes against the ten DNS-lookup-causing-term limit. A root policy is not inherited by a child MAIL FROM domain. Other TXT records can coexist, and multiple quoted strings in one TXT answer may belong to a single record. SPF processing limits.

SPF authorization is not SPF alignment

SPF evaluates the SMTP MAIL FROM identity, normally visible in Return-Path and the receiver's smtp.mailfrom. DMARC compares that identity with the visible From domain. A TOPdesk-owned envelope domain may pass SPF but not align with a customer From domain. The reviewed public TOPdesk documentation does not establish a self-service custom Return-Path control; establish actual behavior from headers and current provider guidance rather than promising it. SPF identity.

If your organization uses its own mail server, authorize that route according to the delivering service's current instructions. Do not remove the SaaS include merely because one environment has migrated: check whether any other legitimate environment still uses SaaS outbound mail.

Request domain-specific DKIM and the right restriction

TOPdesk's current supported SaaS procedure is request-mediated:

1. Open Adding TOPdesk as a secure sender domain and follow its request form on My TOPdesk link.
2. Request domain-specific DKIM for the exact From domain. Identify the legitimate TOPdesk environments that must use it before requesting the accompanying domain restriction.
3. Obtain the resulting setup instructions: full DNS owner names, record types and values, intended signing domain, and the activation/confirmation steps applicable to your request.
4. Have the DNS administrator compare each issued record with the existing zone and publish only the approved public records.
5. Complete the provider's activation process and obtain confirmation for the intended domain and environments. Then verify a newly delivered message.

The public page confirms the request process but does not publish a universal selector, key, CNAME target or guaranteed activation time. The My TOPdesk form is an account workflow whose fields and completion were not verified here. If you cannot access it, use your organization's authorized TOPdesk contact. Do not invent DNS values or follow a third-party private-key upload recipe in place of the current response. Never put a private signing key into DNS or an online checker. Current DKIM and restriction instructions.

A domain restriction blocks use of the domain by other TOPdesk SaaS environments. Reconcile the production, test and training inventory first so a legitimate service desk is not omitted. Keep the restriction request outcome separate from DKIM status: one control limits sender use within TOPdesk, while the other produces a signature recipients can validate.

Publish exact DNS owners for the selected domain

The table below is only a DNS-naming exercise. ISSUED-SELECTOR is a placeholder, not a TOPdesk selector. Your actual record type and content must come from the provider or the mail service responsible for your route.

For a root sender at example.com, its SPF owner is the zone apex and a DKIM selector owner is ISSUED-SELECTOR._domainkey.example.com. Use full names instead if your editor requires them. Verify the final owner rather than trusting a relative-name entry; avoid accidentally appending the zone twice.

At an existing delegated _domainkey.support.example.com authority, the full issued DKIM owner ISSUED-SELECTOR._domainkey.support.example.com maps to relative ISSUED-SELECTOR. Preserve its NS delegation and other selectors, and publish only the actual account-issued record type and value. Relative DNS names.

If the issued record is a CNAME, use the exact target hostname, with no URL scheme and no web proxy. Check that its owner is not already occupied by an ordinary TXT, MX or conflicting CNAME. If the provider issues a TXT public key, copy the complete public value without inserting line breaks or deleting key material. Do not publish both record types at one owner as a hedge. Do not change MX records, delete another sender's selector or reconfigure delegation to work around a conflict. DKIM public-key storage.

For authentication CNAMEs, preserve the visible alias rather than flattening it into address records. On Cloudflare, check both the record’s Flatten option and the zone-wide flatten-all setting, as well as DNS-only status. Coordinate any shared setting change with the DNS owner; preserve legitimate child-zone delegation. Cloudflare CNAME verification guidance, flattening controls.

Keep the required literal CNAME answer: turn relevant per-record Flatten off where available and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, apex CNAMEs are flattened by default and same-zone targets are flattened regardless of that setting; flatten-all cannot be overridden per record. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration without breaking other services or removing NS delegation. These are DNS-host behaviors, not controls assumed in the sending provider. Cloudflare flattening controls and limits.

Preserve DMARC policy and reporting

DMARC can pass when SPF or DKIM both passes and aligns with the visible From domain. DKIM alignment compares the signature's d= domain with From. Relaxed alignment permits the applicable organizational-domain relationship; strict adkim=s or aspf=s requires an exact domain match. A passing signature for an unrelated service domain is not a branded-DKIM success. DMARC specification.

Read the effective DMARC policy for the exact From domain, including applicable parent discovery and any explicit child policy. Preserve existing enforcement, reporting destinations and alignment settings. Adding TOPdesk is not a reason to publish a second DMARC policy or replace an established p=reject or p=quarantine with monitoring mode.

Where no applicable policy exists, the domain owner may approve a monitored rollout such as this example at _dmarc.example.com:

Before using this first-policy example, confirm that no direct or applicable inherited policy exists and obtain the domain owner’s approval of the monitoring and review plan. Publish it as TXT at full owner _dmarc.example.com, relative _dmarc in the example.com zone. The existing child mappings apply only at their actual authority; preserve established policies and approved reporting recipients.

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the example reporting mailbox with an authorized monitored destination. A third-party report service can require destination-side authorization. Review aggregate data for all legitimate senders, not only TOPdesk, before a policy change. Test relevant forwarding and indirect delivery: RFC 9989 requires valid DKIM for domains publishing p=reject, rather than relying on SPF alone. Reporting specification, DMARC interoperability.

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.

Verify DNS and both manual and automated email

The following checks are a procedure, not completed observations. Replace all uppercase placeholders and fictional domains with the values for your route:

dig +short NS example.com
dig @AUTHORITATIVE-NAMESERVER TXT support.example.com
dig @AUTHORITATIVE-NAMESERVER CNAME ISSUED-SELECTOR._domainkey.support.example.com
dig @AUTHORITATIVE-NAMESERVER TXT ISSUED-SELECTOR._domainkey.support.example.com
dig @1.1.1.1 TXT ISSUED-SELECTOR._domainkey.support.example.com
dig @1.1.1.1 TXT _dmarc.support.example.com

Choose the authoritative nameserver for the actual zone, including a delegated child. Query the record type the provider issued: no CNAME is expected when the correct implementation is a direct TXT key. For a CNAME, follow the returned target to its final TXT public key. Expect the exact issued owner/value and a usable nonempty public key, plus one applicable SPF policy at the intended owner. Check public resolver results after cache expiry. A timeout or SERVFAIL needs investigation; it does not prove that a record is missing.

After provider activation, arrange authorized harmless tests to controlled external recipients:

• One manual operator notification with the intended From address.
• One automated action using the configured default or template sender.
• Additional samples for different domains, environments or customer-mail routes.

Keep the raw source securely and use the recipient's trusted Authentication-Results, not an assertion inserted by an untrusted sender. Record From, Return-Path, evaluated smtp.mailfrom, SPF result, all DKIM d= and s= values, DKIM results and DMARC result. Authentication-Results trust boundary.

For a message with multiple signatures, EmailAuth’s DKIM selector guide explains how to keep each actual d= and s= pair together for its public-key lookup. It does not supply a missing provider signing feature.

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

The branded-DKIM acceptance gate is an intended customer-domain signature that passes and aligns, plus dmarc=pass for the correct From domain. A message that passes DMARC only through SPF does not prove the requested signing configuration is working. Also confirm that recipients and reply routing are correct; a test redirected by recipient restrictions may not exercise the intended delivery path.

Require the intended active TOPdesk-issued signature, matching its configured d= and s=, to pass and align under effective adkim with the unchanged intended visible From, plus trusted receiver dmarc=pass for that From. For a separately selected company-mail route, require that route’s intended final mail-service signer instead. A different aligned signer, a rewritten provider From or SPF-only DMARC pass does not close this signing task; provider activation confirmation remains a separate gate. DKIM identifiers, DMARC alignment.

Distinguish SPF pass but unaligned from actual SPF failures and errors. An aligned DKIM pass can satisfy DMARC while SPF reports fail, softfail, neutral, none, temperror or permerror, but that does not close the SPF investigation. On a direct route, require a passing SPF result or a resolved, documented exception owned by the mail administrator. For customer-owned identities, repair the policy or route. For provider-owned identities, escalate the actual domain and receiver error to the delivery provider. Diagnose forwarding separately rather than adding unnecessary root-domain includes.

Troubleshoot the right TOPdesk layer

Pause only the affected change if a regression occurs. Restore approved records after checking dependencies and retest after cache expiry. Switching back to a previously working mail service needs an explicit route decision, not a blind fallback. Keep old public keys while relevant signed messages may still be in transit unless security response requires revocation. Authentication is necessary evidence, but it does not guarantee inbox placement or bypass receiver policy.