Invitation Email Delivery and Troubleshooting | Zoho Vertical Studio Help

Invitation Email Delivery and Troubleshooting

Invitation emails for your Vertical Studio application are sent from the address configured in App Details > System Notification Emails > Customer Communications. If you do not configure a Customer Communications address, Vertical Studio sends invitations from the primary contact email address of your developer account instead. This affects how subscribers identify the sender and whether receiving mail servers trust the message.
Email authentication helps you prove that invitation emails are sent from a domain you control. A properly configured domain improves deliverability, reduces spam filtering, and helps subscribers receive invitations without delay.

Before you begin

Keep these requirements in mind before you configure email authentication:

Standard

Requirement

Purpose

Domain verification

Required

Confirms that you own the sending domain.

DKIM, DomainKeys Identified Mail

Required

Signs each email so the receiving server can verify the sender and message integrity.

SPF, Sender Policy Framework

Recommended

Identifies which mail servers are allowed to send email for your domain.

DMARC, Domain-based Message Authentication, Reporting and Conformance

Recommended

Tells receiving servers how to handle messages that fail authentication. Google and Yahoo require at least p=none.


Notes
You can save a public email domain such as Gmail, Yahoo, or Outlook as your Customer Communications address, but you cannot authenticate it. You cannot configure DKIM for a domain you do not own, so invitations sent from these domains never carry a DKIM signature and are more likely to be filtered.

How the standards work 

Standard

What it does

Domain verification

Confirms that you own the domain from which emails are sent.

DKIM

Uses public-key cryptography to sign each email so the receiving server can verify that the message was sent from your domain and was not altered in transit.

SPF

Identifies the mail servers that are allowed to send email on behalf of your domain, which helps prevent spoofing and reduces the chance of spam filtering.

DMARC

Builds on DKIM and SPF by adding identity alignment, policy definition, and reporting. It tells receiving servers how to handle emails that fail authentication.


Configure the sender address

Set this address first so invitation emails come from your application instead of your developer-account contact address.
  1. Sign in to your Developer Console.
  2. Navigate to App Details > System Notification Emails > Customer Communications.
  3. Add the email address you want to use for invitation emails.
  4. Verify the address if prompted.
Until the address is verified, App Details shows Update Requested. If the verification email is not delivered to your inbox, click Resend Mail.

Authenticate the domain

After you configure the sender address, authenticate that domain so invitation emails can pass sender checks. Use the Email Authentication page to add the domain and verify ownership.
  1. Sign in to your Vertical Studio developer edition at https://platform.zoho.com/crm/.
  2. Navigate to Setup > Channels > Email > Email Deliverability > Email Authentication.
  3. Check whether the domain is already listed and whether its authentication records show the expected status.
  4. Click Add Domain if the domain is not already listed.

  5. Enter the email address that uses the domain you want to authenticate. Use your Customer Communications address when possible.
  6. Click Add Domain.
  7. Wait for the verification code to be sent to that address.
  8. Open the verification email.
  9. Copy the verification code.
  10. Return to Email Authentication and click Enter Code for the domain.
  11. Enter the code, then click Verify.
Confirm that the domain is now listed and verified on the Email Authentication page.
Info
Please note that the verification email stays valid for 15 days. If it expires, or if you do not receive it, click Resend Mail and check the Spam or Junk folder.
Repeat these steps for each domain or subdomain your application uses to send invitation emails.

Retrieve your DNS records

Retrieve these values from Vertical Studio because they contain the exact DKIM and SPF records (DNS records) your domain must publish for email authentication to work correctly.
  1. Open Email Authentication.
  2. Locate the verified domain.
  3. Click
    Validate Records.

  4. Copy the DKIM hostname and DKIM value. Together, these make up the DKIM TXT record you must add to your DNS.
  5. Copy the SPF value if you want to publish SPF. This is the SPF TXT record value you must add to your DNS.
  6. Keep the popup open while you add these DNS records to your domain provider so you can copy the values exactly. Copy the record values exactly as they appear in your account. The DKIM key is unique to your domain.

Add the DKIM record to your DNS

