Emails, spam and infrastructure guide for developers

Email infrastructure knowledge for developers.

I have worked in the email space for a couple of years and thought that sharing the basics of how email works would be useful to developers, technical founders that are about to send out emails to their customers.

I am going to talk about the following topics:

• Infrastructure
• Reputation
• Authentication

There are two types of email:

• Transactional: The email that you receive as the result of some action you've taken on a platform like a password reset, an alert or notification. If a system fails at sending you a transactional email, you could be affected negatively in using the platform.

• Marketing: These emails are sent to you with the purpose of marketing you something, most likely sent by human(s). Unlike transactional email these are not functional emails, if you missed all of the marketing emails you could still live your life happily

Transactional emails are nice, marketing emails - meh - Thinking about it, wouldn't it be really nasty if you couldn't reset your password to your Github account if you'd lost it? But if Github sends you an email to let you know they're giving out a t-shirt to anyone who attends their event it's not the end of the world...right?

👍
Did you know that 1 in 5 emails don't end up in the recipient's mailbox, that's 20% of your company's transactional or marketing sent emails sent that don't ever make it to someone's mailbox .

Why? because you might be not (willingly or unwillingly), complying with the rules of deliverability. Respect the rules, win the game!

Unfortunately 70% of emails sent worldwide are spam!

Email comes with Reputation

Email reputation can be thought of as a score that is attributed to all of the following attributes:

• the sending domain
• the IP of the domain
• the content of the email

If any of the above get flagged, your reputation will suffer and consequently you will have a higher chance of sending emails directly to a spamfolder.

Emails have a code of honor. It's really nasty coding an email in HTML because there are so many gotchas. Do your research, there are hundreds of guides and cheat-sheets. Respect the HTML format, don't add unsupported HTML features or JS in your email.

Furthermore:

• Let people unsubscribe nicely
• Ease up sending lots of email when you get started, and stay consistent sending emails patterns. If you send once a month or twice a month, don't suddenly change to sending email every single day.
• Follow on complaints (spam/flagging), minimize them ( < 0.1% of your total send list)
• Don't fall for honey pots - don't use crawlers to harvest emails, don't use other people's email lists (or at LEAST, don't acquire them from people you can't trust) Monitor bounce rates (soft bounce = out of the office/unavailable inbox could be full or suspended, hard bounce = email address unreachable/invalid) - Use opt-in or double-opt in processes
• Segment email address of people who are active and prefer them over those who are not active. (list filtering)
• Don't use no-reply@yourdomain.com - that's bad for your users and a sign of poor email practices
• Include plain-text versions of your emails, these will help spam-blockers parse your email faster and therefore they will appreciate the plain-text version.

Email Infrastructure: What specifically do you need to know?

• Use dedicated and warmed up IP addresses for new senders - otherwise you will be sharing the reputation belonging to the previous sender on that IP
• Secure server infrastructure from malicious users who might use your platform to spam or do other funny business, or use a third party API, there are a lot of email, APIs out there
• ISP feedback loops . If you can get access to these, use them to know what's going on when people hit report/spam emails (M3AAWG)- most people use ReturnPath's service but there are some companies who use their own services (i.e. GMail)
• Make sure you have your own abuse (postmaster@, abuse@) set up on your own mailservers or domain.
• Collaborate with spam filters like Barracuda or IP2BAN, and be aware of 3rd party hosted filters like CloudMark, MessageLabs
• Research rate Limits for the major email services, this helps specifically if you are setting up your own MX server.

Authentication

Authentication is a big topic - I wrote a post separately about it. Read it here and learn how can you lessen the risk of your messages ending up in a spam folder using SPF, SenderID, DKIM, Domain Keys…

Feedback Loops

• You must own the IP/domain, or have admin rights, in order to register for a FBL
• There must be a working abuse@ or postmaster@ email address for the domain
• The rDNS of an IP being entered needs to match the domain being used
• Most ISPs specify that a good reputation is needed to be accepted on their FBL

Resources that you will find useful

Super good resource to keep in mind
https://wordtothewise.com/isp-information/
Your good or bad reputation can be checked on:

• SenderScore.org
• Senderbase.org
• Reputationauthority.org
• Barracuda Central

Avoid being BlackListed at all costs

• Spamhaus - http://spamhaus.org
• CBL - http://cbl.abuseat.org/ -Trend Micro MAPS - http://www.mail-abuse.com/

Final words...

Staying clear from all these evils is a must for successful email sending!
mers.

Hit me up in the comments if you have further questions :)