OTYS Recruiting Technologies SPF, DKIM and DMARC setup, step by step

For email sent directly through OTYS’s own relay servers, authorize the documented OTYS sender with include:spf.otys.nl, publish the DKIM TXT record issued by your OTYS consultant, and notify OTYS after publication so it can activate signing. DNS publication is not the final step: OTYS explicitly requires that activation handoff. Obtain the exact record owner and value for your account rather than guessing a selector. OTYS technical installation

This guide covers the existing OTYS GO! native outbound relay route. OTYS also documents sending through a customer’s external SMTP server and recommends that alternative; it is a different transport with its own connector, permissions and authentication requirements. This article does not create that connector, change transports, transfer a domain or configure an external mailbox. Confirm which route your account uses before editing DNS. OTYS sending-route distinction

Confirm the route

OTYS describes native relay sending for manually triggered and automatic messages, including workflow mail and application confirmations. It separately describes an External SMTP server configuration that sends through the customer’s mail environment. The application that composes a message is therefore not enough to identify the server that ultimately delivers it. Native and external-server routes

Ask the OTYS administrator to confirm the sending configuration for the exact message stream, intended From address and domain. If a customer SMTP connector is already in use, stop applying the native-only procedure and have the mail administrator use the supported instructions for that route. Do not remove an existing OTYS authorization merely because an external server appears in the configuration: resolve all actual sending dependencies first.

The reviewed native instructions do not specify a self-service role name, paid-plan gate or region-specific selector. Use your authorized OTYS account contact and DNS administrator; do not invent an Administrator-only button or assume account access proves signing is enabled.

For the native route, record the account, domain, message type, consultant responsible for DKIM activation, authoritative DNS host and approved test recipient. Inventory current SPF, DKIM, CNAME and NS records, inbound mail routing, and the effective DMARC policy. Save a dated baseline and agree who can pause an affected workflow and restore the approved configuration.

Use a harmless test contact or isolated workflow. Recruitment messages can contain personal information, employment decisions and private attachments. Do not use a real candidate’s record or trigger an application decision as a DNS test.

Obtain the DKIM packet

The technical installation page says the consultant supplies the DKIM key. Obtain that packet through your established OTYS support or implementation contact. Request enough information to publish it unambiguously:

• The OTYS account and sending domain it belongs to.
• The complete DKIM owner name, record type TXT, and complete public-key value.
• The selector and signing domain that OTYS will use after activation.
• Whether the proposed key is new or replaces an existing selector, and how queued messages and any rotation overlap will be handled.
• The person or case to notify after DNS publication, and how OTYS will confirm signing is activated.
• The SPF policy owner and actual envelope-domain arrangement for the native message stream.

The first-party procedure establishes key issuance and the final provider activation step. The extra items above make the DNS handoff auditable; they are not claims that a particular customer packet has already been supplied. If the full owner, public value or intended domain is missing, request the missing field rather than deriving it from another tenant. Consultant-issued DKIM and activation

OTYS’s external-server article contains a date-shaped selector example. It is not your issued selector, and its prose contains a _domeinkey spelling error. Do not construct a DNS name from that example. Use the exact complete owner issued for your account. Never publish a private signing key, password or API credential.

Authorize OTYS with SPF

The provider’s native installation guide names this mechanism:

include:spf.otys.nl

That is an SPF mechanism, not a second complete policy. The source supplies a sole-sender example below, but do not use it to overwrite a multi-service domain. Confirm the applicable policy owner and envelope scope with OTYS first. Official SPF instruction

v=spf1 include:spf.otys.nl -all

Use that complete example only if there is no existing SPF policy at the confirmed owner and the domain owner has established that OTYS is the sole authorized sender for that identity. If other legitimate senders exist, the approved single policy must include their authorization too. The example’s -all means unlisted senders fail SPF; it is not a harmless default for an unreviewed domain. Preserve a deliberate existing qualifier rather than automatically changing ~all or ?all. SPF fail, softfail or neutral does not dictate a guaranteed delivery or rejection decision.

For an existing policy with a terminal all, add the authorized OTYS mechanism before that terminal mechanism, preserving other approved senders and the existing qualifier. Do not create another v=spf1 TXT record or paste a second full policy into the first. If the policy uses redirect=, review the complete policy design instead of appending an all: any all mechanism causes redirect to be ignored. SPF policy evaluation and redirect