DKIM is required because it lets receiving mail servers verify that invitation emails were sent from your domain.
  1. Sign in to your domain provider's DNS management portal.
  2. Create a new TXT record.
  3. Enter the DKIM hostname in the host or name field.
  4. Paste the full DKIM value into the value field.
  5. Keep the default TTL unless your provider requires a different value.
  6. Save the record.
  1. Use only the hostname shown in Vertical Studio, for example 2232._domainkey, unless your DNS provider specifically requires the full domain name. Some providers append the domain automatically, which can create an invalid host.
  2. Copy the full DKIM value without adding spaces or line breaks. If your DNS provider requires the full host name, add a trailing dot to prevent the domain from being appended twice.

 

Check

What to confirm

Host name

Use only the hostname shown in Vertical Studio unless your DNS provider requires the full host.

Auto-appended domain

Avoid duplicate host names such as 2232._domainkey.example.com.example.com.

Record value

Copy the full DKIM value without spaces or line breaks.

Domain-specific key

Use the DKIM value generated for the same domain.


Add or update the SPF record

SPF is optional, but it adds another sender-validation layer that can improve delivery.
  1. Open your DNS management portal.  For example, if your domain is registered with GoDaddy, open the DNS page for that domain in your GoDaddy account.
  2. Check whether a TXT record beginning with v=spf1 already exists for the same domain used by your Customer Communications email address. The value v=spf1 identifies the TXT record as an SPF policy.
  3. If no TXT record beginning with v=spf1 exists for that domain, create a new SPF TXT record. If one already exists, edit the existing record instead.
  4. Copy the SPF value shown in Validate Records, then add the Zoho include value from that SPF entry to the SPF TXT record for that domain.
  5. Save the record.
  1. Use only one SPF record for a domain. Multiple SPF records can cause validation failures.
  2. Without SPF, some receiving mail servers may apply additional spam checks, which can increase the chance that an invitation is delivered to Spam or Junk.

Check

What to confirm

Existing SPF record

Edit the current SPF TXT record instead of creating a second one.

DNS lookup limit

Keep the total SPF DNS lookups within the supported limit of 10.

Data center value

Use the SPF value shown in your account, because it can vary by data center.

Verified status

The sender address shows as Verified only after domain verification, DKIM, and SPF all pass.


Add a DMARC record

DMARC tells receiving mail servers how to handle messages that fail authentication checks.
  1. Open your DNS management portal.
  2. Check whether a TXT record already exists at _dmarc.yourdomain.com.
  3. Edit the existing DMARC record if one is already present.
  4. Create a new TXT record only if none exists.
  5. Enter _dmarc in the host or name field.
  6. Enter a DMARC policy such as v=DMARC1; p=none; rua=mailto:reports@yourdomain.com.
  7. Save the record.
Notes
If your domain does not already use DMARC, start with p=none. This meets the minimum sender-policy requirement used by Google and Yahoo while you monitor delivery results. If your domain already has a quarantine or reject policy, keep that policy and make sure DKIM is authenticated.

 

Tag

Description

v=DMARC1

Identifies the record as a DMARC record. This tag is required.

p

Defines the policy for messages that fail authentication, such as none, quarantine, or reject.

rua

Identifies the email address that receives aggregate DMARC reports.

pct

Defines the percentage of emails to which the policy applies. The default is 100.


Check DMARC status

Review this status in Vertical Studio to confirm whether the domain already publishes a DMARC policy. Vertical Studio checks the DMARC policy for each domain automatically in Email Authentication:

Status

Meaning

DMARC set

A DMARC policy is published for the domain. Hover over the label to see whether the policy is none, quarantine, or reject.

No DMARC

No DMARC policy is published for the domain.



Review authentication status

After you add the DNS records, review the domain again in Email Authentication to confirm that each authentication method shows the expected result.

Check

What to look for

Domain verification

Confirm that the domain is added and verified. If it is not listed, add it and complete verification.

DKIM

Open the domain in Email Authentication and use Validate Records to check the DKIM result. Confirm that the DKIM record validates successfully for the domain. If it does not, complete the steps in Add the DKIM record to your DNS.

SPF

Open the domain in Email Authentication and use Validate Records to check the SPF result if you want stronger sender validation. Confirm that the SPF record validates successfully for the domain. If it does not, complete the steps in Add or update the SPF record.

DMARC

Check the DMARC status shown for the domain on the Email Authentication page. Confirm whether the domain shows DMARC set or No DMARC. If the domain shows No DMARC, complete the steps in Add a DMARC record.


