StoneShot Learning > Getting Started > Sender Authentication

Sender Authentication

Sender Authentication

In order to send emails on your behalf, we need to setup email sender authentication. We also need a domain to host your images and for the tracked links within your emails. Let’s go over the domain first.

Tracking domain

When you send an email from the StoneShot Platform, we convert any links so we can measure engagement. Rather than using a StoneShot domain name, it’s better for branding and authenticity to use your own.

You could buy a new domain for email tracking, but it’s far better using your corporate domain. We recommend a sub domain such as marketing.yourcompany.com.

When the domain setup, we’ll set up your sender authentication. Email authentication confirms an email is legitimate by verifying the identity of the sender. Email providers like Gmail and Hotmail, and corporate email servers use email authentication to control spam and phishing.

If your emails look at all suspicious, they go through an assault course of spam filters, content checks and more before they have a chance of hitting the recipients mailbox, or they could simply get deleted. Authenticating does not mean that every single email will get through, but it greatly increases your odds.

Sender Policy Framework (SPF)

When an ESP or corporate gateway receives an email from someone@example.com, the ESP/corporate gateway checks the SPF record. If the IP matches what is in your Domain Name Service (DNS), you are good to go and your email will reach it’s recipient. If not, the email could be filtered or deleted.

Here is an example SPF record. Here we are allowing any mail servers at example.com or stoneshot.com to send email from the domain.

Here is another example with specific IP addresses defined. Note the difference with the “all” statement at the end. “~all” (tilde) is a soft fail which means SPF won’t be strictly enforced and “-all” (dash) is a hard fail meaning emails will get rejected if they don’t match the domains/IPs in your SPF record. We do not recommend “-all” as not everyone uses SPF.

Implementing SPF on a domain involves creating a TXT record in the domain’s DNS which would be: v=spf1 include:stoneshot.com -all

We would recommend that this be set up both on the subdomain (mail-yourcompany.com) but also the top level domain (@yourcompany.com) which will allow emails to be sent on behalf of individual sales people to their clients.

Sender Policy Framework (SPF) and Sender ID

SPF and Sender ID are both IP authentication methods, but they are different (more on that shortly). When an ISP or corporate gateway receives an email from someone@example.com, the ISP/corporate checks the SPF (or Sender ID) record at example.com. If the IP matches what is in your DNS, we are good to go. If not, the email could be filtered or deleted. Here’s an example SPF record.

Here we’re allowing any mail servers at example.com or stoneshot.com to send email from the domain.

Here’s another example with specific IP addresses defined.

