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.
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:
- Open App Details > System Notification Emails > Customer Communications in the Developer Console.
- Add an email address on a custom domain you control.
- Verify the address. If App Details shows Update Requested, click Resend Mail if needed.
- 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:
- The DKIM TXT record was never added, so the message is sent without a valid DKIM signature.
- The host name includes the domain twice, for example 2232._domainkey.example.com.example.com, so the DNS record does not resolve correctly.
- The DKIM value was copied incompletely or with extra spaces or line breaks, so the signature cannot be validated.
- 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
- Verify the domain in Email Authentication.
- Click Validate Records and copy the DKIM hostname and value again.
- Compare the DNS record in your provider portal with the value shown in Vertical Studio.
- Remove extra spaces, line breaks, or duplicate domain text in the host name.
- Save the corrected TXT record.
- Return to Email Authentication and validate the domain again after DNS propagation.
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:
- Open Validate Records for the verified domain.
- Copy the SPF value shown there.
- Check whether your domain already has an SPF TXT record.
- Add the Zoho include value to the existing record, or create one if none exists.
- 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:
- No DMARC record exists for the domain, so strict mailbox providers may treat the sender as less trustworthy.
- The DMARC record was added to the wrong host, so receiving servers cannot find the policy.
- More than one DMARC record exists for the same domain, so the published policy becomes invalid.
- 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:
- Check whether a TXT record exists at _dmarc.yourdomain.com.
- Edit the existing DMARC record if one already exists.
- Create a new record only if none exists.
- Publish a policy with at least p=none.
- Confirm that DKIM or SPF passes and aligns with the From domain.
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:
- Ask the subscriber to contact their IT administrator.
- Ask the IT team to check email gateway and quarantine logs.
- Ask the IT team to allowlist your Customer Communications email address or sending domain.
- Ask the IT team to confirm that their security policies permit emails from your sender domain.
- 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:
- Ask the subscriber to contact their IT administrator.
- Ask the IT team to check gateway and quarantine logs for the invitation.
- Ask the IT team to allowlist your Customer Communications email address or sending domain.
- Resend the invitation after the block is removed.
If the software is managed by the subscriber:
- Ask the subscriber to check Junk, Spam, Promotions, and Quarantine folders.
- Ask the subscriber to mark the invitation as safe if it is found.
- Ask the subscriber to add your sender address or domain to their safe sender list.
- Ask the subscriber to check whether local antivirus or email security software blocked or moved the email.
- 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
- Sign in to your GoDaddy account.
- Open My Products.
- Click DNS next to your domain.
- Click Add New Record and select TXT.
- Enter @ for SPF, or enter the DKIM hostname for DKIM.
- Paste the corresponding value.
- Click Save.
Cloudflare
- Sign in to your Cloudflare account.
- Select the domain.
- Open DNS.
- Click Add record and select TXT.
- Enter @ for SPF, or enter the DKIM hostname for DKIM.
- Paste the corresponding value into Content.
- Click Save.
Namecheap
- Sign in to your Namecheap account.
- Open Domain List.
- Click Manage next to your domain.
- Open Advanced DNS.
- Click Add New Record and select TXT Record.
- Enter @ for SPF, or enter the DKIM hostname for DKIM.
- Paste the corresponding value.
- 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:
- Configure a Customer Communications address so invitations do not fall back to your developer-account contact address.
- Confirm that the subscriber email address is entered correctly.
- Use a custom-domain address, not a public email address.
- Verify the sender domain in Email Authentication.
- Publish the full DKIM record with the correct host value.
- Publish the SPF record if you want stronger sender validation.
- Publish a DMARC record with at least p=none.
- Validate the records after DNS propagation.
- Send a test invitation and confirm that DKIM and DMARC show PASS before you start a larger rollout.
- Ask enterprise subscriber organizations to allowlist your sender if needed.
If a subscriber does not receive the invitation:
- Ask the subscriber to check Spam, Junk, Promotions, and Quarantine.
- Verify the recipient email address and resend the invitation.
- Confirm that DKIM validation passes for the sender domain.
- Confirm that the domain has a DMARC record.
- Ask the subscriber to check mailbox rules, forwarding rules, and email security software.
- Ask the subscriber organization's IT team to review quarantine logs when needed.