SPF evaluates the SMTP MAIL FROM identity, normally reflected by Return-Path after delivery. For a null reverse path it uses the HELO identity under SPF’s rules. It does not authenticate the display name or Reply-To, and a parent-domain SPF policy does not automatically authorize a child-domain identity. Confirm the actual evaluated domain before choosing an apex owner. SPF identity selection

Check the complete evaluated lookup chain. The combined limit is ten lookup-causing terms, including nested include, a, mx, ptr, exists and redirect; additional MX and void-lookup constraints also apply. ip4, ip6 and all do not consume that term budget. Do not replace the provider’s include with a one-time IP snapshot. SPF lookup limits

Publish at the authoritative zone for the confirmed owner. For an owner mail.example.com, a relative-name editor for example.com expects mail; a separately delegated mail.example.com zone uses its apex convention. A full-name editor expects the complete owner. Do not add TXT at an owner already occupied by a CNAME or remove a delegation to force a conflicting record into the parent zone.

Publish the DKIM TXT record

Use the consultant’s exact public TXT data. In a typical DKIM owner layout, SELECTOR._domainkey.SIGNING_DOMAIN identifies the lookup name, but the uppercase terms here are placeholders, not OTYS defaults. The account packet must establish both components.

Map the issued full owner to the authoritative DNS editor correctly:

• If the issued owner is SELECTOR._domainkey.mail.example.com and the zone is example.com, a relative-name field uses SELECTOR._domainkey.mail.
• If mail.example.com is separately delegated, that zone’s relative owner is SELECTOR._domainkey.
• If _domainkey.mail.example.com itself is delegated, its relative owner is SELECTOR.
• A full-name field uses the complete issued owner, with the sending domain appearing once.

These examples illustrate DNS name mapping, not a deployable key. Preserve NS delegations and unrelated selectors. If the requested owner already has a CNAME, another key or an unexplained dependency, resolve the conflict with the DNS owner and OTYS before replacement.

Keep the key’s characters and punctuation intact. Some DNS tools represent one long TXT record as multiple quoted strings; those strings must reconstruct the intended value. Do not insert arbitrary spaces, truncate the key or create several independent key records to fit a text field.

The OTYS installation page suggests escaping semicolons when there is a problem. Treat that as a representation issue to resolve with the specific DNS tool, not a blanket instruction to add literal backslashes to published data. Compare the actual TXT answer with the issued public value and ask the DNS administrator or OTYS to resolve any mismatch. Never regenerate the key locally merely because a DNS editor displays it differently. OTYS TXT publication instructions

Complete OTYS activation

After the records are published, notify OTYS that the requested changes are in place. Its documentation says OTYS then activates DKIM as the final step. Ask for confirmation for the exact domain and selector; a public TXT lookup alone cannot establish that the native relay is signing with it. Required final activation

An administrator can inspect the exact issued names with read-only DNS queries such as:

dig +short NS AUTHORITATIVE_ZONE
dig @AUTHORITATIVE_NAMESERVER DKIM_OWNER_FQDN TXT +noall +answer
dig DKIM_OWNER_FQDN TXT +noall +answer
dig SPF_POLICY_OWNER_FQDN TXT +noall +answer
dig _dmarc.FROM_DOMAIN TXT +noall +answer

Replace every uppercase placeholder. Query the actual authority, including a delegated child zone. Compare authoritative and recursive answers after caches expire. Check that the requested public key is complete and the intended single SPF policy is returned. Empty answers, NXDOMAIN or SERVFAIL are not verification successes. An unresolved DNS error is not fixed merely by waiting a predetermined number of hours.

Retain the issued packet revision, publication evidence and OTYS activation confirmation together. This guide does not promise an activation turnaround time; the cited native procedure supplies no service-specific completion deadline.

Preserve DMARC

DMARC compares the visible From domain with authenticated SPF or DKIM domains. Either passing aligned mechanism can satisfy DMARC; an unrelated provider-domain pass cannot be counted as branded alignment. With relaxed alignment, the authenticated domain and From domain share an Organizational Domain. Strict adkim=s or aspf=s requires an exact domain match for the corresponding mechanism. A child envelope domain is not automatically a strict match for a parent From address. Current DMARC standard

For this setup, require the intended OTYS DKIM signature to pass and align, not merely any other signature. Changing Reply-To cannot repair alignment. A provider-rewritten From address must be recorded as a different outcome, not proof that the intended branded sender authenticated.

