How to set up DMARC/DKIM/SPF for Zoho Mail
Published 5 Aug 2026
Updated 5 Aug 2026
11 min read
Summarize with
Zoho Mail needs one SPF TXT record that authorizes Zoho, a Zoho-generated DKIM TXT record that you verify and enable, and one DMARC TXT record at _dmarc. I start DMARC at p=none, confirm that SPF or DKIM passes with the visible From domain, then move to p=reject after every legitimate sender has been identified and fixed. Zoho supports return-path alignment, while DKIM provides the more durable DMARC pass when forwarding changes the delivery path.
Add your domain
I add and verify the sending domain in Zoho Mail before publishing authentication records. Skip this section if the domain already appears as verified in the Zoho Mail Admin Console.
- Open the console: Sign in to the Zoho Mail Admin Console with an Administrator or Super Administrator account.
- Add the domain: Open Domains, choose Add, enter the domain used after the @ in your From address, and continue.
- Copy the proof: Choose the TXT verification method and copy the host and value Zoho generates. Keep both values unchanged.
- Publish in authoritative DNS: Add the TXT record wherever the domain's nameservers point, then save it with a short TTL during setup.
- Verify in Zoho: Return to Domains and select Verify. Continue only when Zoho marks the domain as verified.
Adding and verifying a domain in Zoho Mail
Publish records in the active DNS zone
A record added at the registrar has no effect when the nameservers point elsewhere. I check the authoritative DNS host first, and I avoid adding the root domain twice when the DNS interface appends it automatically.
Set up SPF
For a domain that sends only through Zoho Mail, I publish Zoho's documented include in the single SPF record at the root domain. If the domain has other legitimate senders, I merge their mechanisms into the existing record instead of creating another SPF record.
- Inspect the current record: Find every TXT value at the root that begins with v=spf1. The domain must finish with one such record.
- Use Zoho's value: For Zoho Mail on zoho.com, add include:zohomail.com. Zoho documents include:one.zoho.com when several Zoho services send for the same domain. Confirm the value shown for your account and region before publishing.
- Publish one TXT record: Use host @ or the blank root, paste the merged value, save it, and remove duplicate SPF records only after preserving every authorized sender.
- Verify in Zoho: Open Domains, select the domain, open Email Configuration, choose SPF, and click Verify SPF Record. Compare the result with Zoho's SPF guidance.
SPF TXT record for Zoho Mail onlyDNS
v=spf1 include:zohomail.com -all
Run the root domain through the SPF checker after DNS publishes. A valid result still needs review for the ten-lookup limit and for obsolete includes.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
Zoho Mail supports return-path alignment, so a normal Zoho Mail message can pass SPF for DMARC. A separate sender that cannot use your domain in its return path will show SPF alignment errors. That is acceptable only when its DKIM signature passes and its signing domain matches the visible From domain.
Verifying the SPF record in Zoho Mail
Never publish a second SPF record
Two TXT records that begin with v=spf1 cause SPF permerror. I combine all required mechanisms into one record and keep its total DNS-triggering mechanisms at ten or fewer.
Set up DKIM
DKIM must use the selector and public key generated for the exact domain in Zoho. I choose a 2048-bit key when the DNS host accepts its longer TXT value, then verify and enable the selector in Zoho so outbound messages are actually signed.
- Generate the selector: In the Zoho Mail Admin Console, open Domains, select the domain, then choose Email Configuration and DKIM. Click Add.
- Name and size the key: Enter a selector such as zoho, choose 2048 bits when supported, and click Add. Copy the complete TXT name and value that Zoho generates.
- Publish the key: Create a TXT record at zoho._domainkey. Some DNS hosts append the domain automatically, so do not enter the full domain when that would duplicate it.
- Verify and enable: Return to the selector row, click Verify, then enable DKIM when prompted. Verified but disabled selectors do not sign mail. Follow Zoho's DKIM steps if the control labels differ in your account.
DKIM TXT record structureDNS
Host: zoho._domainkey Value: v=DKIM1; k=rsa; p=<Zoho-generated-public-key>
Generating and enabling a Zoho Mail DKIM selector
A DKIM pass that counts
- Signature result: The message header reports DKIM pass.
- Signing domain: The d= domain matches the visible From domain under relaxed or strict rules.
A DKIM setup that still fails
- Selector state: The key is verified in DNS but remains disabled in Zoho.
- Domain mismatch: DKIM passes for a Zoho domain that does not match the visible From domain.
Set up DMARC
Publish one DMARC TXT record at _dmarc after SPF and DKIM are working. I recommend p=none for a new deployment so reports reveal every sender without changing delivery. If the domain already uses p=quarantine or p=reject, keep that enforcement level while fixing Zoho Mail.
- Check for an existing policy: Query _dmarc for TXT records. Edit the existing DMARC record instead of publishing a second one.
- Choose the reporting address: Replace dmarc@example.com with a mailbox or DMARC reporting address you control. Keep the example value only for syntax testing.
- Generate the record: Use the DMARC record generator or enter the record below exactly, with your reporting address substituted.
- Publish and verify: Create a TXT record at _dmarc, save it, then verify that public DNS returns exactly one valid DMARC policy.
Starting DMARC TXT valueDNS
v=DMARC1; p=none; rua=mailto:dmarc@example.com
The checker should return one record, valid syntax, and the intended policy. It cannot prove that Zoho messages pass DMARC, so test real mail after the DNS check.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Zoho's phased guidance moves a domain through none, quarantine, and reject. I keep relaxed SPF and DKIM alignment unless a strict business requirement has been tested against every sender and subdomain. See Zoho's DMARC policy guide for the matching Admin Console controls.
Generating a p=none DMARC record in Zoho Mail
One DMARC record only
Multiple TXT records at _dmarc cause a permanent DMARC error. I merge tags into one policy and verify the published result before relying on it.
Verify and troubleshoot
A DNS record can validate while actual mail still fails authentication. I send a new message through the same Zoho Mail path users will use, then inspect the received headers and DMARC result.
- Send a fresh test: Use the normal Zoho Mail web app or configured client, with the exact From domain being protected. Do not test by forwarding an old message.
- Confirm SPF: Check that SPF passes and that the return-path domain matches the visible From domain under the selected DMARC rules.
- Confirm DKIM: Check that DKIM passes and that its d= domain matches the visible From domain. If no signature exists, enable the verified selector in Zoho.
- Confirm DMARC: The final result must report DMARC pass through SPF or DKIM. Use the DMARC checker to separate DNS syntax faults from message-level failures.
- Account for propagation: If Zoho cannot verify a new record, confirm the authoritative DNS zone and record host, then retry after the TTL expires.
|
|
|
|---|---|---|
SPF permerror | Duplicates or lookup limit | Merge and simplify |
No DKIM | Selector disabled | Verify, then enable |
DKIM fail | Wrong or altered key | Republish full key |
DMARC fail | Identity mismatch | Fix SPF or DKIM |
Fast fault isolation for Zoho Mail authentication
Checking SPF, DKIM, and DMARC results in Zoho Mail
The email tester is the quickest end-to-end check. It asks for a test message and returns a diagnosis of the received SPF, DKIM, DMARC, and message configuration.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Fix message-level failures before increasing the DMARC policy. A passing DNS lookup proves publication, while a passing test message proves the sender used the intended authentication path.
Get alerted when it breaks
Authentication changes after setup when selectors rotate, DNS records are edited, or a new sending source appears. Suped is our DMARC monitoring product and the best overall choice here for ongoing monitoring because it turns aggregate reports into source-level issues, real-time alerts, and exact steps to fix each failure.
- Route reports: Point the DMARC rua tag to the unique reporting address Suped provides, while keeping one DMARC TXT record.
- Verify sources: Mark Zoho Mail and every approved sender as verified, then investigate unrecognized IPs and domains instead of authorizing them automatically.
- Enable alerts: Set notifications for rising DMARC failures and newly observed sources so a broken selector or DNS edit does not wait for a manual review.
- Watch the whole domain: Use Suped's unified DMARC, SPF, DKIM, blocklist (blacklist), and deliverability views to connect an authentication change with reputation symptoms.
A practical monitoring loop
Suped's automated issue detection identifies the failing source, explains whether SPF, DKIM, or DMARC caused it, and gives steps to fix it. The same workflow works across multiple domains, including agency and MSP tenants.
The free plan is useful for a first domain, while hosted SPF can manage authorized senders without repeated DNS edits and SPF flattening keeps complex records under the lookup limit. Suped's DMARC monitoring workflow is the place to review source history before changing policy.
Secure your domain with p=reject
Move to p=reject only after DMARC reports show that every legitimate source passes through matching SPF or DKIM. I treat the change as a controlled rollout, with ownership and rollback criteria recorded before each DNS edit.
- Inventory all senders: Review at least one normal business cycle and include Zoho Mail, transactional systems, support mail, marketing mail, and devices that send directly.
- Fix legitimate failures: Enable matching DKIM wherever available. Use SPF alignment when the sender supports a custom return path. Remove retired senders instead of authorizing them.
- Stage enforcement: Move from p=none to p=quarantine, review impact, then use p=reject. Increase pct in measured steps when the receiving systems you depend on honor it.
- Protect subdomains: Set an explicit sp policy when subdomains need different treatment, and test every active subdomain before rejecting mail.
- Keep monitoring: Use Suped alerts during and after the rollout. A new source or expired DKIM key must be fixed before legitimate messages accumulate under reject.
Ready for p=reject
- Known sources: Every legitimate source has an owner and an approved authentication path.
- Passing traffic: Normal mail passes DMARC consistently, including peak and periodic sends.
Stay at the current policy
- Unknown volume: Unidentified sources still send meaningful legitimate traffic.
- Unstable pass rate: SPF or DKIM failures recur without an alert and ownership process.
Full enforcement DMARC TXT valueDNS
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Suped's hosted DMARC policy staging reduces manual DNS changes and keeps the rollout tied to observed source data. Use hosted DMARC when the team wants controlled policy changes with continuous monitoring.
FAQ
These are the checks I use when a Zoho Mail authentication result remains unclear after the DNS records have been published.