Implementing SPF on a domain involves creating a TXT record in the domain’s DNS. Confusingly, you need to ignore the SPF record type as it’s obsolete. SPF and Sender ID are two different standards (see http://www.openspf.org/SPF_vs_Sender_ID for a full explanation) and you can ignore the Sender ID spec as it’s not been widely adopted.

Here’s a graphic that shows the authentication in action.

StoneShot itself has the following SPF setup:

The above SPF entry shows three separate ‘include’ entries which is for management purposes. Each ‘include’ is recursively evaluated to determine the IPs allowed for sending. Rather than listing IPs (below) where any change to an IP would require the SPF record to be updated to reflect the change.

An ‘include’ reference does not require the SPF record to be changed, as it only references the domains DNS. So, any changes are automatically reflected due to the recursive nature of DNS.

What do I need to change?

If you do not already have a SPF record you will need to create a TXT entry with the following:

If you already have an existing SPF record all you need to do is add the following into the existing record. For example, your record may be like the following:

Add an additional entry “include:stoneshot.com” into the record:

Testing and Checking

A list of useful sites for testing and evaluating SPF records. For performing general DNS based test and checks: http://mxtoolbox.com/.

Before making active changes, you can test proposed changes with the added benefit of a trace: http://vamsoft.com/support/tools/spf-policy-tester.

SPF Alignment

This is an additional step to increase the security aspect and is optional due the potential subdomain and DNS changes. This is beneficial for organisations who are spoofed a lot.

The mechanism essentially ties from sender domain in the Email to the MFROM/Return-Path – where Email is physical sent from. They should via various SPF, DNS, and DKIM lookups tie up together to prove where the Email is being sent from is actually legitimate.

Here’s an example of a non-aligned SPF record:

Delivered-To: someone@gmail.com
Received: by 10.114.29.231 with SMTP id n7csp449849ldh;
Thu, 23 Jun 2016 03:13:01 -0700 (PDT)
X-Received: by 10.194.173.65 with SMTP id bi1mr31121102wjc.160.1466676781714;
Thu, 23 Jun 2016 03:13:01 -0700 (PDT)
Return-Path: <bounce-2J25004147781P@mail04.stoneshot.com>
Received: from mail04.stoneshot.com (mail04.stoneshot.com. [217.68.19.143])
by mx.google.com with ESMTPS id cb4si6341890wjc.49.2016.06.23.03.13.01
for <someone@gmail.com>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 23 Jun 2016 03:13:01 -0700 (PDT)
Received-SPF: pass (google.com: domain of bounce-2J25004147781P@ mail04.stoneshot.com designates 217.68.19.143 as permitted sender) clientip=217.68.19.143;
Authentication-Results: mx.google.com;
dkim=pass header.i=@clientdomain.com;
spf=pass (google.com: domain of bounce-2J25004147781P@mail04.stoneshot.com designates 217.68.19.143 as permitted sender) smtp.mailfrom=bounce2J25004147781P@mail04.stoneshot.com;
dmarc=pass (p=NONE dis=NONE) header.from=clientdomain.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=ss201601; d=clientdomain.com;
h=List-Unsubscribe:Reply-To:From:To:Message-ID:Date:Subject:MIMEVersion:Content-type:Content-Transfer-Encoding; i=Michael.Wilson@clientdomain.com; bh=l3nKzFsctUBgTNjmIFB5VAkHBBZ6RMZP/S+BU5jgNp0=; b=Vu55ayTh061C+yPhSiQ9jBgIj1xOtFrPte4pQLGq7fkmoDka+w4f+wYRzAR4qqmvngpDcQIoTssK Zn33VvT5om/U1+BLAFLORZ70m1RZjgxLvKqhEwDVsIIJ7DxXFuIOEmPx9viE7X9ypZ4yzTRIkQfK 8fGoTFxz+qvCzqAuPo8= Received: by mail04.stoneshot.com id hder2q1nf484 for ; Thu, 23 Jun 2016 11:13:01 +0100 (envelope-from ) Reply-To: Michael.Wilson@clientdomain.com From: “Michael” To: someone@gmail.com Message-ID: Date: Thu, 23 Jun 2016 11:13:00 +0100 Subject: Test Email/span>

Here’s an example of an Aligned SPF record:

Delivered-To: someone@gmail.com
Received: by 10.114.29.231 with SMTP id n7csp449849ldh;
Thu, 23 Jun 2016 03:13:01 -0700 (PDT)
X-Received: by 10.194.173.65 with SMTP id bi1mr31121102wjc.160.1466676781714;
Thu, 23 Jun 2016 03:13:01 -0700 (PDT)
Return-Path: <bounce-2J25004147781P@clientdomain.com>
Received: from mail04.stoneshot.com (mail04.stoneshot.com. [217.68.19.143])
by mx.google.com with ESMTPS id cb4si6341890wjc.49.2016.06.23.03.13.01
for <someone@gmail.com>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 23 Jun 2016 03:13:01 -0700 (PDT)
Received-SPF: pass (google.com: domain of bounce-2J25004147781P@clientdomain.com designates 217.68.19.143 as permitted sender) client-ip=217.68.19.143; Authentication-Results: mx.google.com;
dkim=pass header.i=@clientdomain.com;
spf=pass (google.com: domain of bounce-2J25004147781P@clientdomain.com designates 217.68.19.143 as permitted sender) smtp.mailfrom=bounce-2J25004147781P@clientdomain.com;
dmarc=pass (p=NONE dis=NONE) header.from=clientdomain.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=ss201601; d=clientdomain.com;
h=List-Unsubscribe:Reply-To:From:To:Message-ID:Date:Subject:MIME
Version:Content-type:Content-Transfer-Encoding;
i=Michael.Wilson@clientdomain.com;
bh=l3nKzFsctUBgTNjmIFB5VAkHBBZ6RMZP/S+BU5jgNp0=; b=Vu55ayTh061C+yPhSiQ9jBgIj1xOtFrPte4pQLGq7fkmoDka+w4f+wYRzAR4qqmvngpDcQIoTsKZn33VvT5om/
U1+BLAFLORZ70m1RZjgxLvKqhEwDVsIIJ7DxXFuIOEmPx9viE7X9ypZ4yzTRIkfK8fGoTFxz+qvCzqAuPo8=
Received: by mail04.stoneshot.com id hder2q1nf484 for <someone@gmail,com>; Thu,
23 Jun 2016 11:13:01 +0100 (envelope-from <bounce-2J25004147781P@clientdomain.com>)
Reply-To: Michael.Wilson@clientdomain.com
From: “Michael” < Michael.Wilson@clientdomain.com>
To: someone@gmail.com
Message-ID: <82a861a468d44e99893d26746ed5e433@clientdomain.com>
Date: Thu, 23 Jun 2016 11:13:00 +0100
Subject: Test Email

Notice the subtle differences – which is key to SPF Alignment. The rule is, the From Email Sender domain matches the MFROM in the Email headers. There are two scenarios to consider:

  1. Domain/sub-domain is pointing to MX to somewhere other than StoneShot
  2. Domain/sub-domain is pointing to MX to StoneShot

Once the SPF is aligned, the resulting email bounces, responses, and postmaster traffic will travel back to the original From Sender domain.

At present enforcing SPF Alignment will mean StoneShot can only send emails from a single sender domain, as the Alignment is tied to the StoneShot account.

StoneShot handles Responses and Bounces on your behalf

If your domain/sub-domain MX is pointing to StoneShot already there is nothing more you need to do. This service is being deprecated.

What StoneShot changes

StoneShot will make the necessary changes so the MFROM email header is in line with the From Sender domain.

StoneShot does not handle Responses but does handle the Bounces

This is more complex as the From Sender is the Reply path, but the MFROM is StoneShot, so they conflict.

What do I need to change?

If the From Sender and MFROM were to match, your sender will be receiving the Bounces also, which would normally be received by StoneShot; not so useful. So the standard practice is to provision a sub-domain for bounces only where the MX record points to StoneShot.

For example, if we were to simply match the MFROM in the email header if would appear as follows: From sender: accountmanager@clientdomain.com

In the Email Header:

Any emails sent by StoneShot, which are intended for StoneShot, would simply return to the actual senders domain.

By provisioning a subdomain to handle the bounces only, the email would look like this:

From sender: accountmanager@clientdomain.com

In the Email Header:

This should pass SPF Alignment checks as there is a partial match on the From Sender domain and the Return-path domain; that is the key.
So:

  1. Provision a subdomain for bounce emails.
  2. Configure the MX for the new subdomain with details provided by StoneShot.
  3. Add SPF to the bounce domain as detailed in this document.

What StoneShot changes

StoneShot will make the necessary changes so the MFROM email header is in line with the From Sender domain.
Once the changes have been made using another From Sender will not work pass alignment checks.

DKIM

DKIM is a cryptographic authentication method and it’s a little trickier to set up than SPF. DomainKeys and DKIM are used interchangeably with DKIM evolving from DomainKeys.

DKIM uses a key pair consisting of a public key and a private key. The private key is used to sign the message so it’s kept secret. The public key is used to verify the signature and therefore it’s made publicly available. The receiving mail server looks-up the public key to verify the signature (included in the header of the message) and accepts or rejects the message.

Like SPF, the public key is held in a DNS TXT record. Here’s how it looks.

The DomainKeys can be applied to your sub-domains or top level domain. To generate the DomainKeys, there are two approaches depending on the where the ownership of the domain resides. The best practices is as follows:

  • If a client owns a sub-domain/domain they should generate the Keys as they have control of the DNS.
  • If StoneShot provisioned the sub-domain/domain then StoneShot should generate the Keys as we have control of the DNS.

But in practice the keys can be generated by either party and exchanged between each other.

When generating the DKIM Keys, there are a number of elements required. The DomainKey Selector, Doamin to secure, and the Key size. These typical the settings we suggest:

  • StoneShot will use ‘ss’ as the DomainKey Selector to identify StoneShot
  • Private/Public keys are 1024bit
  • The domain to be authenticated i.e. sub-domain.domin.com. This is what a typical set of generated keys would look like:
    —–BEGIN PUBLIC KEY—–
    MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDES1ixlFXR+JHuZ+zOm+8Vwb8w Dnzss9cQtK4ie0AB2Oz4OXEt7ncJ6YH6DVOhNqyCCM0oVtsjWm0JnbIq46hUHTAF Uvtxvn6XlGBzORBo6Gqe+X10R9DdXuVeL5RfYULrZT9edQ3Hgp8e8vvvLZx1CBJW PtZc14FfEk9aFGTU3QIDAQAB —–END PUBLIC KEY—–
    —–BEGIN RSA PRIVATE KEY—– MIICXgIBAAKBgQDES1ixlFXR+JHuZ+zOm+8Vwb8wDnzss9cQtK4ie0AB2Oz4OXEt 7ncJ6YH6DVOhNqyCCM0oVtsjWm0JnbIq46hUHTAFUvtxvn6XlGBzORBo6Gqe+X10 R9DdXuVeL5RfYULrZT9edQ3Hgp8e8vvvLZx1CBJWPtZc14FfEk9aFGTU3QIDAQAB AoGAX+9rM68Jmotf1yLXq8quOPXuGPCbwZvLepCzooqWJ9D7T/3TAN3RM/j521n0 C5CLEyp2CkcY5thk/hQiZa/KLiawhNcFODjRhMu1cZzWqYxb6XlbuYwyMS6VXB5w 666vE8T27jmWxaMwOYNsRoSdIPkZTefvGIQBZaD5kn4rmYkCQQDnswjJ/MTWiahe FCGOZHCMNo6pxEfvL7cYjDH+6wcYwVgK9gosFnR5Chx+yTKLEks+boc3OiF4o7gk 4YiOkafvAkEA2OG2OIKCh42gWSS+26njlmSkvPSQ+PYVNmxE43Yo7DwNmxFvpa/s 7OwK2U4aii5ttMb3u9E8EKr3bM3QDd9j8wJBAIRwhQSYNJeBJjlofmnbJa4v/Uoz BP9Gof0pHebdxzeyRLY3P0dGKpuJWRJrxTVTZqkwGqBJ3RoNU1PZiuobfgcCQQCg 0Z2hAYVwpmAEOe8cSzlrR22wf1kQgsjv9hCO6gsmQNGF7sPvBCiW9eCFihi75fmL Vw5Twq7bXSrjDyn7X25pAkEAl6ciIGgbCKYEOWKolkPflLAKRxK5lOb2Y2uXF/Up 3NnFUuwtk0cXee9JHvAU1vYFlrXbN9Jo0ZV8veEglkY2UA==
    —–END RSA PRIVATE KEY—–

The DNS change would be as follows:

A DomainKey Selector entry in TXT

And the value is the public key:

(Depending on the DNS server, the “\” to escape the “;” may not be required.)

The private key is used and stored by StoneShot to sign the emails when sending.

Testing and Checking

A useful site to generate DKIM public and private keys is DKIM checker to check and validate a DNS entry: http://dkimcore.org/tools/keycheck.html

If you need any assistance, please contact the StoneShot Team who will be happy to help.

More in this section

post > default
Getting Started
Sender Authentication
Contact Us