I’ve had a lot of discussions with clients who have (or should have) concerns about the role addresses in their lists. Most discussions revolve around the presence of these addresses in the subscriber database and why Real Magnet prevents them from being loaded by default.

To provide some context, let’s clarify what we call “role addresses.” They’re typically defined as any address that is assigned not to a specific individual, but instead to a role within an organization. These addresses include, but are not limited to:

• sales@
• info@
• admin@
• hostmaster@
• abuse@

…and the list goes on and on. There is no definitive list of role address prefixes, because domain admins can set up role addresses for literally anything. However, there are really just a couple dozen role addresses that are most commonly seen, including those examples above.

Even when these addresses are provided via a clear opt-in method, they are still more likely to cause delivery issues. As a result most providers block them from being imported into email lists. In fact, some ESPs have reported that role addresses are 2-3 times more likely to unsubscribe or bounce than non-role addresses, and lists containing high numbers of role addresses typically see sharp declines in engagement.

So what’s the big deal? Why exactly are role addresses problematic? Most (but not all) of the problems with role addresses hinge on the fact they often route mail to a group of people instead of a single contact. Let’s look at some of the biggest concerns:

1. Permission is often impossible to confirm. With multiple recipients at the same email address, opt-ins are murky at best. Let’s say you get an opt-in request from sales@example.com, which includes everyone on the Sales team at that domain. That request was made by only one of the people who actually receives those mailings. Even with a confirmed opt-in, it’s possible that the other recipients of that address do not want to receive your mailings. They are more likely to report the message as spam or unsubscribe, which brings us to…
2. Unsubscribes get applied too broadly or reversed too easily. With a role address, one of the recipients of the message may choose to unsubscribe even while others want to continue receiving your mailings. If you use an unsubscribe method that is linked to a custom recipient ID (as most ESPs provide), that person will be unsubscribing the group instead of just his own address.In addition, recipients often send an email request to unsubscribe (or report spam). This email will likely originate not from the role address, but from their personal address that actually receives the mail. If the recipient fails to include message headers or the headers have been distorted by their email client, it is sometimes tough to know what address actually received the mailing. The personal email address may be added to a suppression list, but the recipient will continue to receive your mailings.
3. Roles (and the people who fill them) change regularly. Let’s say you have a role address that directs to a team of employees, and let’s also say that each of those employees has made it clear they want to receive your emails. Great! Now what happens when a new person joins that team? Or a member of another department is added to that role address group to be kept abreast of team-related emails? To avoid all issues, you’d have to get a new consent each time someone new joins that address. That’s certainly possible, but not really practical and nearly impossible to track.
4. Bounces are more difficult to process. If one of the recipients of your email leaves the organization and their address goes dark, there’s a chance the bounce response never reaches you (depending how the org handles bounces and routing). But even if you do receive the bounceback, you may not know how to process it. The address returning the bounce will not be the one that’s in your mailing list, which will cause most automated bounce handling to choke. If you continue to send to invalid addresses domains may block all your mail or, even worse, one of those addresses may roll over into a spam trap and get you blacklisted.

Now that you know the problems with role addresses, how do you avoid these issues? If you’re building a new list, you should require that recipients enter a non-role address. There are a couple of ways to do this depending on your technical resources. The most effective method is to implement real-time address checks that will reject role address submissions, but this also requires the most technical overhead. Many senders choose instead to simply inform their subscribers that role addresses cannot be used. Then, those addresses will be discarded upon list import and will not receive email.

For senders who already have a list containing role addresses, the next steps may be a bit less clear. If your list contains only a few of these addresses, it may be best to reach out to the individuals to ask them to provide a different address. This can be accomplished through a one-to-one email, phone call, or even a face-to-face conversation.

When you have a larger number of role addresses, we typically recommend sending a bulk campaign asking these recipients to update their information. Most senders do this via email (outside their ESP in many cases) or a postcard encouraging users to update their preferences to continue receiving mail.

Typically, recipients who want your emails will be willing to update their information. However, if you have some recipients who can only use a role address, many ESPs will evaluate on a case-by-case basis whether or not those addresses can be allowed in your list.

– BG