Zoho People SPF, DKIM & DMARC Setup: Step-by-Step Guide

For branded Zoho People notifications, configure the application's domain-specific DKIM TXT record and validate it in People. Do not copy a Zoho Mail SPF record into your domain just because both products have Zoho in their names. This guide covers People application notifications, not staff mailbox hosting, Zoho CRM, Campaigns or an independently configured SMTP service.

This is a source-reviewed configuration guide, not a claim that a customer account or message has been tested. Authentication improves identity verification; it does not guarantee inbox placement.

Before you start

Confirm the notification actually originates in Zoho People. A staff member's mailbox, a recruitment integration and an HR application notification can have different sending systems even when all display the same domain. Authentication configured for one does not automatically configure the others.

Have the People account administrator and the authoritative DNS administrator available. The reviewed documentation does not establish a universal subscription entitlement, region-specific selector or precise permission-role name. If the controls are missing, ask the account administrator to establish access for this operation rather than changing subscriptions, accounts or security permissions.

Record the intended visible From address, the current authoritative DNS provider, existing selectors, and applicable DMARC policy. Preserve current mailbox routing, working sender authorizations and reporting recipients. This task requires no MX change, domain transfer, website rebranding or nameserver migration.

Find your domain and obtain its DKIM record

In People, open Settings > Manage Accounts > Organization Setup > Email Authentication. Domains are populated from active users and verified From addresses; you cannot manually add or remove them on this page. Public-mail domains are excluded. Select the intended domain's DKIM Details and copy its TXT requirement. Official People authentication workflow.

The illustrated dialog labels the fields Hostkey and Hostvalue. Its DNS Provider selection changes the host-key representation. The values are blurred in the documentation, so neither a universal selector nor a public key can be inferred from the illustration. Use your own account's current values. The People account FAQ also describes choosing the DNS provider and copying the displayed hostname/value.

Keep the selected domain and the issued record together in your change notes. If a domain is absent, investigate the underlying user/From-address configuration with the administrator; do not manufacture a selector or try to create a domain entry in the authentication list. A mailbox confirmation and domain-signing configuration are different checks.

Publish the TXT safely

At the authoritative DNS host, add the complete public DKIM TXT data for the exact owner issued by People. Preserve all tags and the entire key. Do not publish a private key, substitute a record from a screenshot or paste a PEM certificate in place of the issued TXT value. Never overwrite another sender's selector merely because its name looks similar.

Understand the DNS editor's naming convention before saving. These are owner-format illustrations, not Zoho records:

Full owner selector._domainkey.example.org belongs beneath the example.org zone as selector._domainkey when the editor appends that zone suffix.
In a separately delegated _domainkey.example.org zone, the relative owner is selector.
For an actual child sending domain, determine its authoritative zone first. A separate child delegation changes where its record belongs; an editor at the parent is not necessarily authoritative for it.

Use the issued full owner as the reference point and inspect the resulting public name. Adding a full name to an editor that automatically appends the suffix can produce the wrong owner twice. Conversely, truncating a name in an editor that expects a full name can put it in the wrong place.

If the issued TXT owner already has a CNAME, stop and investigate. TXT and CNAME cannot coexist at the same owner. Preserve delegations and shared dependencies; request a supported resolution instead of deleting an existing alias or nameserver delegation. Multiple unrelated TXT records elsewhere in the zone are not a reason to erase them.

This documented route uses TXT, not an HTTP-proxied CNAME. Do not invent CNAME targets, change global flattening settings or toggle proxy options to fit an unrelated tutorial. DNS publication is public: retain only the necessary public record data in shared change notes, never credentials or private signing material.

Validate authentication

After DNS publication, return to People and click Validate Authentication. The required result is Authenticated. The official screenshot's button agrees with the main instructions; an incidental sentence mentioning “Get again” is not a separate required control. Allow cached DNS answers time to expire, but first rule out incorrect owners and incomplete values. People validation instructions.

People requires authenticated domains for custom From addresses; otherwise it uses noreply@zohopeople.com. A provider-address fallback can deliver a notification without proving your branded domain works. Confirm the intended From identity in the actual notification configuration and then in a received message. Do not treat Reply-To, a display name or a successful mailbox verification as a substitute for authenticated visible From.

What about Zoho People SPF?

The reviewed People workflow supplies DKIM TXT instructions, not a People-specific universal SPF include. This is an evidence boundary, not a claim that SPF is irrelevant or unsupported. Do not borrow a Zoho Mail, CRM or Campaigns include, or copy the SPF policy of Zoho's corporate domain.

SPF evaluates the SMTP envelope sender, usually shown in trusted receiving results as smtp.mailfrom, rather than automatically checking the visible From address. Identify the actual envelope domain of a People notification before considering any change. If it is provider-owned, changing your root-domain SPF does not change that identity or make it align with your brand.

Where the provider confirms a customer-controlled envelope route, obtain that route's exact supported SPF requirements before editing it. Keep one v=spf1 TXT policy at the evaluated owner, preserving other legitimate senders and intended qualifiers. Count the ten evaluated DNS-dependent-term limit including nested mechanisms, not merely ten literal includes. A redirect is ignored when an all mechanism is present. A qualifier is not a promise about final inbox placement or receiver rejection. SPF specification.

