Scope the recruiting identity before configuration
Zoho Recruit documents Setup > General > Email Settings > Email Authentication > Add Domain. The entered address receives a verification code, described as valid for 15 days. After verification, Validate exposes SPF and DKIM details for publication as TXT records. Recruit Email Authentication
The proposed scope should identify the recruiting organization, account, edition, region, intended sender domain and message categories. A staffing agency may communicate under several legitimate brands, while an internal recruiting team may use a dedicated subdomain. Neither arrangement justifies assuming that every configured sender belongs to the same domain owner.
Identify the person responsible for candidate-facing identity and the administrator responsible for DNS. Do not request access to candidate records merely to review authentication configuration. The catalogue implementation requirement remains open: this manuscript has not accessed a Recruit tenant, requested a verification message or inspected a real candidate communication.
Keep address verification separate from DNS authorization
The DNS guide directs administrators to copy the record details exposed by Validate. It discusses combining existing SPF authorization into one policy and warns about DNS editors appending the domain suffix. Its displayed SPF and selector values are examples, not proof of a particular account's current settings. Recruit DNS settings
A received verification code confirms a checkpoint in the application's workflow, but it is not the public key record itself. Retain the fact and time of verification without storing the code in a permanent project file. Separately retain the generated DNS request and the domain owner's approval to apply it.
If a recruiting consultant uses a customer's domain, do not infer permission from a familiar company name or an email exchange. Establish who is authorized to configure that domain and which sender identity the customer approved. The proposed handover should make this ownership relationship explicit before a new sending dependency is created.
Review the complete SPF policy without copying examples
SPF identifies permitted sending paths for its specified SMTP identities. Review the actual route's envelope identity before deciding where a proposed policy change belongs. The visible recruiter address alone is not enough to determine the evaluated domain, and a remembered Zoho Mail value is not a universal answer for every Zoho application.
At a relevant owner name, multiple selected SPF records cause an error. Merging an existing policy therefore requires a complete review rather than adding a second record for the new application. Preserve other legitimate senders, mechanism ordering and termination behavior. Review nested DNS-dependent terms against the evaluation limit as well; a short-looking policy can still depend on a longer chain.
A policy review is not a record of a message result. The proposed evidence should distinguish generated instructions, approved publication and an actual receiver's evaluation. Do not label a domain authenticated merely because a sample string is syntactically plausible. RFC 7208, section 2.4; RFC 7208, section 3.2; RFC 7208, section 4.6.4
Verify the selector name and complete key data
A DKIM signature supplies a selector and signing domain, which together identify the key lookup. Retain the exact account-generated owner name and public value. Do not reuse the sample selector in a help article or replace an existing key without identifying its active dependencies.
The DNS editor's suffix behavior matters. Some interfaces append the zone automatically, while others accept a fully qualified name. Compare the intended final lookup name with the actual editor semantics; removing the suffix blindly is no safer than always including it. In master-file notation, standalone @ means the current origin, not every subdomain.
TXT key data may be represented as several character strings within one record. Preserve the complete logical value and avoid confusing that representation with several separate records. No private signing key is required for an ordinary publication review. Treat credential or private-key requests as a different security-sensitive action, not an expected attachment to the DNS worksheet. RFC 6376, section 3.5; RFC 6376, section 3.6.2.2; RFC 1035, section 5.1; RFC 1035, section 3.3.14
Apply DMARC semantics rather than broad product shorthand
DMARC evaluates the relationship between the author domain and a passing authentication identity. A passing aligned SPF path or a passing aligned DKIM path can satisfy the authentication requirement; it is not a universal requirement that both mechanisms pass. Also, a DKIM signature is not message encryption and does not establish the confidentiality of a candidate's application.
The proposed received-message review records the visible From domain, signing domain, selector, relevant envelope identity and trusted receiver results. Confirm the route and time of the sample so evidence from another account, brand or transport cannot be substituted accidentally. A successful domain configuration checkpoint remains distinct from these message observations.
Authentication does not establish that a job offer is genuine, that a recruiter is authorized to request a payment, or that a recipient should disclose identity documents. Those business decisions require separate verification. Avoid turning a technical acceptance statement into a guarantee about recruitment legitimacy or legal compliance. RFC 9989, section 4.4; RFC 6376, section 1
Acceptance worksheet for recruitment operations
Use this original proposed worksheet to preserve domain ownership and candidate privacy throughout the project.
- Organization scope: Recruit account, edition, region, brand and message categories included in acceptance.
- Sender ownership: intended author domain, accountable recruiting team and any customer-domain authorization boundary.
- Verification checkpoint: completion evidence and timestamp without saving the one-time code.
- Generated records: exact names, types and public values linked to the account that issued them.
- Existing dependencies: affected SPF policy, selectors already in use and the approved change owner.
- Message acceptance: representative route, minimized header evidence, trusted results and alignment interpretation.
- Privacy controls: avoid candidate attachments, application answers and unnecessary personal identifiers in diagnostic material.
- Release decision: named reviewer, unresolved current-account questions and continuity plan for scheduled recruitment communications.
This worksheet is not a completed audit. No candidate data has been collected, no DNS records have been queried or changed, and no recruitment messages have been sent for this manuscript.
Fictional diagnosis: a sample from another recruiting brand
A fictional staffing business authenticates a domain for its main brand and later introduces a customer-specific recruitment address. During review, an administrator presents a passing message from the main brand as proof that the customer-facing route is ready. The two messages have different author domains and ownership relationships, so the conclusion is unsupported.
The proposed correction begins with the approved sender inventory and the exact account-generated configuration. The team requests appropriate evidence for the customer-facing route without copying candidate applications or forwarding confidential attachments. It also reviews whether the domain owner has approved the proposed sending relationship.
The final report states which route has evidence and which remains unverified. It does not infer impersonation or provider failure from the missing evidence alone. This scenario is fictional and does not describe a real Recruit account, an executed message test or a verified incident.