Identify the route
TOPdesk can use its SaaS mail servers or an organization's mail server. This procedure covers the SaaS route; if your organization relays through its own server, obtain that server's authentication instructions instead. Record the sending workflow and intended From domain before editing DNS. No account configuration or live test was performed for this guide.
Authorize SaaS sending
TOPdesk's current source directs administrators to merge include:spf.topdesk.net into existing SPF instead of listing individual servers. Request domain-specific DKIM and a domain restriction through My TOPdesk's request form. Domain restriction limits use of your domain to your TOPdesk environments. Obtain the resulting account instructions for DNS and activation; this public page does not supply a universal selector or key. Do not improvise a private-key upload based on an older third-party recipe. See the TOPdesk source below.
Original service-desk acceptance design
Use one manually triggered ticket notification and one automated workflow notification, each addressed only to a controlled test mailbox. Record which route sent each message. Compare actual From values with the approved list; do not assume an operator notification and a background automation share a sender. Preserve the returned DKIM setup instructions alongside the DNS evidence without exposing credentials.
A separate security check belongs in the ticket: identify every legitimate TOPdesk environment that must use the domain before requesting restriction. An incomplete environment inventory could disrupt a real service-desk workflow. The acceptance design asks for that inventory and for the request outcome, but does not claim the restriction has been applied or tested.
Decide what a failure means
An SPF pass for a provider domain does not by itself establish alignment with the service desk's From. If DKIM passes with an unrelated signing domain, collect the raw headers and compare them with the domain-specific configuration request. If both authenticated identifiers differ from the intended From, stop the release and ask the service owner to resolve the route. Do not use a whole-domain DMARC exemption as the first repair.
If a test succeeds through the organization's relay but fails through SaaS, that is evidence about two different paths, not intermittent DNS. Keep route-specific results and rollback instructions. A controlled switch back to an already validated relay can be a recovery option only after the owner confirms that it supports the required workflow.
Prove the identity at the receiver
Use a controlled external mailbox and send through the production workflow, with harmless content and no customer data. Save the raw message, timestamp and the receiving system's Authentication-Results. Ignore authentication assertions inserted by an untrusted sender. Record the visible From domain, Return-Path or authenticated envelope identity, and every DKIM d= and s= pair. A display name or Reply-To address is not the DMARC identity.
SPF pass authorizes the connecting server for the evaluated envelope identity. DKIM pass validates a signature for its signing domain. DMARC needs a passing method whose domain aligns with the visible From: strict alignment requires the same domain; relaxed alignment permits the applicable organizational-domain relationship. A provider-owned signature can pass without authenticating your visible From. One passing aligned DKIM signature can satisfy DMARC even when another signature fails. These protocol rules come from RFC 7208, RFC 6376 and RFC 9989, listed below.
Check authoritative DNS before diagnosing caches. Ask an authoritative server for the exact name and type, then compare a recursive resolver after its cached lifetime. For DKIM, follow any CNAME to its public-key TXT response. Never publish a private key. Keep one SPF policy at each evaluated name and check the ten DNS-lookup-causing-term limit across nested includes. Do not replace a shared SPF policy with a provider example.
Recovery and acceptance
Pause the affected workflow if tests show a new regression. Compare the changed record with the saved version and undo only that change after checking other senders. Recheck DNS and resend after recovery; reverting a value does not flush every resolver immediately. Keep old DKIM verification records available while previously signed messages may still be in transit, unless a security incident requires revocation.
Accept the change only when DNS, application state and a real received message agree. Record the flow owner, evidence timestamp and next review trigger. Inbox placement alone is not proof of authentication, and successful authentication does not guarantee inbox placement. Do not tighten a shared domain's DMARC policy on the strength of one provider's test. Inventory the other legitimate sources first.
Inventory the environments before domain restriction
Written case TD-01 assumes support@example.org is used by two legitimate SaaS environments, production and training. The proposed restriction request lists only production; neither environment’s resulting restriction state has been observed. The service owner must reconcile both environments with the security owner before requesting the intended boundary, and plan harmless manual and automated notification checks for each. The DNS administrator still needs the domain-specific DKIM response; no selector or key is invented here. All message authentication results remain unknown. No request, restriction, key upload or ticket notification was executed.
Preserve the enforcement boundary
RFC 9989 Section 7.4 requires valid DKIM, not SPF alone, for domains publishing p=reject, and warns about indirect-mail and mailing-list interoperability. A single successful direct-message test is not proof that every legitimate route is ready for stronger policy. Keep existing approved protection while diagnosing the actual gap; any policy change needs its own decision.