Skip to main content
Sign in
Español (España)
MAIN MENU

Best practices to ensure email systems work with MorgWard Support

Morgs

Suite allall plans

At MorgWard, we strive to keep your inbox free of spam, but we need your help to 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 these sections:

PTR record for SMTP servers sending email to MorgWard Support

Ensure that all IP addresses that you use to send email to MorgWard 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 email to Support. 

Ideally, a PTR record should belong to the same domain that sends email 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 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), it should belong to the domain of email sender and match with an MX record. Support expects SMTP servers that send email 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: 

SPF records 

Domains that send email to Support should have a valid SPF record that authorizes IP addresses to send email on behalf of the domain.

Here are 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, you can add an additional layer of security on your inbound emails by enabling Sender Authentication with SPF, DKIM, and DMARC alignment. See 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 valid resolvable DNS name.
  • We recommend that you 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 MorgWard support address (support@subdomain.zendesk.com) then we recommend that 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. 
  • We do not provide support for your web form's functionality.  

Emails that Support does not trust

Support 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 a SMTP server with a missing PTR record or an invalid HELO greeting.

* We attempt to detect forwarded emails if you are forwarding emails from your domain to a MorgWard support subdomain, e.g. support@yourdomain.com >> support@subdomain.zendesk.com. In case we have detected email forwarding we will undertake alternative approach to authenticate the sending SMTP server. However forwarding SMTP server should be configured to preserve DKIM signature and not to tamper with the original email body and sensitive headers.

Comments

0 comments

Please sign in to leave a comment.

Powered by Zendesk