Common issues and fixes

Case 1: The subscriber does not recognize the sender

This usually happens when your application does not have a Customer Communications address. Vertical Studio then sends the invitation from the primary contact email address of your developer account.
The invitation is sent from your developer account email instead of your application support address. Depending on whether that sender domain is authenticated and how the recipient mailbox is configured, the message may reach the inbox, Spam, or quarantine. Even when it is delivered, the subscriber may not associate the sender with your business or application and may ignore or delete the invitation.
Solution:
  1. Open App Details > System Notification Emails > Customer Communications in the Developer Console.
  2. Add an email address on a custom domain you control.
  3. Verify the address. If App Details shows Update Requested, click Resend Mail if needed.
  4. Complete domain verification and DKIM setup for that domain.

Case 2: The subscriber does not receive the invitation because DKIM is missing or invalid

Invitation emails need both domain verification and DKIM to count as authenticated. If the domain is unverified, if the DKIM record is missing, or if the record is published incorrectly, receiving servers may place the invitation in spam, quarantine it, or reject it.
Common causes:
  1. The DKIM TXT record was never added, so the message is sent without a valid DKIM signature.
  2. The host name includes the domain twice, for example 2232._domainkey.example.com.example.com, so the DNS record does not resolve correctly.
  3. The DKIM value was copied incompletely or with extra spaces or line breaks, so the signature cannot be validated.
  4. The domain was added in Vertical Studio, but the verification code was never entered, so the domain does not complete authentication.
When this happens, the invitation is sent from your Customer Communications address without a valid DKIM signature. Receiving systems may send it to Spam, move it to quarantine, or reject it entirely, which means the subscriber may never see the invitation.
Solution
  1. Verify the domain in Email Authentication.
  2. Click Validate Records and copy the DKIM hostname and value again.
  3. Compare the DNS record in your provider portal with the value shown in Vertical Studio.
  4. Remove extra spaces, line breaks, or duplicate domain text in the host name.
  5. Save the corrected TXT record.
  6. Return to Email Authentication and validate the domain again after DNS propagation.

Case 3: SPF is not configured

SPF is optional for sending invitation emails, but it improves trust with receiving mail servers. Some providers apply stricter spam checks when SPF is missing, even if DKIM is present.
If SPF is not configured, the invitation is sent without SPF support for the sender domain. Depending on the recipient provider and its filtering rules, the message may land in the inbox, Spam, or Junk. As a result, the subscriber may receive the invitation in a filtered folder instead of the inbox.
Solution:
  1. Open Validate Records for the verified domain.
  2. Copy the SPF value shown there.
  3. Check whether your domain already has an SPF TXT record.
  4. Add the Zoho include value to the existing record, or create one if none exists.
  5. Save the record.

Case 4: Gmail or Yahoo filters the invitation because DMARC is missing

Some email providers apply stricter checks when a domain has no DMARC record. This is especially common with Gmail and Yahoo.
DMARC requires either DKIM or SPF to pass and align with the From domain. Once DKIM authentication is complete, the domain meets the alignment requirement for DMARC.
Common causes:
  1. No DMARC record exists for the domain, so strict mailbox providers may treat the sender as less trustworthy.
  2. The DMARC record was added to the wrong host, so receiving servers cannot find the policy.
  3. More than one DMARC record exists for the same domain, so the published policy becomes invalid.
  4. When this happens, the invitation is sent from your authenticated domain, but the domain has no usable DMARC policy. Strict mailbox providers may send the message to Spam, move it to quarantine, or reject it, so the subscriber may not find the invitation in the inbox.
Solution:
  1. Check whether a TXT record exists at _dmarc.yourdomain.com.
  2. Edit the existing DMARC record if one already exists.
  3. Create a new record only if none exists.
  4. Publish a policy with at least p=none.
  5. Confirm that DKIM or SPF passes and aligns with the From domain.
Notes
Note: DMARC is mandatory for domains that send more than 5,000 emails per day.

Case 5: The subscriber's organization quarantines the invitation

