Workflow: Ensuring email system compatibility with Zendesk

<p>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.</p><p>This article includes the following setup recommendations and best practices:</p><div style="margin-bottom: 20px; text-align: right;">
<button id="master-toggle" class="btn fw-semibold text-dark" data-action="expand" style="background-color: #DEF991; border: none; outline: none; border-radius: 7px; padding: 10px 20px; font-size: 15px; transition: background-color 0.2s ease;" onmouseover="this.style.backgroundColor='#cbef6d'" onmouseout="this.style.backgroundColor='#DEF991'">
Expand all tabs
</button>
</div>
<script>
document.addEventListener('DOMContentLoaded', function () {
const toggleBtn = document.getElementById('master-toggle');

toggleBtn.addEventListener('click', function () {
const action = this.getAttribute('data-action');
const headers = document.querySelectorAll('.accordion');

headers.forEach(header => {
const isActive = header.classList.contains('active');
const panel = header.nextElementSibling; // Grabs the corresponding .panel container

if (action === 'expand' && !isActive) {
// Open it by simulating a standard click
header.click();
} else if (action === 'collapse' && isActive) {
// Close it by simulating a standard click
header.click();
}
});

// Flip button text and states
if (action === 'expand') {
this.setAttribute('data-action', 'collapse');
this.textContent = 'Collapse all tabs';
} else {
this.setAttribute('data-action', 'expand');
this.textContent = 'Expand all tabs';
}
});
});
</script><div class="accordion"><h3 id="h_01ECJJH94SB64MXE9JSP1HQT8K">Recommendation 1: Set up a PTR record for SMTP servers sending email to Zendesk</h3></div><div class="panel">
<p>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.</p>
<p>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.</p>
<p>Example of the correct record for domain.com:</p>
<ul>
<li data-list-item-id="e261ea1299a0746f9bac6bad8558882c4"><code>host 1.2.3.4</code></li>
<li data-list-item-id="e3a461800ba2014718444d96be5f8c73e"><code>Host 4.3.2.1.in-addr.arpa. domain name pointer mail.domain.com</code></li>
</ul>
<p>Example of a missing record:</p>
<ul>
<li data-list-item-id="e5ada14ccbab7c968ad94cc238e85ffab"><code>host 1.2.3.4</code></li>
<li data-list-item-id="ef7baf54128e2fe4e13cfe0059b32c8c0"><code>Host 4.3.2.1.in-addr.arpa. not found: 3(NXDOMAIN)</code></li>
</ul>
<p>Example of the record that should not be used to send an email:</p>
<ul>
<li data-list-item-id="e0860e5e3d79587b80da47b964e75d7a0"><code>host 1.2.3.4</code></li>
<li data-list-item-id="e7200ad9d3c742a819e8205e10efd762c"><code>Host 4.3.2.1.in-addr.arpa. domain name pointer 4-3-2-1-cable-subscribers.isp.com</code></li>
</ul>
</div><div class="accordion"><h3 id="h_01ECJJHEXNKKYH9JSK36GHC7GR">Recommendation 2: Set up HELO and EHLO greeting hostname</h3></div><div class="panel">
<p>HELO name is used by SMTP servers to greet each other. The HELO record being resolvable according to <a href="https://tools.ietf.org/html/rfc5321#section-2.3.5" target="_blank" rel="noopener noreferrer">RFC 5321 (§2.3.5)</a>, 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.</p>
<p>Example of the correct record for domain.com:</p>
<ul><li data-list-item-id="e61efe1792cdf1d8a82dceb1f62f771dd"><code>HELO mail.domain.com</code></li></ul>
<p>Example of HELO greetings that are considered low trust:</p>
<ul>
<li data-list-item-id="e3b58af0980b74609941e084c33c057f3"><code>HELO mail.otherdomain.com</code></li>
<li data-list-item-id="ee481a4af35ff59993f94cc6c130902b0"><code>HELO localhost</code></li>
<li data-list-item-id="e9d9a948582e4afa6373f513e8bb2d898"><code>HELO 1.2.3.4</code></li>
<li data-list-item-id="e0772d468894002bcddc23a005ff5ed59"><code>HELO invalid.tld</code></li>
<li data-list-item-id="ee8969574e2cc788945743177d358729c">
<code>HELO not.existing.domain.com</code><br>For more information, see <a href="https://en.wikipedia.org/wiki/List_of_SMTP_server_return_codes#4xx_Persistent_transient_failure" target="_blank" rel="noopener noreferrer">List of SMTP server return codes</a> from Wikipedia.</li>
</ul>
</div><div class="accordion"><h3 id="h_01ECJJHM6VTZDPG6QBA4CFV370">Recommendation 3: SPF records</h3></div><div class="panel">
<p>Domains that send emails to Support should have a valid SPF record that authorizes IP addresses to send emails on behalf of the domain.</p>
<p>Find below two examples of the correct SPF record for the following situation:</p>
<ul>
<li data-list-item-id="e9b73f84333e35c5e76a15d469098c2ea"><code>domain.com</code></li>
<li data-list-item-id="eb52061a8879e12599fb185c4beb05eed"><code>SMTP servers with address 1.2.3.4</code></li>
<li data-list-item-id="e39149d1381b5ca6176e057492e900fa4"><code>MX record mail.domain.com pointing on 1.2.3.4.</code></li>
</ul>
<p>Both examples would enable 1.2.3.4 to send emails on behalf of domain.com.</p>
<ul>
<li data-list-item-id="e7723338b30755d9c75ca44eceb802a51"><code>domain.com. 3600 IN TXT "v=spf1 mx:domain.com ~all”</code></li>
<li data-list-item-id="ebd6453561fd8c6ff165b6e284e62b8e3"><code>domain.com. 3600 IN TXT "v=spf1 ip4:1.2.3.4 ~all”</code></li>
</ul>
</div><div class="accordion"><h3 id="h_01KSHEGZA9GAPBY8X79ZPE4AG7">Recommendation 4: SPF, DKIM, DMARC, and ARC</h3></div><div class="panel"><p>To decrease the number of spoofed emails and spam you may receive, add an additional layer of security on your inbound emails by enabling Sender Authentication with SPF, DKIM, DMARC, and ARC. For more information, see <a href="https://support.zendesk.com/hc/en-us/articles/4408821985818-Authenticating-incoming-email-SPF-DKIM-DMARC-and-ARC" target="_blank" rel="noopener noreferrer">Authenticating incoming email (SPF, DKIM, DMARC, and ARC)</a>.</p></div><div class="accordion"><h3 id="01K3NVV7A9DMJ2AM1DCXXP3NHD">Recommendation 5: Adding ARC Headers</h3></div><div class="panel"><p>For accounts forwarding traffic to Zendesk we recommend adding <a href="https://www.valimail.com/blog/what-is-email-arc/" target="_blank" rel="noopener noreferrer">ARC headers</a> so that we can incorporate your auth evaluation of the traffic when it arrived at your forwarding servers.</p></div><div class="accordion"><h3 id="h_01ECJJJ3A4EG1ZYVTQVK3Z6FDM">Best practices for sending emails using scripts and web forms</h3></div><div class="panel">
<p>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.</p>
<ul>
<li data-list-item-id="ed5c35d64e16cb7c5e16d08723b7c9c8f">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.</li>
<li data-list-item-id="ebf3ca96ce1a8d940d407a1b9e7faf0cd">When you send emails to Support using web forms, web applications, or automation scripts, emails should be formatted correctly, in accordance with <a href="https://tools.ietf.org/html/rfc5322" target="_blank" rel="noopener noreferrer">RFC 5322</a>.</li>
<li data-list-item-id="e865b29389a7b8d8d46435518e0fe7ec9">Messages should contain properly formatted <strong>Subject:</strong>, <strong>From:</strong>, <strong>To:</strong>, and <strong>Reply-To:</strong> headers.</li>
<li data-list-item-id="e12d7dd137146087b023f0b3ac7a4d8dc">Sending IP address should have a PTR record (reverse DNS resolution).</li>
<li data-list-item-id="e4d8f47cae1769a9b75f24ae4d690c761">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.</li>
<li data-list-item-id="eb90b1dfee95f3f6d8569d0a03655a5ab">The HELO greeting should have a valid resolvable DNS name</li>
<li data-list-item-id="e56bc4ddb42ea9bd651edc212a0c54d82">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 or dropped traffic</li>
<li data-list-item-id="e16bf5af6b21963b623ec150b1c43c4ed">If you are sending to a native Zendesk support address (support@<em>yoursubdomain</em>.zendesk.com) then your form should be able to handle transient network errors and, or <code>4xx</code> responses for resiliency</li>
<li data-list-item-id="ec4fa5e109a045764ce61973194e0b6ae">Do not hardcode an MX relay to any of our MX records. Each relay should perform an MX lookup</li>
<li data-list-item-id="eaff66d694dba301ea144b98966c4b46e">Do not use the <a href="https://support.zendesk.com/hc/en-us/articles/4408842999066" target="_blank" rel="noopener noreferrer"><strong>Mark as spam</strong></a> feature for submissions from your web form. This will have a negative impact on your form's sending reputation</li>
<li data-list-item-id="e1188371a861979d98a880a42bebce5b4">Zendesk Customer Support does not provide support for your web form's functionality</li>
</ul>
</div><div class="accordion"><h3 id="h_01ECJJJ9NV3N4PQSPJF11Q4VQS">Best practices for sending trustworthy emails</h3></div><div class="panel">
<p>Zendesk does not trust:</p>
<ul>
<li data-list-item-id="eb2c5b12cfaa15efe75a7b00d84ecda05">Emails that are spoofing the email sender without having an authorizing SPF record published in the domain owner’s DNS zone</li>
<li data-list-item-id="e3d8ce4b3d32d26389a73098b112e9318">
<p>Emails with a spoofed sender address, invalid or unaligned DKIM signature, or failed SPF check</p>
<div class="note">
<span class="notetitle">Note:</span> Zendesk attempts to detect forwarded emails if you are forwarding emails from your domain to a Zendesk support subdomain, for example, support@yourdomain.com &gt;&gt; support@<em>yoursubdomain</em>.zendesk.com. In the event that Zendesk detects email forwarding, Zendesk undertakes alternative approaches to authenticate the sending SMTP server. However, try to configure the forwarding server to preserve the DKIM signature and not to tamper with the original email body and sensitive headers, as this can cause failure. Also, try to utilize ARC headers whenever possible.</div>
</li>
<li data-list-item-id="ec22c381cdcadb3c68d167ba506a85f56">Emails that use invalid, non-existent, or non-resolvable domain names in the sender and recipient headers of the email are likely to be suspended or rejected.</li>
</ul>
<p>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.</p>
</div>