Straight to your inbox
Get the best email and digital marketing content delivered.
Join 250,000 in-the-know marketers and get the latest marketing tips, tactics, and news right in your inbox.Subscribe
This is a post I’ve been meaning to write for a long time now. I’ve been delaying it purely because I wanted it to be perfect. I wanted to write with Zeldman-like virtue on why email, just like the web, needs to pay attention to web standards. Sadly, in the time between the idea for this post and actually getting it published, web standards support in email has gone seriously downhill. I can’t delay it any longer. My role at Campaign Monitor has given me a great opportunity over the years to research and speak to other designers at length about the standards issue. Each time the topic comes up the result is always the same – getting an email to display consistently in all of the popular email clients is by far the most frustrating part of the job. It’s a painful and always moving target that’s getting harder instead of easier. There’s really no justification for it and it’s about time something was done. Accepting the reality of email today Let me preface this by saying I completely respect everyone’s choice for the email format they prefer to send and receive. I also understand that it probably wasn’t the original purpose of email to go beyond one-to-one plain text messaging. I really do. This is one of the biggest reasons we encourage everyone to include a plain text alternative whenever they send a HTML email. But we need to be realists. Every popular email client supports HTML email and most use that format out of the box. Out of the box means it’s the format of choice for anyone outside of the design and early adopter community and there’s no indication that’s changing any time soon. No amount of angry comments on Slashdot singing the praises of Pine are going to suddenly force email client developers to drop HTML support. It’s just not going to happen. So, it’s not going anywhere and it’s broken. If we can all get past this point together, it’s obvious that the best path forward is to work with desktop and web-based email client manufacturers to improve how HTML emails are rendered, not argue amongst ourselves about personal preference. What’s wrong with the current picture? Today there are at least 10 popular email clients out there, each offering different levels of standards support ranging from perfect to virtually non-existent. I often hear comparisons between the current state of standards in email and the web circa 2000. While there certainly are some similarities, there are also some big differences. The web standards movement faced not only poor browser support, but also an uneducated design community. They had browser makers and designers to convince. Today we’re lucky enough to stand on the shoulders of these giants in a world where web standards have well and truly been embraced by browser developers and the design community alike. People want to build HTML emails using the same approach they build for the web. Another big differentiator is the fact that there were 2 or 3 browsers to consider back then and we knew exactly which web browsers were popular, making it much easier to know where to focus our energies. There is almost no data like this for the email world. Are more of my subscribers using Thunderbird or Apple Mail? It’s almost impossible to know. So, we’ve got 3 to 4 times more variations to cater for and we don’t even know which ones we should be targeting. Because of this huge variation in standards support, email designers have been forced into a corner. There have certainly been valid attempts at encouraging the use of web standards in email, of which I’m proud to say we’ve played a part. The W3C has even jumped on board in realizing something needs to be done here. With the recent and unfortunate news from Microsoft however, it’s been getting harder and harder to justify this approach. What we’re now left with is building for the common denominator. This means bandwidth hogging, image heavy emails with nested tables and font tags. Yes, I said font tags. I see hundreds of these designs being sent every day purely because it’s the only way to achieve consistent rendering across the board. Type in the URL of those creating these designs however and you’ll often find a beautifully coded standards compliant site. Email design truly is stuck in the dark ages. Revisiting the benefits of web standards Many of you are already well aware of the positives web standards offer, but I’ll focus on those I think are particularly relevant to email. It removes the guess work from email design – This is an instant win for designers and everyday email users alike. If all email client developers aimed for something close to web standards, you can design an email knowing it will work for all your subscribers. Stop and think for a second how awesome that would be. Your subscribers will win by no longer receiving garbled, hard to read newsletters because their email client doesn’t support standards. Faster loading and reduced bandwidth consumption – Well coded, standards compliant markup that separates content from presentation is generally much more compact than nested table and spacer-image based markup. Further to this, many designers have given up on rendering issues altogether and send purely image-based emails. This adds significantly to the file size and results in a poor experience for their subscribers because of image blocking. Make your email accessible to all – Using standards does not automatically mean your email will be readable to people with disabilities, but it’s certainly a great start. By separating content from presentation you’re making it much easier for everyone to access your email. Further to these intrinsic benefits of web standards, there’s another significant win that would follow. Using tables for layout is a dying art in the web design community. Many designers who started web design in the last few years have never even coded a table based layout, which is a good thing. The current email environment means a designer not familiar with the table based approach will need to learn a completely different way of creating a page if they want to send HTML emails. We’re fast approaching a fork in the road where email design will become a niche, expensive service that fewer designers can provide. Sure, a few designers win by being able to charge more for their work, but everyone else loses. Where to from here? This much is clear – arguing about HTML vs plain text or complaining about standards support in email isn’t going to get us anywhere. It’s time to get off our butts and actually help email client manufacturers to introduce better standards support. I also think it’s important to realize that these manufacturers don’t have a problem with web standards. Supporting standards might not always be the easiest option, in fact for web-based providers I’m sure it’s quite the opposite. It’s our job to demonstrate why they are important and then make them as easy as possible to embrace. We’ve been hard at work on this for the last few weeks, focusing on the following areas: Establishing a baseline of what standards we need supported in email – We certainly don’t expect perfect standards support across the board initially, but there are a number of key properties that we can encourage manufacturers to support sooner rather than later. Document the important changes each of the major email client manufacturers need to make in order to support web and related standards – Once we’ve established the baseline, we can put together a basic wish list of the changes each manufacturer will need to make to meet this target and then work with them in any capacity possible to help make this happen. Create a simple acid test that makes it easy to see if an email client supports this baseline – Much like WaSP’s Acid2 test, we should make it easy to see if these important standards are being supported by creating a simple test page that can be viewed in that email client to confirm at a glance if the baseline is being met. We plan on bringing this all together in a dedicated site launching soon. Obviously the more of us that can get behind this the easier the job will be. Even the king of web standards, Jeffrey Zeldman agrees (emphasis his): Learn how HTML mail works (or doesn’t) across as many platforms as possible, and work with the manufacturers to improve support for web standards. This is not my job. I did my job where web standards are concerned (you’re welcome!), and turned over The Web Standards Project to a new generation of leadership. And as I never send HTML formatted mails, not only is it not my job, I wouldn’t even be qualified to do it. But standardistas who are compelled by their clients to create HTML mails (or who choose to do so) are gently urged to do their part in diminishing wasted bandwidth and enhancing semantics. We’ll be posting more about this initiative soon, including how you can help make a difference. Jeffrey’s right, it’s not his job – this one’s up to us. Update: You can start helping right now. Check out the initial list of baseline standards that should be supported and add your own thoughts.
On September 5th, New Zealand’s Unsolicited Electronic Messages Act 2007 comes into effect. For Campaign Monitor customers, this should have little impact, because it is essentially just requiring that New Zealand businesses have direct permission to email people, and always provide an unsubscribe link. Our permission policies already extend beyond that, so you won’t need to do things differently, even if you are from New Zealand. However, it is another piece of ammunition for you to use when discussing permission with your clients, to show the growing international agreement on the importance of respecting peoples email addresses and right to control what arrives in it. Mark Brownlow has a good collection of anti-spam laws around the world, helpful if you need to check for a specific countries legislation. Don’t forget though that just complying with the relevant laws is not enough anymore. You have to ensure your emails are relevant too, or risk being blocked and filtered in the same way spam is.
We’ll be taking the Campaign Monitor application offline for a total of 4 hours this Sunday morning between 1am and 5am (US Central time – see this in your own time zone) to make some key hardware upgrades and add some additional layers of redundancy to both Campaign Monitor and MailBuild. Don’t worry, the maintenance will have zero impact on your subscribe forms or campaign tracking, everything will purr along as usual – you just won’t be able to log into your account. If you’ve scheduled any campaigns to be delivered in this time-frame, they’ll be sent as soon as the application is back online. Update: We got the updates done faster than expected and as of 2.40am we’re back online. Thanks for your patience (that is of course if you weren’t sound asleep).
Anybody who has attended one of the excellent Web Directions conferences in the past will know what a great opportunity they are to hear great talks and meet up with your web colleagues. This year Web Directions South is on in Sydney from September 25th to 29th, with two days each of workshops and talks. If you aren’t already registered, then tomorrow is the last day to register at the early bird price (you don’t have to pay yet). Last year Dave and Ben gave a talk about how they started Campaign Monitor, and you can still download the podcast and slides. This year we are not speaking, but we will be part of the expo during the conference days. In our stand we’ll be demoing Campaign Monitor and MailBuild, meeting some of you guys and we’re also working on giving away a pretty cool prize. There are some great speakers lined up for the event, and we’d love to see you there! Tomorrow is also the deadline for nominations for the McFarlane Prize, an award for excellence in Australian web design. The prize is for “sites built and launched by Australian individuals or teams between August 1st 2006 and July 31 2007”, and you’ve still got enough time to nominate. Visit the Web Directions 2007 website.
When we launched our new email authentication system last week, we had no idea how well it would be received. To be honest, authentication can be a tricky concept to get your head around and I was a little nervous about how popular it would be. Sometimes I love being wrong. In less than a week hundreds of authenticated domains have been set up, many with an authenticated domain for each and every client. It’s been fantastic to see and a great result for everybody. Your emails have a better chance of being delivered, ISP’s know who you are and your domain is being protected from abuse. A number of customers have also been kind enough to send in instructions and screenshots walking through how they added the records with their own hosts. This is hugely appreciated. If you’ve set things up and don’t see your host listed, we’d LOVE for you to send through the steps and screens so it will be that much easier for your fellow Campaign Monitor designers using the same host. Of course, it hasn’t been smooth sailing for all. Almost every host out there has a different front end for managing your DNS. Some make it a breeze, others like to see you sweat. We’ve even discovered a few hosts that don’t support TXT records (and therefore authentication) at all. Sigh. We’ve put together a quick authentication FAQ for those of you that are having trouble getting your records added. We’ve found that with a little persistence even those claiming not to support it can bend their rules if you ask nicely.
What if I told you that with a few minutes work you could instantly reduce the chances of your email being marked as spam, build trust with your recipients and protect your brand from being abused via email. Sounds pretty good doesn’t it. Well, that’s exactly what you can do with the new email authentication feature we just launched. What the heck is email authentication? Email was built in much more innocent times when spam came in a can and phishing was something you did on the weekend to relax. This meant the system was left fairly open, making it very easy to manipulate – it’s just as easy to make your email come from firstname.lastname@example.org as it is from email@example.com. Unfortunately this great flexibility has also been it’s greatest undoing. Enter email authentication, a simple method that proves you sent the email. While it’s by no means a silver bullet to the spam problem, authentication is an important first step in adding that much needed accountability layer into email. In a nutshell, it involves you adding some simple records to the DNS of the domain name you send email from that says who is allowed to send email on your behalf. Without getting into too much of the boring details, there are two main authentication standards out there you need to support called Sender ID and DomainKeys. What is important is that different ISP’s use one or a combination of both, so to get the best results we’ve made it dead easy to support both standards. What’s in it for you? All the large ISP’s like AOL, Hotmail, Yahoo! and Gmail are using email authentication as an important layer in their spam fighting arsenal. By setting up Campaign Monitor as an authenticated sender, you can instantly bypass certain filters, giving your campaigns a better chance of arriving in the inbox. Not only that, but many ISP’s like Yahoo! and Hotmail will flag your email as authenticated, which helps to build trust between you and your subscribers and improves the chances of your emails being opened. For example, here’s an authenticated and non-authenticated email in Yahoo! Mail: Authenticating your sending domains in Campaign Monitor I know the concept of authentication can make some designer’s eyes glaze over (mine included), so we’ve made the entire process as pain-free as possible. While I’ll give you an overview here, we’ve also put together a complete guide in the help system, along with instructions on updating your DNS records in some of the popular hosts (we’ll be adding more soon). To get started, select the client you’d like to set this up for under “Manage Clients” and click the big green “Add a domain to authenticate” button. Once you enter the domain name you want to authenticate, we’ll generate the 2 records to add to your DNS. Once you’ve added the records, we’ll automatically check them out and confirm that they’ve been added correctly. As soon as they have, that domain will be available as an authenticated domain when sending email for that client. That’s all there is to it! We’ll take care of the rest and make sure each ISP knows the email is definitely coming from you. You’ll now be able to bypass some spam filters, build trust with your recipients and ensure your domain name cannot be used fraudulently by others.
Our brand new suppression list feature was rolled out a few hours ago. All went very smoothly and you can check them out under your Manage Subscribers tab. You’ll notice that each client-wide suppression list is populated with all the unsubscribes from any previous lists in that client’s account. This ensures that moving forward anyone who previously unsubscribed cannot be added to any new subscriber lists. Quick Tip: Scrubbing your lists against the suppression list While we’ve populated your suppression list with any previous unsubscribes, we haven’t scrubbed all of your lists against it. If you’d like to scrub any of your subscriber lists against the suppression list, here’s a quick tip. Head into the “Unsubscribe Options” for that list and you’ll notice a new section where you can adjust how it integrates with the suppression list. If you turn suppression list integration off by selecting “Only unsubscribe them from this list”, save your settings and then turn it back on again, you’ll be given some additional options. The second of these options allows you to scrub all your “Active” subscribers against the suppression list. Here’s a quick screenshot of how this looks: By ticking that checkbox, we’ll automatically scrub your list and remove anyone who has ever unsubscribed from any lists for that client. We hope you enjoy the new feature, we think it’s a great addition and plan on adding it to MailBuild real soon too.
Here’s some more evidence for the great and growing depth of design talent working with email newsletters. The latest few take the total to over 150 different designs. Subscribe to the gallery’s RSS feed to keep up to date as the list grows.
To keep things as easy to manage as possible, we’ve always kept unsubscribes at the list level, not the client level. This means that if a customer is subscribed to List A and List B and they unsubscribe from List A, they will still be subscribed to List B. This approach has worked very well for the majority of you guys. Most of you only have one or two lists per client and more often than not there isn’t much cross over anyway. The problem with this approach is that as your list management needs get more complex, the chances of an unsubscriber being accidentally sent to again increase. On top of this, there are plenty of other list management scenarios out there. You might want to ensure anyone who unsubscribed is never contacted again, no matter how many lists they’re in. What if you’ve got a big chunk of unsubscribers from a previous system that you want to ensure are never added to any of your lists in Campaign Monitor? The list really does go on. From tomorrow, all of this will be possible from your Campaign Monitor account. The Answer: Suppression Lists Tomorrow we’ll be introducing a new feature called “Client-wide suppression lists”. This is basically a client-wide do not email list. Here’s a screenshot of how you can access this list from your subscriber list index page: Any address in this list will never be added to your subscriber lists and you can add and remove addresses from it whenever you like. By default, any unsubscribes from each list will be added to the suppression list for that client automatically. Here’s how the page to manage your suppression list will look: This keeps you safe by ensuring you can never re-send to a previous unsubscriber accidentally. The best part is, you don’t need to lift a finger to start taking advantage of this feature, it will work behind the scenes automatically. Choose which approach works for you While the suppression list will be turned on by default for each list, we’ve give you the ability to turn it off on a list-by-list basis. If you’d like to revert back to the old approach, no problem at all. You’ll be able to adjust how this is handled in the Unsubscribe Settings for that list. Here’s a quick screenshot of the new options: I hope you all find the new suppression list feature useful. We think it’s a big improvement over the current approach and like any good update, works seamlessly behind the scenes without you actually needing to do anything.
Anyone trying to pay for a campaign for the last few hours would have noticed a frustrating “Server busy” message. Our sincere apologies for this. Turns out our payment gateway is having some unscheduled downtime. We’re working with them as I type this and will post an update here the moment they’re back online. Not that it’s any consolation, but we’ll be moving to a new and more reliable merchant provider in the next few weeks. This one’s frustrating for everyone. Update: We’re back online and accepting payments again. Thanks so much for your patience as this issue was resolved and apologies again for any delays this caused.
We’ve posted about this quite a while back but it remains one of the most common questions we get. How can I get the address of people who just unsubscribed, so I can keep my database up to date? Since we first answered, we’ve added a full API which has a method for getting a list of people who have unsubscribed since a specified date. If you have some development skill available, that’s a great way to keep things in sync. However, you don’t have to use the API – a simple way of getting hold of those unsubscribed addresses is to use the custom unsubscribe confirmation page. You can find it under ‘Unsubscribe Options’ for any list, and it lets you enter a URL that we will send people to after they unsubscribe from your list. You can just have a static ‘sorry to see you go’ page there, but you can also pass through the unsubscribing email address, and send it to whichever internal system you have. It’s very simple – just make your unsubscribe URL something like: www.yourwebsite.com/goodbye.php?emailaddress=[email] That [email] tag will be replaced with the relevant address, and passed onto your pag, and from there it’s up to you. Anyone who unsubscribes via a link in your campaign or an unsubscribe form will be handled in this way. Please note: You can’t pass through any custom field values on the query string like this, only the name and email address will work.
Join 250,000 in-the-know marketers and get the latest marketing tips, tactics, and news right in your inbox.Subscribe
From Australia to Zimbabwe, and everywhere in between, companies count on Campaign Monitor for email campaigns that boost the bottom line.Get started for free