What are the best practices to ensure email systems work within Support?

Question

How can I ensure that my email system works well with Zendesk?

Answer

Zendesk strives to keep your inbox free of spam, but there are certain measures you can do to help secure the channels you use to interact with customers. This article provides an overview of how to increase the trust level of your email server.

This article includes the following sections:

• PTR record for SMTP servers sending email to Zendesk
• HELO and EHLO greeting hostname
• SPF records
• DMARC and DKIM
• Sending emails using scripts and web forms
• Emails that Zendesk does not trust

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 

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.

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” 

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). 

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. We 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 ([e-mail]) 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.  

Emails that Zendesk does not trust

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.*
• 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.

*Zendesk attempts to detect forwarded emails if you are forwarding emails from your domain to a Zendesk support subdomain, for example, [e-mail] >> [e-mail]. 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.