Find the effective direct or inherited policy for the actual From domain. Preserve enforcement, alignment settings and authorized reporting destinations. Do not publish a child p=none override to bypass inherited protection. If no direct or applicable inherited policy exists, the domain owner approves a first monitoring policy and an appropriate monitoring plan is in place, the following is a minimal TXT value. This conditional example is not a replacement for an existing policy:

v=DMARC1; p=none

Publish only at the correct owner for the intended From domain:

A DNS editor expecting a full name uses the full owner instead. Do not create duplicate DMARC policies at one owner. The minimal value does not itself request reports. Add rua only for an actual authorized destination, not a sample recipient copied from another organization.

If the report destination belongs to a different Organizational Domain from the domain where the policy was found, the report-generating receiver must check DNS authorization. A destination within that same Organizational Domain is excepted; a different hostname alone does not make it external. Protocol DNS authorization does not replace the owner’s privacy and data-sharing approval. RFC 9990 §4

Do not copy the external-SMTP article’s pct=10 example or its explanation of report volume. The current DMARC specification supersedes RFC 7489 and removes pct; it is not a way to limit aggregate reports. A policy change affects more than one OTYS sample and needs a broader sender review. DMARC changes and policy requirements

Test the actual OTYS message

After authorized DNS publication and OTYS activation, send a harmless message through the exact native OTYS workflow being commissioned to a controlled receiver. A direct send from the organization’s usual mailbox does not test OTYS. Verify materially different manual and automated routes separately rather than triggering every live workflow.

Use receiver-controlled evidence to establish the trust boundary for Authentication-Results: documented receiving-service behavior for externally supplied Authentication-Results, trusted administrative logs or confirmation from its mail administrator about which results were produced inside its own receiving boundary. A familiar authentication-service identifier, copied delivery header or first-position result alone is not enough. Do not trust arbitrary upstream headers supplied with the message. Authentication-Results trust considerations

Record the intended and actual From, envelope domain, all DKIM d=/s= pairs, SPF result, intended OTYS signature’s result and alignment, and trusted DMARC verdict. Add the account, exact message type, record revision, activation confirmation, receiver and timestamp.

Accept the branded setup only when the issued DNS and provider activation agree, the intended OTYS signature passes and aligns with the intended From, and the trusted receiver reports dmarc=pass. Investigate unexpected SPF failures or errors even if DKIM supplied the DMARC pass. This is a commissioning criterion for the intended signing work, not a claim that DMARC always requires both mechanisms. Raw DKIM versus aligned policy results

Keep evidence private. Do not send candidate correspondence or raw messages with personal data to a public tester. Successful authentication does not guarantee inbox placement, authorize recruitment outreach or prove every OTYS notification is configured identically.

Troubleshoot and recover

DKIM key is visible but messages have no intended signature: confirm OTYS completed activation for this domain and selector. DNS publication alone is incomplete in the documented native procedure.

The key does not resolve: check the authoritative zone, issued full owner, duplicated suffix, delegation and TXT value. Do not guess a date selector or use _domeinkey from the source typo.

A published key differs from the packet: compare actual TXT data, including concatenated strings. Resolve DNS-editor escaping with the administrator; do not keep adding backslashes or generate a replacement key without OTYS coordination.

SPF permerror: check duplicate policies, syntax, nested lookups/loops and limits. SPF temperror: investigate transient DNS failure. SPF fail or softfail: inspect the real sending route, connecting address and envelope policy. Forwarding can alter the connecting IP; adding an apex include cannot change the envelope’s domain.

DKIM passes but DMARC fails: compare the actual signing domain with the visible From and effective alignment mode. A passing unrelated signature or a strict-alignment mismatch is not solved by changing Reply-To.

Mail now uses the external SMTP route: stop applying native-only assumptions. Have the mail administrator review that route’s current configuration and authentication. Do not create a relay connector or broaden IP trust as an improvised repair.

A change breaks a stream: pause the affected workflow where safe, preserve the failed sample privately, and coordinate recovery with OTYS and the DNS owner. Restore only the approved last-known-good configuration. Retain prior selectors while queued messages or rotation still need them; do not delete unrelated keys, publish +all, disable filtering or weaken domain-wide DMARC.

Sources and maintenance

Recheck current account instructions and preserve the issued packet when changing domains or keys. No customer account, DNS, candidate data or delivered message was accessed or tested; no support request, configuration change or publication was performed.