Use this guide to ensure that your email system is optimized for a seamless integration with Zendesk. By following the best practices outlined in this article, you can enhance the trust level of your email server and minimize the risk of any issues when working with Zendesk.
This article includes the following setup recommendations and best practices:
- Recommendation 1: Setup a PTR record for SMTP servers sending email to Zendesk
- Recommendation 2: Setup HELO and EHLO greeting hostname
- Recommendation 3: SPF records
- Recommendation 4: DMARC and DKIM
- Best practices for sending emails using scripts and web forms
- Best practices for sending trustworthy emails
Recommendation 1: Setup a PTR record for SMTP servers sending email to Zendesk
Ensure that all IP addresses that you use to send emails to Support have a Pointer (PTR) record. PTR records provide extra confidence that the given IP address has a connection to the domain owner. For example, IP address 1.2.3.4 should resolve to mail.domain.com if someone from domain.com sends an email to Support.
Ideally, a PTR record should belong to the same domain that sends emails to Support. It should not contain IP address numbers or keywords that indicate that an IP address belongs to a residential ISP.
Example of the correct record for domain.com:
host 1.2.3.4
Host 4.3.2.1.in-addr.arpa. domain name pointer mail.domain.com
Example of a missing record:
host 1.2.3.4
Host 4.3.2.1.in-addr.arpa. not found: 3(NXDOMAIN)
Example of the record that should not be used to send an email:
host 1.2.3.4
Host 4.3.2.1.in-addr.arpa. domain name pointer 4-3-2-1-cable-subscribers.isp.com
Recommendation 2: Setup HELO and EHLO greeting hostname
HELO name is used by SMTP servers to greet each other. The HELO record being resolvable according to RFC 5321 (§2.3.5), should belong to the domain of the email sender and match with an MX record. Support expects SMTP servers that send emails to Support to have a resolvable HELO hostname.
Example of the correct record for domain.com:
HELO mail.domain.com
Example of HELO greetings that are considered low trust:
HELO mail.otherdomain.com
HELO localhost
HELO 1.2.3.4
HELO invalid.tld
-
HELO not.existing.domain.com
For more information, see this article from Wikipedia: List of SMTP server return codes.
Recommendation 3: SPF records
Domains that send emails to Support should have a valid SPF record that authorizes IP addresses to send emails on behalf of the domain.
Find below two examples of the correct SPF record for the following situation:
domain.com
SMTP servers with address 1.2.3.4
MX record mail.domain.com pointing on 1.2.3.4.
Both examples would enable 1.2.3.4 to send emails on behalf of domain.com.
domain.com. 3600 IN TXT "v=spf1 mx:domain.com ~all”
domain.com. 3600 IN TXT "v=spf1 ip4:1.2.3.4 ~all”
Recommendation 4: DMARC and DKIM
To decrease the number of spoofed emails and spam you receive, add an additional layer of security on your inbound emails by enabling Sender Authentication with SPF, DKIM, and DMARC alignment. For more information, see the article: Authenticating incoming email (SPF, DKIM, DMARC).
Best practices for sending emails using scripts and web forms
Sending emails to Support using web forms or automated scripts is not recommended and is not currently supported. Customers who still want to send these types of emails must follow the rules outlined below.
- All sending web forms should either require authentication or use CAPTCHA, or both. Zendesk can not prevent spam attacks that you are both allowing and encouraging.
- When you send emails to Support using web forms, web applications, or automation scripts, emails should be formatted correctly, in accordance with RFC 5322.
- Messages should contain properly formatted Subject:, From:, To:, and Reply-To: headers.
- Sending IP address should have a PTR record (reverse DNS resolution).
- Support encourages you to add valid SPF records, sign these emails with the DKIM key published on the sending domain DNS zone, and have a DMARC policy published specifying the way emails should be treated.
- The HELO greeting should have a valid resolvable DNS name.
- Forward any email from a web form through an external support address, for the purpose of data redundancy and to decrease the likelihood of suspensions.
- If you are sending to a native Zendesk support address (support@subdomain.zendesk.com) then your form should be able to handle transient network errors and, or
4xx
responses for resiliency. - Do not hardcode an MX relay to any of our MX records. Each relay should perform an MX lookup.
- Do not use the Mark as spam feature for submissions from your web form. This will have a negative impact on your form's sending reputation.
- Zendesk Customer Support does not provide support for your web form's functionality.
Best practices for sending trustworthy emails
Zendesk does not trust:
- Emails that are spoofing the email sender without having an authorizing SPF record published in the domain owner’s DNS zone
- Emails with a spoofed sender address, invalid DKIM signature, or failed SPF check
Note: Zendesk attempts to detect forwarded emails if you are forwarding emails from your domain to a Zendesk support subdomain, for example, support@yourdomain.com >> support@subdomain.zendesk.com. In case Zendesk detects email forwarding, Zendesk undertakes alternative approaches to authenticate the sending SMTP server. However, configure forwarding SMTP server to preserve DKIM signature and not to tamper with the original email body and sensitive headers.
- Emails that use invalid, non-existent, or non-resolvable domain names in the sender and recipient headers of the email
Support exercises a low level of trust towards emails that were sent via an SMTP server with a missing PTR record or an invalid HELO greeting.
0 comments