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
Midway through 2007 we introduced email authentication to Campaign Monitor, as an optional change you can make to increase the deliverability and security of your email campaigns. We’ve seen a huge amount of people setting up Sender ID and DomainKeys records for their ‘from’ domains. We introduced an email authentication FAQ for some common questions, but since then a few more common questions have cropped up. Can I still use Campaign Monitor without DomainKeys and Sender ID? Absolutely. If your host does not support TXT records, you can still use your Campaign Monitor account. It just means your campaigns may go through additional filters, and you miss out on the other benefits of authentication. Your campaigns will still be sent out as normal, and you will still see all the reporting. Do I have to change web hosts if my host does not support DomainKeys? No, you don’t have to necessarily. Instead, you can just switch DNS providers. Often your DNS records are hosted by the same people who host your site, but it does not have to be that way. Services like DNS Made Easy, ZoneEdit, easyDNS let you host just the DNS records with them, and keep all your sites elsewhere. This can be both faster and safer than hosting DNS and website together – it makes changing web hosts easier and also gives you more flexibility, so it is worth looking into. My DomainKeys are not verifying — what should I do? There are two main reasons this could happen. Either the DNS records have not yet propagated, or the records have not been correctly added. You can check how the records are appearing (or not) by using a service like DNSStuff. Go to the ‘tools’ section, and you can do a free DNS Lookup under ‘Hostname Tools’. Enter the domain name you are trying to verify (as in abcwidgets.com) and change the drop down menu to ‘TXT’. Hit ‘Lookup’ and you will be able to see if the records are showing up or not. If they are not there, then you need to talk to your DNS or web host and ask them to help you out. From our side, we can only see what is there, not make any changes. If it looks like the record is there and correct, then contact support. It will help if you mention the domain name you are trying to add records for. Email authentication can be a tricky area, but it is worth exploring as it is likely to become more important in the future. If you have any more questions, leave them as comments below.
As I’ve mentioned before, your sending reputation and the relevance of your email are some of the most important factors that can determine if your email arrives in the inbox or the junk folder. In order to evaluate your sending reputation, more and more ISP’s are using their “Mark as Spam” button. It’s pretty simple, if you only occasionally get a spam complaint made against you and you don’t send to that address again, you should be OK. Get lots of complaints and keep sending to those addresses and you’re in trouble. Many of the popular ISP’s out there share these complaints with Campaign Monitor so we can monitor our customers and also keep your lists clean of those who clearly don’t want to hear from you any more. To date we’re reporting on such complaints for Hotmail/MSN, AOL, United Online, Roadrunner and USA.net. We have now extended our spam reporting feature to include Comcast, the largest cable internet provider in the US. This means that any time a Comcast subscriber marks your email as spam, we’ll remove them from your list and also provide a detailed report saying who did this and when. This integration means your list will stay clean automatically and you can gather indirect feedback from your customers about the relevance of what you’re sending them.
Today we released a big round of updates to our API documentation and code samples to make it even easier to connect your Campaign Monitor account with your own web sites and applications. If you’re a back-end developer that’s right into this stuff, here’s the scoop on what we’ve changed: Vastly improved documentation We’ve done a complete overhaul on the documentation for every method available in the API. Each method will now include the related samples that feature the method, the parameters used, return codes and sample requests and responses for SOAP, POST and GET. Check out the Subscriber.Add method to get an idea of what you can expect. Comprehensive PHP wrapper Thanks to incredibly generous Campaign Monitor customer and PHP developer Kaiser Shahid, we now have an all-inclusive PHP package that supports SOAP, GET and POST seamlessly. The sample also includes a complete set of functions that encapsulate every method available in the API. Big Flash overhaul All you Flash developers out there will be pleased to know that we’ve now got a much improved Flash sample ready for download. Kindly developed by Ben and the talented team at DNA Design, the sample includes a standard subscribe form as well as a more complex version supporting custom fields. The sample has also been coded in a way that makes it easy to use any of the other methods available in the API. .NET C# and ASP samples move from the desktop to the web For the .NET samples we have created a VisualStudio.NET 2003 project that includes example pages calling some of the different API methods available. The pages use standard ASP.NET controls and are written using the Code-Behind model. This project will also work with all newer versions of Visual Studio. We’ve also changed the samples from traditional desktop applications to web pages. ColdFusion sample arrives For all those ColdFusion developers we’ve now got a great API sample that includes a standards subscribe form and a more complex one supporting custom fields. The sample code will also be easy to modify to adopt any of the other methods supported by the API.
The Gmail landscape is changing. But that’s hardly news because we’ve been using a beta version for years now. What is news is that there are four different versions of Gmail to consider when designing/developing an HTML email. If the four versions varied in simply GUI design or experience design there would be little to tell. However, as we discovered each version has its own way of handling HTML and CSS. First we’ll share the skinny on the different versions so you get a sense of what web designers are facing. Then we’ll show you some details about what’s happening under the hood.) Note: no version of Gmail supports proper standards-based markup, so these reports are based on using compromised markup with inline styles and tables. The Versions Defined There are two core ways to use Gmail: As a gmail.com account. This entails signing up for a Gmail address (firstname.lastname@example.org) and then accessing the account at gmail.com with their webmail interface. (Alternately POP or IMAP access can be setup in a desktop email-client, but the rendering of emails in such a scenario is solely dependent upon the desktop client’s performance and is thus irrelevant to this post.) As a Google App. This entails setting up Gmail as a hosted webmail application for one’s personal domain. In this scenario, Gmail is used as a webmail interface to one’s own library of addresses (email@example.com). Gmail.com Account Google offers two different versions of their interface for those using a gmail.com account: “older version,” which is set by default, and “newer version” (these are the actual names). There are a few minor differences in the experiences moving from one to the other, most notably the addition of a chat feature in the Newer Version. Overall they’re practically the same client, except for how they render HTML emails. Following are two screen shots of the same HTML email, one from each version: Newer version Older version Then, whether in “older version” or “newer version” one has the ability to switch to something called “basic HTML” view. Google defines this as follows: Standard view is what you’ll see when you sign in to Gmail from a fully-supported browser…In case you don’t have access to a fully-supported browser, we still want you to have access to Gmail—that’s why we’ve developed a basic HTML view of our service that is compatible with almost any browser. Their fully-supported browser list comprises Safari, Firefox, Mozilla, Netscape and IE on Mac, Linux and Windows, but they mention that you’ll need Firefox 2 or IE 7 to“take advantage of the newest Gmail features.” The features they list as being unavailable in “basic HTML” view are: Filter creation Spell checker Keyboard shortcuts Address auto-complete Custom from addresses But “basic HTML” view offers something more: a different rendering of your HTML email: Google Apps A screen shot of the test email from a Google App version of webmail pasted atop a screen shot of the same email in the “older version” of gmail.com is a pixel-for-pixel replica. At this time there is no way to toggle between “older version” and “newer version” in the Google App, though one can toggle between the standard version and “basic HTML view.” And the latter renders the same way as gmail.com in the same view. Is There a Line of Defense? The core differences (as far as we can tell) moving from one version to the next are how it renders padding, font sizes and bold formatting of headlines (h1–h6). Unfortunately, because of how the “newer version” renders messages there is little we can do to ensure consistent rendering across the various versions of Gmail. Following are some specific details about how each version handles the aforementioned styling. Padding In “newer version” both CSS- and table-padding are destroyed. Neither is supported, so padding is out. This is a fundamental problem in that any text inside of a box with a colored background will appear broken as it connects with the box’s sides. The “older version,” “basic HTML view” and Google App are all consistent with information we have reported in previous posts: padding is only rendered if it is used as an inline style. Font Sizes and Headline Formatting With font sizing, the “newer version” actually offers the closest accuracy. The “older version” and the Google App simply enlarge font sizes which, while has an unsightly result, isn’t nearly as bad as reducing font sizes regarding accessibility. The “basic HTML view” has the oddest rendering of all versions. Body text renders correctly but the headlines are stripped of bold formatting and are reduced to the size of surrounding body text. In Closure I believe the inconsistent rendering across the various versions of this one email client further supports a best practice of using standards-based markup. Doing so will ensure your emails look the same in any version of Gmail, in addition to supporting all the benefits of web standards. Using tables and inline styles will result in some headaches when it seems unlikely that one will achieve consistent rendering anyway. As we recently pointed out in the Email Standards Project blog, it might be time for a Gmail intervention. If supporting web standards is something you think the Gmail team should be aware of, show your support by commenting on the post in the ESP blog, adding your thoughts to this Google Groups thread and sending your feedback directly to the Gmail team. They’re listening, let’s make sure we’re heard. Update: Clarification about Padding As hcabbos pointed out in the first comment below, my reports about “inline padding” are somewhat ambiguous. To clarify, the newer version of Gmail does not support either CSS padding or inline padding via the cellpadding tag. So in the “newer version” padding is not possible at all. The following screen shots will help illustrate this: Newer version Older version
After just completing a mammoth office fitout and a big move into more space, we’re looking for a number of new people to join the Freshview team. This is a pretty cool opportunity for anyone interested in shaping the future of 2 award winning (and much-loved) web applications used by tens of thousands of fellow designers. I like to think we offer a pretty awesome work environment – free catered lunches, near the beach, private offices, and lots of other fun stuff. We’ve been holding out on making this announcement until the move into our shiny new premises was complete, but now we’re all settled and really need some more hands on deck. Here are the new positions we’ve opened up: Designer and customer support legend System Administrator Senior Developer Mid-level tester Office Manager/Bookkeeper If you’re interested, we’ve written a little about what it’s like working at Freshview. If you’re not a good match but know someone who is, please help us out by passing the position on to them. All of these positions are for our Sydney office, but if you’re the right match and interested in moving to sunny Sydney, we’d be happy to sponsor you. It’s actually a pretty easy process these days – just ask Bob, our new QA Engineer who we moved here from Canada.
While a lot of my energy is focused the Email Standards Project and looking to the future of email design, it’s obviously still important to know the best way to approach it for the here and now. If you’re looking for something close to consistency, this means using tables for layout and inline CSS. I’ve just put together an article for Vitamin called “Ensuring your HTML emails look great and get delivered” that looks back at my original recommendations last year, why they don’t make the cut any more and what you need to focus on today. This includes a list of CSS properties that are considered safe across the board, and the best way to use tables for consistent results. On top of my design recommendations, I also dig into advice on getting your emails delivered. This covers a range of topics like how to get permission, reduce spam complaints and monitor your sending reputation. If you’re already a Campaign Monitor customer, you can rest assured that all of the technical recommendations are already covered for you by default. Having said that, the technical side is only a part of your email reputation â€” the crucial ingredients of permission and relevance are up to you. Check out the article.
Now that our support for HTML confirmation emails is live, I thought it might be a nice time to revisit some recommendations on the best approach to capturing subscribers via a form on your web site. Here are a few guidelines you should consider to ensure a good experience for your new subscribers and make sure they’re primed to receive your first campaign. 1. Make it easy to subscribe Nobody likes filling in forms. While we make it easy to capture all sorts of information about your subscribers, try not to get carried away. Ask for the bare essentials only. If you do need to capture lots of information, check out these tips on good form design. 2. Ask everywhere Don’t rely on a single page on your site to lure subscribers, such as a Newsletter or Contact page. Try and place a subscribe form on every main page of your site. Again, keep it simple and only ask for the bare essentials. Here are some tips on integrating your list with any current form on your site. Don’t forget to also capture permission offline any chance you get, such as events and at the counter. 3. Set expectations It’s extremely important that you align your customers’ expectations with exactly what you plan on sending them. Make sure your subscribe form clearly explains the type of content they’ll be getting and how often they’ll be getting it. Try and do this on the form itself, and then back it up in the confirmation email. 4. Get added to their safe senders/contacts list When sending a confirmation email we let you specify the from email address you’d like to use. Make sure this address is an exact match to the from address you’ll be using when sending your campaigns. This way you can request to be added to their safe sender or contact list in the confirmation email. Once you’re in that list, you’ll often go through less filtering and your images will be displayed by default. 5. Say thanks and give some gold Don’t forget to say thanks to your subscriber. They’ve just taken a leap of faith handing over some personal details to you, show them you appreciate it. You might also consider linking to key content on your site they might be interested in, such as a past issue or some popular articles that might be related to the reason they subscribed in the first place. 6. Track where they subscribe from Follow this little tip on tracking where your subscriber join from. This allows you to do some A/B testing on different pages to see which subscribe offer/design works best. 7. Don’t forget about forwards Be sure to include a forward to a friend and subscribe link in each campaign you send. If you’re sending useful content, some subscribers will pass it on, so try and make it easy for these recipients to join your list if they’re interested. Finally, don’t forget to keep the tone of your email personal, friendly and avoid lots of email jargon. Lots of these suggestions are easy to implement, but they can make a big difference in that all important first impression.
Over the weekend we pushed a highly requested new feature live – HTML confirmation emails. It’s now easy to send a nicely formatted HTML confirmation email to anyone who joins your list from your subscribe forms or via the API. To import the HTML creative for your confirmation email, you just need to provide us with the URL. We’ll grab the page, import all images and even externally linked CSS into a single email referencing the images on our servers. You can easily preview your HTML version once it’s imported and make any changes that suit. To improve deliverability and ensure the confirmation looks great for those who prefer plain text, you can also provide a basic plain text version of your confirmation email that will be included in the same email. We’ll include a sample one to help get you started. If your new subscriber is using a plain text email client, they’ll see that version instead. To set up for own HTML confirmation email, head into your subscriber list and click on “Create a Subscribe Form” to get started.
For those of you closely monitoring support for standards-based markup in popular email clients, you’ll be happy to know that we have recently encountered a nice improvement for the .Mac webmail client. And while we’d love to take credit for having instilled fear in the hearts of Apple, we simply can’t compete with the Soprano family. Still, we’re hoping our countless articles and recent announcement about the Email Standards Project is helping to shape the future of HTML emails. In any case, at least one client is indeed shaping up. A while back we reported on the new .Mac webmail client. The old version offered amazing support for CSS. Unfortunately, the arrival of bells and whistles in the new version significantly depressed its support of standards-based markup. What’s more, we discovered a gratuitous DIV in the inbox window that eradicated all styles because of an interruption in the Descendant Selectors. The solution was to use Universal Selectors, which helped .Mac and had no inadvertent effects on other clients. On top of our post, I personally wrote Apple on more than one occasion, asking them to fix this problem. And I asked my partners to do the same. Irrespective of the impact of those emails and our post, they have since remedied this issue by withdrawing the gratuitous DIV. Consequently, our “.Mac fix” is no longer necessary. That’s the good news. The bad news is that .Mac’s support for CSS is still extremely poor. Let’s hope Apple finds it worthwhile to remedy that. We’ll be outlining exactly what changes they’ll need to make in the upcoming ESP site, launching in the next couple of weeks.
We’ve revisited these results in a newer blog post on image maps in email clients. Given current conditions in which images are very often blocked in email messages, image maps seem to be an odd technique to pursue. Because when your source image is blocked, your links are no longer functional. That’s a fundamental accessibility issue. However, the Campaign Monitor team receives frequent inquires about image maps so we decided to test them out for people who are curious. Then you, the web designer, can decide how brave you are when you unleash them into the wild. The Results Remarkably, email clients offered good support for image maps. And most surprising is that many clients retain functionality of the links even with images off. Following is a table which exhibits how popular email clients handled the image maps. Client Functions With Images On Functions With Images Off .Mac Yes Yes Yahoo! Mail Yes No Yahoo! Mail Classic Yes No AOL Webmail Yes Yes Gmail No No Windows Live Hotmail Yes No Apple Mail Yes Yes Thunderbird Yes Yes Penelope (Eudora 8) Yes Yes Outlook 2007 Yes Yes Outlook 2003 Yes Yes Outlook Express Yes Yes Windows Live Mail Yes Yes Lotus Notes 8 Yes Yes Entourage Yes No The Recommendation The results indicate that it’s not a good idea to use image maps. Specifically because of the following issues: The frequency in which images are disabled image maps and their respective images don’t marry well and therefore pose accessibility issues for those visually impaired Gmail—a very popular email client—doesn’t support them consistently (they do not work when using Safari) And with that you have the knowledge you need to discourage use of image maps.
Just under 8 hours ago (at around 1am Sydney time) our payment gateway decided to go offline without notice. Because we don’t charge you until you actually send your campaigns, this meant that no campaigns, either scheduled or being sent immediately could be delivered. After working with them for the last few hours, we’ve just received word from the gateway that the issue has been resolved, and can confirm that your campaigns can now be delivered. We realize this situation is completely unacceptable. Please rest assured that we are now accelerating our plans to move to a new payment gateway (it was happening later this month, but will now happen a lot sooner). We are also looking at extending our monitoring system to ensure we’re alerted about a payment processing error and are also looking into adding a layer of redundancy to our payment processing to ensure you’re never bothered by something like this again. Of course, I realize this explanation does nothing to curb the frustrations you and some of your clients must be feeling right now. If you feel you were significantly impacted by this issue, please get in touch with support and we’ll credit you for the cost of the campaign you were delayed in sending.
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