Articles in this section

SETUP - SPF, DKIM, and DMARC

  • Updated
Follow

When you send an email from T2Connect, the recipient's ISP (such as Gmail, Yahoo, AOL or Outlook), will use a variety of methods to determine if you are permitted to send communications using your from email address. For example, you are not permitted to send an email with the from email address info@example.com unless you own Example.com. If someone sends messages posing as Example.com, ISPs have methods of identifying this as phishing and will block it. 

SPF, DKIM, and DMARC are the three established methods used to verify a sender's identity. 

Authentication allows good senders to further solidify their reputation and protect their domain from bad senders who may try to hijack their domain.

As such, we make it easy for you to setup authentication, but you are not required to do so. 

DKIM

DKIM is essentially a “signature” any sender can apply to their email messages. This signature makes clear that the purported sender of the message is actually the sender of the message. Any domain can be used as the “signature.” For example, a company called Example will sign their messages with the Example.com domain to confirm that the message was actually sent by Example.

This is accomplished by inserting a hidden, cryptographic signature into your email header (T2Connect will do this) and then placing a public key on your website that verifies the authenticity of this signature.

It is easy to setup DKIM for you own domain . 

Contact our support department to received your DKIM and SFP Txt records.

You will need to add these TXT records to the DNS of your website. To find specific instructions for your host, we recommend searching Google for “add TXT record at _______”. Fill in the blank with the name of your host (Godaddy, Hostgator, Cloudfare etc). 


SPF

SPF records are public records on your website that authorize certain servers to send mail with your domain. 

We actually handle SPF for all senders, because SPF protocol will check the sending server's domain for SPF, not your own domain. 

As such, SPF is out of your hands. You don't need to setup SPF, even if you are using a Custom Domain.

Why should you set up SPF on your domain?

There is an older, deprecated version of SPF called SenderID where the recipient ISP checks the visible From Address for authentication. The means the from address domain you use to send the message (like @mydomain.com) would be checked for an SPF record that authorizes T2Connect to send with this domain. 

SenderID is deprecated and the only ISP of note that still checks for SenderID is Microsoft (this includes Outlook.com, Hotmail.com, Live.com, and MSN.com). There is no evidence that this check will influence your deliverability positively or negatively. 

There may be other, smaller ISPs that still use some version of SenderID, although they are rare. And, in some cases it may be necessary to setup SPF/SenderID to ensure the notification emails from your automations deliver.

You can choose to add an SPF record to your domain to ensure your emails will pass a SenderID check. However, this will not have a noticeable affect on deliver ability to any major ISP, since the standardized SPF check is handled by T2Connect. 

If you already have an SPF record, it is important that you don't add a second. Instead of having two SPF records, you should just add “include:emsd1.com” to the current SPF record, like this:

v=spf1 include:emsd1.com include:_spf.google.com ~all

DMARC

DMARC builds on SPF and DKIM, and tells ISPs like Gmail and Outlook what to do if your emails fail SPF or DKIM. ISPs will look to the DMARC record on your domain to know how they should handle mail that doesn't pass DMARC.

The lack of a DMARC record (which is the default) will tell ISPs to treat mail normally if it doesn't pass DMARC. A stricter DMARC policy will tell ISPs to reject or quarantine mail that doesn't pass a DMARC test.

Most importantly, DMARC is not a method to “boost” your deliverability. It permits you to enhance security for your domain.


By default, all domains will not have a DMARC record in place, and it is not necessary for you to setup a DMARC record for delivery. As such, DMARC is totally optional, and there is no immediate benefit to deliverability to setup DMARC, unless:

  1. Someone is actively spoofing your domain, sending fraudulent mail, and tarnishing your reputation. DMARC would let you identify this malicious activity and shut it down.
  2. You added a DMARC record that is “strict” which will lead ISPs to block mail that doesn't pass a DMARC test. A poorly configured DMARC is basically telling ISPs you want them to block your messages.

There are two options for DMARC, lenient and strict. We recommend setting up a lenient policy, because this is the safest for deliverability. To setup a lenient DMARC policy, you should add this TXT record to your domain at _dmarc.mydomain.com:

v=DMARC1; p=none;

If you want to implement stronger security on your domain, you can setup a strict DMARC record that will tell ISPs to reject or quarantine mail that does not pass the DMARC test. To setup a strict DMARC record, we would advise you visit dmarc.org for recommendations to configure the record properly. 

Important: A strict record will require that you have a proper DKIM record setup for your sending domain, or else all your mail from T2Connect will fail the DMARC test. Make sure you have set up DKIM for all of your sending domains before setting up a strict DMARC record. 

Additional Reading

In this article, we didn't attempt to explain the technical process of how SPF, DKIM, and DMARC work. Each of these authentication protocols has a public website where the technical specification is explained at depth: