Ensuring Email Delivery

Steps to ensure emails from GraspDATA are delivered to recipients.

Quick Instructions

To ensure that emails sent from GraspDATA are delivered to recipients and not bounced, instruct your IT department to authorize the following Grasp email/SMTP servers to send on behalf of your domain @mycompany.com:

  • grasp.smtp.com
  • o1.relay.grasptech.com

Additional Information and Options

In products like GraspDATA or GraspAGENT, Grasp is sending email on behalf of your company’s domain. For example, If your name is John and you work for Easy Travel 123 and your email address is john@easytravel123.com and you are trying to send reports to Bob with email bob@mycompany.com, then when Grasp sends email on your behalf, we will be using john@easytravel123.com as the 'from' address on the email. This has advantages like white labeling Grasp products so they appear to be your products and allowing your clients to simply hit 'reply' and send an email directly back to john@easytravel123.com. 

A problem can occur though because Grasp is not actually an authorized sender for your domain @easytravel123.com. In our example, we sent an email with a 'from' address of john@easytravel123.com and a 'to' address of bob@mycompany.com. The first step that occurs in the emailing process is that Bob’s mail server is going to look at the email Grasp sent on your behalf and see if it actually came from a mail server authorized to send on behalf of your domain @easytravel123.com. Bob’s mail server may notice the email did NOT come from any mail server associated with Easy Travel 123, but rather from a server associated with Grasp. At this point, the reaction of Bob’s mail server will vary – his server may allow it to pass-through or it may be rejected as SPAM and never make it to Bob’s inbox. Keep in mind that the reaction of every client’s mail server is going to be different – the vast majority of client’s mail servers will allow the email to pass through, but others will simply mark it as SPAM and drop or bounce the message and Bob will not receive the message.

The solution is we need to tell the world that Grasp is allowed to send email on behalf of @easytravel123.com. There are several ways this can be achieved:

  1. Change the 'From' address: Any email you send out of a Grasp product will have to use noreply@grasptech.com in the 'From' line of the email.
    1. The downside here is that you lose the white labeling effect which may be OK for internal emails sent between two @easytravel123.com employees. For your clients though, they will see the email is coming from GRASP and not from john@easytravel123.com
  2. Use YOUR mail server: If you create a login for Grasp to your mail Server/SMTP, Grasp can connect to it and route all email you produce in Grasp through your mail server. This will allow your clients’ mail servers to see that the email truly came from your mail server and not Grasp.
    1. In this solution, SMTP BASIC authentication MUST be turned ON because Grasp’s emailing code needs to authenticate with the server before sending.
    2. The IP for the Grasp server will be 64.79.86.130 (if you are on a dedicated server, this will be different - please contact support@grasptech.com). You can use this IP to lock down your internal firewalls as needed as well.
  3. SPF: The last solution involves configuring the 'Sender Policy Framework' or SPF record in your Domain Name Server or DNS settings. You will need to update or add a DNS SPF record (it is a TXT type record) to include the GRASP mail server/smtp server. Here is what you should set your SPF entry to (bold part is Grasp):

v=spf1 +a +mx +ip4:<ip of your mail server here> +ip4:<ip for second mail server and so forth> include:o1.relay.grasptech.com include:graspspf.smtp.com ~all

    1. You can ensure your SPF is set up correctly by visiting http://www.kitterman.com/spf/validate.html which provides many tools to test and validate SPF setup scenarios.
    2. Please email support@grasptech.com and note which method you implemented. This will allow Grasp then to test the new settings and ensure email pass-through works correctly moving forward.