Nobody Likes Spam

Everyone is familiar with the scourge of email and spam, and (in particular) with spoofing (which can lead to phishing). Spoofing is when an email is sent by someone pretending to be a person or organization, but who isn’t.

Spoofing can of course be malicious. But it’s also part and parcel of using a third party professional email service (e.g. FeedBlitz) to send your bulk emails for you. There are lots of ways that Email Service Providers (ESPs) like FeedBlitz work on deliverability, such as managing and maintaining IP reputation. 

In addition though, a sending organization can formally say that an ESP is authorized to send on their behalf. This is called email authentication, and goes by two main acronyms, SPF and DKIM.

SPF and DKIM

As well as potentially improving deliverability (because SPF and DKIM prove that we are authorized to send on your behalf), they confer other brand advantages. Specifically, they eliminate the “via <ESP name>” from the header in web mail apps, such as gmail. That can reduce confusion for recipients.

The onus of setting up SPF and DKIM is on you and your end-user organization, and requires setting up DNS entries, as follows.

Setting up SPF

Create an SPF record for the domain (it’s a TXT entry on the domain’s DNS) you will be using as the “From” domain as part of you service, and either set up a new SPF record (which you will need to if you set up a new subdomain, e.g. messaging.myplugin.com):

v=spf1 include:t9n.feedblitz.com –all

or, if you’re using an existing domain with an existing SPF record, add this:

include:t9n.feedblitz.com

to the relevant SPF record.

IMPORTANT: If the domain you specify sends email via other services (such as your own email service), change –all to ~all in the “new” SPF record above, and include the relevant SPF settings for them too.

We strongly recommend you set up a subdomain (e.g. messaging.myplugin.com) for your dedicated email service, for simplicity.

Once you have your SPF record set up, you can have your end users add it to their SPF records via an include statement, except they include:messaging.myplugin.com instead of the t9n.feedblitz.com domain.

Enabling DKIM

DKIM is another way of authenticating, and we also recommend that you enable it. Again this is a DNS entry, but note that DKIM records are not TXT records, but are instead in our usage CNAME (alias) entries, as follows:

feedblitz._domainkey.messaging.myplugin.com. CNAME dkim.t9n.feedblitz.com

where you replace “messaging.myplugin.com” with the subdomain you’re using.

Since DKIM is more complex, FeedBlitz has tools to check DKIM settings. A DKIM profile must be set up in your FeedBlitz account, which you can then use to validate the settings. When you’re setting up DKIM we suggest very short TTLs (e.g. 60s or less) so that changes you make propagate quickly. Once the record validates, you can change the TTL to something more sensible.

Adding DMARC to the Alphabet Soup

But wait, there’s more. DMARC is another DNS protocol that doesn’t authenticate email, but instead tells receiving ISPs how to handle email that doesn’t authenticate via SPF and / or DKIM.

Yahoo, for example, prohibits anyone from sending email from a yahoo.com address, unless it came via a Yahoo email server. Their DMARC record basically tells receiving ISPs to not even accept the email.

So what FeedBlitz does, when it sees someone trying to send an email through us using a yahoo.com address, is change the from address to one that will be accepted, making sure the reply-to and from name are unchanged. We do this for all domains we recognize as having hostile DMARC policies; it’s a good thing.

Setting up SPF and DKIM correctly dramatically reduce the risk that a corporate decision will unwittingly cause a deliverability problem. In the event that a DMARC issue is detected and the domain owner later authorizes FeedBlitz, you nee to contact FeedBlitz support so that we can update our records appropriately.