Even when your domain is authenticated, a subscriber organization may quarantine messages from a new sender because of its internal mail gateway policy.
When this happens, the invitation is held by the subscriber organization's email gateway and does not reach the subscriber's inbox. The message remains in quarantine until the organization's IT team releases it or allowlists the sender.
Solution:
  1. Ask the subscriber to contact their IT administrator.
  2. Ask the IT team to check email gateway and quarantine logs.
  3. Ask the IT team to allowlist your Customer Communications email address or sending domain.
  4. Ask the IT team to confirm that their security policies permit emails from your sender domain.
  5. Resend the invitation after the allowlist is updated.

Case 6: Email security software on the subscriber side blocks the invitation

Security tools on the subscriber side can move messages to Junk, Spam, or a local quarantine even when the sending domain is authenticated.
Common examples include Microsoft Defender for Office 365, Google Workspace spam filtering, Proofpoint, Mimecast, Barracuda, Cisco Secure Email, Fortinet FortiMail, Sophos, and Trend Micro.
When this happens, the invitation is intercepted by email security software on the subscriber side and may be moved to Junk, Spam, or a local quarantine managed by the software or the subscriber organization. The subscriber does not see the invitation until the sender is marked safe or the message is released.
Solution:
If the software is managed by the subscriber organization:
  1. Ask the subscriber to contact their IT administrator.
  2. Ask the IT team to check gateway and quarantine logs for the invitation.
  3. Ask the IT team to allowlist your Customer Communications email address or sending domain.
  4. Resend the invitation after the block is removed.
If the software is managed by the subscriber:
  1. Ask the subscriber to check Junk, Spam, Promotions, and Quarantine folders.
  2. Ask the subscriber to mark the invitation as safe if it is found.
  3. Ask the subscriber to add your sender address or domain to their safe sender list.
  4. Ask the subscriber to check whether local antivirus or email security software blocked or moved the email.
  5. Resend the invitation after the block is removed.
If you are onboarding many subscribers from the same organization, contact their IT team before you send invitations.

Add records in common DNS providers

Use these examples if you need a quick reference for where common DNS providers place TXT records.
The steps vary by provider, but the record type is the same.

GoDaddy

  1. Sign in to your GoDaddy account.
  2. Open My Products.
  3. Click DNS next to your domain.
  4. Click Add New Record and select TXT.
  5. Enter @ for SPF, or enter the DKIM hostname for DKIM.
  6. Paste the corresponding value.
  7. Click Save.

Cloudflare

  1. Sign in to your Cloudflare account.
  2. Select the domain.
  3. Open DNS.
  4. Click Add record and select TXT.
  5. Enter @ for SPF, or enter the DKIM hostname for DKIM.
  6. Paste the corresponding value into Content.
  7. Click Save.

Namecheap

  1. Sign in to your Namecheap account.
  2. Open Domain List.
  3. Click Manage next to your domain.
  4. Open Advanced DNS.
  5. Click Add New Record and select TXT Record.
  6. Enter @ for SPF, or enter the DKIM hostname for DKIM.
  7. Paste the corresponding value.
  8. Click Save all changes.
For step-by-step instructions for other DNS providers, such as Bluehost, HostGator, Wix, Squarespace, Network Solutions, and WordPress, refer to your provider's DNS help documentation.

Checklist

Use this checklist before you send invitations and when you troubleshoot delivery issues.
Before you send invitations:
  1. Configure a Customer Communications address so invitations do not fall back to your developer-account contact address.
  2. Confirm that the subscriber email address is entered correctly.
  3. Use a custom-domain address, not a public email address.
  4. Verify the sender domain in Email Authentication.
  5. Publish the full DKIM record with the correct host value.
  6. Publish the SPF record if you want stronger sender validation.
  7. Publish a DMARC record with at least p=none.
  8. Validate the records after DNS propagation.
  9. Send a test invitation and confirm that DKIM and DMARC show PASS before you start a larger rollout.
  10. Ask enterprise subscriber organizations to allowlist your sender if needed.
If a subscriber does not receive the invitation:
  1. Ask the subscriber to check Spam, Junk, Promotions, and Quarantine.
  2. Verify the recipient email address and resend the invitation.
  3. Confirm that DKIM validation passes for the sender domain.
  4. Confirm that the domain has a DMARC record.
  5. Ask the subscriber to check mailbox rules, forwarding rules, and email security software.
  6. Ask the subscriber organization's IT team to review quarantine logs when needed.