Email Reputation Management – Part Two

This is the second of a two part post, so if you aren’t familar with how email delivery works or the importance of your reputation as an email sender, be sure to check out part one before reading on. Here we’ll dive deeper into the topic of email reputation management, covering some concrete steps you can take to more effectively manage your email sending reputation.

General Reputation Management

The contents of your email messages and the responses they generate have a major impact on your reputation as an email sender. The most obvious examples of this are spam report and complaints registered by the recipient. These will quickly erode your reputation as an email sender and should be avoided at all cost. In addition to this, your bounce rate is also a factor used to determine your reputation and should be actively managed to ensure it is held as low as possible. A bounce rate of at most 1% is a good target to have in many systems.

I wasn’t initially aware of it, but ESPs also setup spam trap email addresses which are not used to send or receive emails but rather are kept completely off the grid, so that when an email is sent to one of these addresses it can confidently be recorded as spam.

Finally, the actual contents of your email can also cause it to be flagged as spam which reflects negatively on your reputation. Ensuring that your emails adhere to the CAN-SPAM specification is a good initial step toward preventing this. Additionally, using tools like Mail Tester to actively test your emails is a good practice to be in the habit of.

It’s important to keep an eye on each of these factors and not focus exclusively on just one or two of them.

Domain Reputation Management

The first step in managing your domain based email sending reputation is to determine the domains you plan to use for sending emails. Each of these domains will have a separate reputation, which can be beneficial in many cases but also adds an additional level of complexity to your application. In many cases you may be able to use a single domain for all emails you send. At Belly, we send emails directly to our users for many different reasons (e.g. user account management, member reward redemption, merchant marketing newsletter, etc). We also send emails on behalf of our merchants directly to their customers. For this reason, we manage a number of different domains to isolate the reputation for each group.

There are two methods that recipient ESPs commonly use to verify the domain specified on an incoming message. They are DomainKeys Identified Mail (DKIM) and the Sender Policy Framework (SPF). Both are designed to allow the recipient ESP to verify that the sender of the message does in fact own the domain from which they are sending emails. For this reason, the first step is to purchase all domains from which you plan to send emails.

DKIM works by having the sender create a TXT resource under the domain from which they plan to send emails (e.g. The sender then includes a ’DKIM-Signature’ header field on the message, which specifies the domain and selector values the recipient ESP will use to retrieve the associated verification resource. This signature also contains an encrypted hash of the message contents. The recipient ESP extracts the public key from the retrieved resource and uses this to decrypt the hash value contained in the message’s DKIM signature. They can then compute a hash of the message and verify that it’s computed value matched the decrypted value provided by the sender. In this manner they are able to verify that the sender does in fact own the domain specified in the signature.

SPF provides a similar type of verification using a different procedure to accomplish this. To enable SPF the sender creates a TXT resource for the exact domain from which they will be sending emails. The contents of this resource specifies the set of hosts that are authorized to send email on their behalf (e.g. “v=spf1 ip4: -all”). The syntax of this resource is defined by the SPF specification, which I won’t attempt to fully explain here but rather would encourage you to review the specification (link) and work with your ESP to determine the appropriate content to use for your domain. When the recipient’s ESP receives a message from your domain, they will pull the corresponding TXT resource and use it’s contents to verify that the sending server is included in the set of authorized hosts or IP addresses.

Both these types of verifications can and typically are used in parallel to provide more robust verification of the sender. We highly recommend using both types of verification on all domains from which you send email as they have a major impact on your email sending reputation and delivery rate. In particular places significant emphasis on these types of verification and without them you can expect to see a 10 – 20% increase in your bounce rates for these emails.

IP Reputation Management

On the IP reputation side the first step is to allocate dedicated IP addresses for the servers from which you plan to send emails. Most ESPs use a standard pool of IP addresses for the email traffic they send on behalf of their customers. They also typically allow customers to reserve dedicated IP addresses to ensure only their messages are sent from these addresses. Without using dedicated IP addresses, you will not able to control your IP reputation. Instead you will be lumped in along with the rest of the emails being sent through your ESP. In a similar manner to your domain reputation management, you also want to consider how many IP addresses your application will need and the traffic that should be isolated into each. In many cases it would be appropriate to maintain a separate IP address for each domain from which you send emails.

One thing to be mindful of when setting up a new dedicated IP address is that recipient ESPs watch for patterns in the email activity that comes from an IP address and use this as a determining factor in the reputation assigned to that IP. For this reason, if you take a new (a.k.a. “cold”) IP address and start sending large volumes of email through it, recipient ESPs will see this as a sudden increase in the volume of email they expect from that IP address and will be more likely to flag the traffic as potential spam. Rather you need to “warm up” the IP address by initially sending small amounts of traffic from the IP address and gradually increasing this amount until the desired email volume is reached.

Recipient ESPs also use Reverse DNS (rDNS) to verify that the IP address from which they received a message matches the server advertised as the sender of the message. In this case the sending server is what is being validated, not the sending domain. Each email message identifies the domain from which it is being sent (e.g., which is separate from the domain of the sender’s email address (e.g. [email protected]). When a recipient ESP receives a message they will run both a forward DNS query (i.e. standard DNS resolution of hostname to IP address) and a reverse DNS query (i.e. looking up a hostname based on an IP address) using the advertised domain of the sending server and the IP address from which they received the message. These two lookups must provide a symmetric mapping between the IP address and the domain in order for the sending server to be verified. The rDNS query depends on a PTR record to be configured for the IP address from which you are sending these emails. In many cases the IP address used for sending emails is owned by your ESP and will require their help to have rDNS support configured for it.

ESPs will often automatically configure rDNS for your dedicated IP addresses using hosts within their domain. The benefit of configuring rDNS using your own domain is the isolation this provides from your ESP. Instead of piggybacking your reputation on top of theirs, which may limit the level of reputation you’re able to achieve, having you emails advertised as being sent from your domains puts you in complete control of your reputation.


Unfortunately there is no silver bullet solution to improving your email sender reputation. Much like search engine optimization (SEO) this is a task that requires consistent attention to hone in on the right set of steps to produce an optimal reputation for your application. Most importantly, have fun with it! Try out some of the steps outlined above, track the results, and keep tinkering with it until you reach an acceptable delivery rate for your application.

Ask a question or share this article, we’d love to hear from you!