Do not mark SPF healthy solely because DKIM makes DMARC pass. Record and diagnose SPF failure, temporary DNS error and permanent evaluation error separately. A configuration error and an alignment difference are not the same thing.

Keep DMARC protection intact

DMARC compares the visible From domain with authenticated identifiers. Relaxed alignment permits the relevant Organizational Domain match; strict alignment requires exact domain equality. Either aligned SPF or aligned DKIM can satisfy DMARC, but acceptance of this new DKIM configuration specifically requires its intended signature to pass and align. A separate SPF-based DMARC pass cannot prove the new key works. See DKIM alignment and the visible From domain and the current DMARC specification.

Preserve existing direct and applicable inherited policies. A People warning about DMARC does not authorize weakening quarantine/reject, creating a second record or replacing reporting destinations. Check the applicable policy and actual From domain before changing anything.

Only when no applicable direct or inherited policy exists, the owner approves, and a monitoring plan is agreed, an initial TXT policy can be v=DMARC1; p=none. For illustrative From domain example.org, the owner is _dmarc.example.org; for news.example.org, it is _dmarc.news.example.org. Map the owner relative to its authoritative zone. These are conditional examples, not records every reader should add. This minimal policy does not itself request aggregate reports.

Choose report recipients intentionally. When a destination is in a different Organizational Domain from the domain where the DMARC policy was found, the report-generating receiver must check DNS authorization. A destination within that same Organizational Domain is excepted. DNS authorization does not replace the owner's approval to share operational data. Never copy a tutorial's external reporting mailbox. Aggregate-report authorization, RFC 9990 section 4.

Verify a real notification

After approved configuration, use an authorized, controlled recipient and a minimal notification through the intended People workflow. Avoid triggering a bulk HR event or exposing employee information just to test authentication. Where possible, use a permitted test record containing no unnecessary personal information. This article has not performed such a test.

Inspect the original received message. Use authentication results produced inside the receiving service's known processing boundary, following its documented handling of externally supplied Authentication-Results, or ask the receiving administrator for a trusted trace. A familiar authserv-id string or header position alone is not proof; ignore attacker-inserted or untrusted result fields. Authentication-Results specification.

Record the visible From domain, actual envelope identity, intended DKIM signature's d= signing domain and s= selector, plus trusted SPF, DKIM and DMARC results. Accept the branded setup only when:

The visible From is the intended brand address, not the provider fallback.
The intended People signature passes DKIM and aligns under the applicable relaxed or strict policy.
The trusted receiving service reports DMARC pass.
SPF errors are separately investigated rather than hidden by the DKIM result.

A message can contain several signatures. A passing unrelated provider signature is insufficient if the intended branded signature fails or does not align. Test materially different notification paths separately. Forwarding or later content changes can alter results; examine the actual route instead of automatically replacing the key.

Troubleshooting and FAQs

Why is our domain missing from Email Authentication?

Review the account's active-user and verified From-address configuration. The authentication page is not a manual domain registry. For a domain you do not control, such as a public mailbox provider, you cannot publish that provider's customer-domain DKIM record. Ask the administrator to resolve the intended sender identity first.

Why does validation remain pending?

Check the selected domain, DNS Provider representation, actual public full owner and complete TXT value. Confirm the DNS service being edited is authoritative. If those are correct, allow cache expiry and retry validation. Waiting cannot repair a duplicated suffix, a truncated key or a record saved in an inactive zone.

Should I add the SPF include from a Zoho Mail guide?

Not on the strength of this People setup. Match the product and actual envelope route. Existing mailbox SPF should remain intact; a shared vendor name is not evidence that another product's record applies.

People says Authenticated, but notifications use the default sender

Check which notification configuration produced the message and which From address it selected. Compare its domain with the authenticated domain. A DNS success does not prove every notification uses that identity. Preserve the actual failed example and have the administrator resolve the route rather than claiming fallback delivery as branded success.

DKIM passes but DMARC fails. What should I inspect?

Compare the passing signature's signing domain with the visible From under the applicable alignment mode. Check that you are reading trusted receiver results for this message, not a previous test or an injected header. Investigate actual identities before changing enforcement; lowering the policy does not fix misalignment.

Can I remove old selectors after adding this one?

Not without confirming their dependencies. Other applications and queued messages may use them. Coordinate any rotation or retirement with the responsible sender and retain the new configuration's evidence. A newly authenticated record does not prove every older key is unused.

What should go into a support request?

Use the approved support channel and include only necessary sanitized evidence: product, intended domain, validation state, exact public owner/type, time of the check and relevant trusted results. Do not send passwords, private keys, unrelated employee data or full HR-message contents. Make clear whether the problem is record discovery, People validation, sender selection or delivered-message alignment.

Sources and limits

The primary sources are the Zoho People Email Authentication instructions, including its DKIM-details and successful-validation illustrations, and the relevant authentication section of the People general account FAQ. Account-specific values must come from the current account, not these illustrations.

This review did not access a customer account, change DNS, send a message, test delivered headers or publish a page. Source-document review and static manuscript checks are not hands-on implementation testing, live CMS rendering or evidence of search rankings.

Zoho People SPF, DKIM and DMARC setup, step by step

On this page