Home Resources Blog

Blog Post

Microsoft Takes Email Design Back 5 Years

As I type this post I still can’t believe it. I’m literally stunned. If you haven’t already heard, I’m talking about the recent news that Outlook 2007, released next month, will stop using Internet Explorer to render HTML emails and instead use the crippled Microsoft Word rendering engine. Now c’mon, how bad can this be? First things first, you need to realize that Outlook enjoys a 75-80% share of the corporate email market, which is similar to Internet Explorer’s share of the browser market – they make the rules. We’ve been doing some early testing, as have a few other brave souls, and come February, here’s just a taste of what won’t be supported: No background images – Background images in divs and table cells are gone, meaning Mark’s image replacement technique is out the window. Poor background color support – Give a div or table cell a background color, add some text to it and the background color displays fine. Nest another table or div inside though and the background color vanishes. No support for float or position – Completely breaking any CSS based layouts right from the word go. Tables only. Shocking box model support – Very poor support for padding and margin, and you thought IE5 was bad! Microsoft have released a full run down of what is and isn’t supported, including a downloadable validator that helps you validate your HTML for their engine. Word of warning though, it only works with Microsoft software and Dreamweaver. To give you a quick example of just how far backwards we’ve gone, here’s a screenshot of the Campaign Monitor newsletter (which uses CSS for layout) in Outlook 2000 and 2007. Yes folks, that’s seven long years difference. Outlook 2000 Outlook 2007 This really is a game changer. Previously you could send a HTML email in the comfort that the majority of your recipients would have very good CSS support. Other email clients were also catching up. Thunderbird uses the Firefox rendering engine, the new Yahoo! Mail beta has great CSS support. Things were looking good for us CSS based email designers. Unfortunately, that all goes down the toilet now. If your email breaks in Notes or Eudora, it was often an acceptable casualty, but if it breaks in Outlook, you’re more than likely ostracizing too many recipients to justify your design approach. This certainly doesn’t spell the end for HTML email, it just takes us back 5 years where tables and nasty inline CSS was the norm. Imagine for a second that the new version of IE7 killed off the majority of CSS support and only allowed table based layouts. The web design world would be up in arms! Well, that’s exactly what the new version of Outlook does to email designers. What’s the reasoning behind this? After picking up the contents of my desk off the floor and taking a few deep breaths, I tried to come up with a few decent reasons why Microsoft would go in this direction. Here’s what I came up with. Security – But wait! Microsoft have touted Internet Explorer as “a major step forward in security”. Surely they’d just replace the IE6 rendering engine with IE7 and be done with it. I’d also love to know how float and position impacts the security of an email in any way. Consistent rendering – By default Outlook uses the Word engine to create HTML emails, which it’s done for years now. Perhaps Microsoft figured that in order to keep the look and feel of emails consistent between Outlook users they’d display emails using the same engine that created them. But what about the millions of other email newsletters out there that aren’t created with Outlook or Word? If an email is created with Outlook, then surely it should display perfectly in a modern browser like IE7. They hate us – OK, this one might be pushing it, but I’m running out of explanations here. Don’t get me wrong, we’re not Microsoft bashers here. Both our products are developed on Microsoft’s .NET platform and we’ve been a fan of their development environment for the better part of a decade. But seriously, they’ve taken 5 important years off the email design community in one fell swoop. At least they’ve still got Hotmail, right? Well, no. We’ve been doing plenty of testing with the new version of Hotmail (Windows Live Mail) for an upcoming article and it turns out that like Outlook 2007, Live Mail is actually a step backwards for us email designers. At least Hotmail ignored all CSS (except for inline CSS) and you could force it to roll back to a nicely formatted rich text email. Instead, Windows Live Mail displays some CSS but, you guessed it, limited support for floats and no positioning. It’s looking like table based layouts all round at Microsoft for the next few years at least. Where to from here? We’ve been spending the better part of the last 2 years encouraging designers to embrace accessible and standards compliant email design, but frustratingly that position may no longer hold much weight. Just yesterday, Jonathan Nicol said: None of these limitations is going to make the task of designing HTML emails impossible, but they will ensure that no advances are made in this field for a good number of years. Remember, it’s been four years since the last version of Outlook was released, so I‚’m going to guess it’ll be at least six years before Outlook 2007 drops off the edge of the map. Sadly, I couldn’t agree more. While this is certainly a big blow, the reality is that many of us are going to have to scale back our email templates to years past and stick with tables and inline CSS if we want consistent looking emails in Outlook and Windows Live Mail. For a quick example, our sample email templates use a table based layout combined with some simple CSS. Template changes aside, I don’t see why we have to take it lying down. I’d love to hear your thoughts on this news. Perhaps if we get together as a community and explain to Microsoft how damaging this change really is, we can encourage some real change, or at the very least get the discussion started. What say you, email designers? Update 1: Welcome Digg users. With the anti-HTML email comments rolling in, I just want to clarify one thing here. This has nothing to do with the text/HTML email debate and won’t stop people sending HTML email. All it means is that a lot of HTML emails in Outlook will be garbled and difficult to read. Nothing more, nothing less. Thanks also to those posting constructive comments. It seems this situation might have plenty to do with Microsoft having to separate the browser from the OS for anti-trust reasons. Update 2: We’ve just posted a follow up article that explains Microsoft’s reasoning behind this change and exactly what we can do about it if we want it changed. Update 3: The time for complaining about this change or debating HTML vs plain text has passed. Read why we need to look forward and start doing our own part to improve standards support in HTML email.

Blog Post

SiteVista Launches a Cool Email Testing Service

If you read Mark Wyner’s recent email testing opus you may have despaired at how time consuming and complex it all seemed. Even though you know it is sensible and necessary, it seems like a lot of work. Fortunately for all of us without Mark’s commitment to excellence, SiteVista have today released the first version of their email testing service. SiteVista’s web page testing service has had great reviews, and this new service looks set to match it. So what is an email testing service anyway? Basically, it’s a quick, simple and efficient way to find out how your carefully crafted HTML email is going to be variously displayed or mangled by different email clients. You put your email in, and you get back a bunch of screenshots, just like a web page testing service. Right now you get screenshots from: Outlook 2000 / XP / 2003 / 2007 Outlook Express Hotmail Gmail Apparently more will be added soon, including Apple Mail, AOL, Yahoo! Mail, Entourage and Eudora. For each client you get one screenshot of your email in the inbox / preview pane, and one of the email as it appears when opened. So within minutes you can find out how Hotmail users will see your email, whether your header fits into the Outlook preview pane and what kind of ads Google is likely to run next to it! If you’ve ever had subscribers emailing you saying they couldn’t see that photo, or your text was unreadable, you know why this is a vital service. How does it work? SiteVista have made this incredibly simple. The signup process is quick and painless, and literally within one minute I was testing my first email. To start a new test, you are given a specific email address to send your email to. You fire off your html email to that address, let SiteVista know, and you are immediately taken to the results page. Over the next few moments (from seconds to a minute or two) all the spots in the grid are filled as the screenshots appear. You can click on each one for a full size view, and it is worth noting that you can see the full email, not just a screenful. SiteVista rather grandly call this ‘FullPage technology’. Any problems are easy to spot, and you can then go away and make whatever corrections are needed before running another test. Your account contains a record of all your previous tests, so you can go back and check your results at any time. It’s all fantastically straightforward and logical. How much does it cost? If you are a freelancer, you can have up to 50 tests a month for USD$49, which is great value. Even better, if you sign up by this Friday the 12th, you can lock in your account at USD$39/month for the life of your account. Businesses can have unlimited access for up to 10 people for USD$149/month. For the full details, including annual rates at a discount, check out the pricing page. So you like it then? Yes, we all think it is a great service. There’s a couple of questions I’d like to see the SiteVista site cover, like what screen sizes and resolutions the email clients are at. I also would like to know if the email clients have been left with their default settings or not. Other than that, SiteVista’s email testing service looks like a really useful tool that can save you a lot of wasted time and money testing and sending emails. If you want to make sure you are giving your email campaigns the best chance of success, you need to test them. SiteVista have given us a simple and cost effective way to do that. What do you think? Do you do any cross-client testing for your emails now? Would you give SiteVista’s service a try?

Blog Post

New Legal Requirement for UK Based Customers

A quick one for all our UK based customers. A recent Companies Act amendments now requires additional content to be included in every email you send. As of the 1st January this year, each email sent by a company must now include: Your registered address (not just a valid company address) Your company registration number Your place of registration On top of appearing in all emails, this content must also be included on your web site. From what we’ve read, this doesn’t mean every page on your site, but just your about or legal page for example. You can find out a little more about this over at The Register.

Blog Post

The Best Christmas Emails of 2006 – Winners Announced

Check out this years crop of amazing holiday emails.

Blog Post

How to Test HTML Emails

Whether I’m developing a website or an HTML email, I spend a good deal of time testing. I run my files through a large suite of browsers and email clients, and my process is thorough. There are some things I test for globally and others which are specific to the target audience. In any case, my process is extensive because my goal is to maximize accessibility. I am often asked how I test emails. This article will outline that process including what I look for when I test, how I test for various viewing scenarios, what techniques/utilities I use for debugging and what email clients I use in my suite. You might recognize the process as part of your own, learn something new about testing or even curse my efforts as useless. I feel that my testing process is efficient and effective, but I’d love to learn something new about how my peers are testing. Comments are a good thing. My Suite of Test Devices To ensure my work accommodates people using all of the three most common desktop platforms (Macintosh, Windows and Linux) I have them all at my disposal. I design/develop on my Mac (as I have for over a decade) and have the other two on standby. Because I use a Mac Pro I can run all three platforms on a single computer (I’m running Ubuntu—an amazing and free Linux platform—and Windows XP), thanks to the glorious Parallels application: I also test on as many alternate devices as possible. This is most challenging because there are a plethora of mobile devices with an equally intimidating number of browsers and email clients. I do what I can with my Zaurus (Linux), my Treo (Palm OS) and my Blackjack (Windows). And I profusely apologize to my colleagues and friends as I occasionally beg them for test runs on their devices. Quite an annoyance, I’m sure. My Suite of Test Clients There is a lot of data to support a general consensus about the most widely used email clients and web browsers, but I also ask around to learn what people are using. This gives me a great foundation for where I should focus my efforts. However, with strict goals for accessibility I test for an extremely broad collection of clients/browsers. Some may call it extensive or even gratuitous, while I call it thorough and considerate. My suite of encompasses the following clients: Mac OS X Apple Mail 2.1 Entourage 10.1 Windows XP Mozilla Thunderbird 1.5 Outlook 2002 Outlook Express 6 Eudora 7 Lotus Notes 6.5 AOL 9 Linux Evolution Mail 2.8 Mozilla Thunderbird 1.5 Webmail .Mac Gmail Yahoo (original and new beta) Hotmail Windows Live Mail AOL Handhelds Palm Versamail (Treo smartphone) Linux EMail (Zaurus PDA) Outlook (Windows mobile) Deployment of Tests For Campaign Monitor customers who are logged in to the admin system, sending test emails is effortless. Simply navigate to the “test campaign” utility under the “create/send campaign” tab, enter the basic information and you’re set: I point all of the desktop/handheld clients in my suite to an IMAP account which I’ve created solely for testing. This enables me to send tests to a single address, then view the results across the board. Webmail accounts, however, are unique and consequently need to be tested individually. But the aforementioned test utility allows concurrent delivery to three addresses. So testing in six webmail clients is still simple and quick. Through countless tests I have learned (as we all do) what general markup will succeed and fail in various clients/browsers. This knowledge enables me to send an initial test which most often works fairly well across the board, sans a handful of unanticipated hiccups. Then, as I work to resolve the complications, the testing suite dwindles until I am satisfied with the results in each client. Campaign Monitor’s test utility enables me to quickly resend tests, and the IMAP setup enables me to view the results only in clients needing attention. My Approach to Presentation There are two fundamental ways to markup the presentational layer of an HTML document, each having its own benefits/compromises: standards-based CSS for all presentation, or table-based layouts which envelope font/color tags for text formatting. From my perspective, there is no contest between the two approaches. However, for those less educated about the pros and cons I’ll outline the basic concepts. Font Tags and Tables While this approach offers a fairly consistent visual presentation across most email clients, it comes at a high price: Embedded presentation layers weigh down an email, slowing down rendering times for mobile devices and people with dial-up connections and increasing fees for people using pay-per-kilobyte mobile plans. Table-based layouts render horribly on small-screen devices and are nightmares for disabled readers who must navigate using key/verbal commands. Table-based layouts are challenging to integrate into CMS solutions and to segment for templates. Redundant, inline presentational-markup complicates maintenance. Standards-Based CSS While web professionals are increasingly adhering to web standards, the debate about using them for HTML emails is still quite fiery. And because of my articles on the topic, I’m typically a target for misinformed, plain-text-email evangelists. The benefits of web standards in the email environment is no less impactful than on websites. If anything, they’re more important because of the increasing number of people using mobile devices to access email. The benefits of using web standards to mark up emails is obvious: Reduced file sizes are considerate of mobile readers who pay for every kilobyte they download and for people using slower dial-up connections. The content is accessible to everyone, is fluently read by aural devices and is easily navigated by those using assistive devices. Clean segmentation enables easy integration with CMS solutions. Presentation is maintained in a single location, ensuring global changes are quick and simple. There are a couple of compromises one must accept when using CSS for presentation: Visual design is reduced to something, not unlike a rich-text format in some clients. Formatting is lost when forwarded from many clients. A Word to the Wise Irrespective of my stance on this debate, there will always be a client who believes design integrity across the board is significantly more important than accessibility or catering to a mobile device audience. Consequently, I have learned that it is vital to discuss these approaches with my clients before engaging in a project. Failing to have this conversation up front will inevitably result in hearing a client say “this doesn’t look good in Hotmail” or “when I forward this from Outlook, the formatting is lost.” My Goals There are many viewing scenarios to consider which vary more wildly in the email environment than within web browsers. This is primarily because security and spam are of great concern in our inboxes, but also because of the increased use of mobile devices. I believe my approach to preparing for each of these scenarios yields appropriate results across the spectrum of clients. I have specific goals for each scenario—all focused on accessibility—and test for these specific results accordingly. Following, are some of these specific scenarios. Text-Only Clients Many people use non-graphical email clients, especially in the mobile arena. These clients either display the plain-text segment of a multi-part email or extract text from the HTML. Take a look at how Lynx (popular non-graphical browser) renders HTML into a text-only presentation: Note how there is some formatting which helps the reader distinguish headlines (flush left) from paragraphs (indented). This is possible because the headlines are marked up appropriately with H1, h3 and P tags. Font tags and tables would produce something much less readable. Also, note how I compose ALT text, using all-encompassing brackets. This is something I do by default to help readers distinguish ALT text from regular content when viewing HTML sans images. And I prefix ALT text with a description of the image (in this case “photo:”), which denotes what type of image has been omitted. I test for text-only presentations using Lynx, Palm VersaMail and Linux EMail (default email application on my Zaurus handheld). Disabled Images with CSS Support Images can be manually disabled, and are disabled by default in a handful of clients. As David Greiner brings to our attention, Epsilon Interactive conducted a study which reports how 30% of our recipients may not even know images are disabled. My approach to image integration is pretty simple, I use CSS backgrounds for all images which are part of the core visual design and only use embedded images (<img>) for contextually relevant images. The big challenge surfaces when images are disabled in a graphical client that supports CSS. In this scenario, CSS-background images would disappear leaving no ALT text. However, there is a solution to this problem which I outline in another article. I believe it yields acceptable results: The title of this email, “Digital Web Magazine,” is exhibited with an image of the publisher’s logo. With images disabled in a client that supports CSS we retain visibility of a title. Perfect. I am able to easily test how my email will appear with disabled images using an amazing Firefox extension which is invaluable even beyond testing for disabled images. I highly recommend it for every web designer. HTML Capable Clients with no CSS Support Many HTML-capable clients do not support CSS. In this scenario, CSS shines bright. “Why?,” you say. “It’s gone.” I use CSS for my entire presentation and semantic markup for the content, so when the CSS is removed from an HTML document the result is a readable email, visually similar to that of a rich-text document: This is where those seeking pixel-perfect designs across the board begin to recoil in horror. I feel this is an acceptable sacrifice to ensure accessibility for everyone, though many clients would disagree. And this is where the aforementioned pre-project discussion will come in handy. My clients are prepared for this scenario, safeguarding me from a mid-project debate and potential situation requiring me to recode an email using font tags and tables. Testing for this scenario is simple using the aforementioned Web Developer Extension for Firefox, wherein CSS can be disabled with a single click. But it is advisable to set up Hotmail and Gmail accounts for real-world testing. Both of the said webmail clients support HTML and disable CSS by default. Screen Readers Aural devices obviously ignore all visual design. But that doesn’t mean all visual elements disappear completely. For example ALT text and link titles are read aloud and lists are denoted as such. Thus it becomes obvious just what kind of impact our markup can have on a visually-impaired reader. Testing for aural devices is incredibly challenging because they simply aren’t widely available without paying significant license fees. The popular screen readers on the market are well worth their weight in gold to those who need them, but for developers the expense can be intimidating. However, there is an open source screen reader available for the Linux platform called Emacspeak. Thanks to the aforementioned Parallels application and respective Ubuntu Linux-platform on my Mac Pro, this is what I use to hear my websites and emails. Spammers and Standards Compliance I would like to conclude this article with a note about the deployment of mass emails, just so we’re all clear on my intentions. I have written a handful of articles about techniques for successfully deploying standards-compliant emails. Consequently, I have been labeled a “spammer,” an “email marketer” and outright “evil” in blogs around the web. I have also received some emails exhibiting a level of anger I would expect if I were clubbing seals. And the debate about whether or not we should even have HTML emails fuels the fire for these evangelists. My articles are intended to help legitimate companies send legitimate emails to an audience of subscribers. Permission-based email deployment is not evil and spammers do not take the time to ensure their emails are standards-compliant. I welcome a debate about use of HTML in the email environment, but I would like to ensure that my intentions are not misconstrued. I have clearly outlined the importance of CAN-SPAM ACT compliance, do not work with clients who disregard the importance of a permission-based email-communication system and do not support the use of rented lists for mass marketing. The benefits of web standards are clear, and my hope is that this information will encourage people to accompany their standards-compliant websites with standards-compliant emails. I’ve said it before and I’ll say it again: if we have to build HTML emails, we may as well do it right. I am willing to go the extra mile to ensure accessibility—how about you?

Blog Post

Getting Opt-In Permission Offline

Professional trade show presenter Heidi Miller based a recent episode of her “Diary of a Shameless Self Promoter” podcast around the concept of email newsletters and spam. Heidi, who collects a lot of business cards through her work, had mentioned previously that she was considering taking email addresses from those cards and signing them up to her newsletter. Several callers to her show suggested (correctly) that without explicit permission from those contacts, subscribing them to her list could be considered spamming. One of the callers described a great method to handle this specific situation. When she meets people, she specifically asks them if they would like to receive her email newsletter. If they say yes, she has them write ‘Yes to Newsletter’ on the back of their business card. Conversely, if they say no, she notes that on the card instead. That way, when she processes the new contacts after a convention or show, she has a clear indication of who has opted-in and who has not. Nobody is accidentally subscribed and she always has the original permission to refer to. If you deal with a lot of offline permission situations, you might consider adapting this to your situation and put it into use. When you add new subscribers to Campaign Monitor, our anti-spam policy requires that you have clearly explained that you will be contacting them by email. This technique could be part of a good permission management process. Do you have any experience dealing with getting permission offline? What’s your process?

Blog Post

Image Blocking, Alt Tags and Why CSS Rules

For the most current results on image blocking in email clients, view our updated post. I read an article on Clickz today by Jeanne Jennings on the current state of image blocking in email. Jeanne tested 30 random B2B and B2C emails in her inbox on their approach to image blocking. While the results were mixed, I was very surprised to see her suggest that image alt tags might not even be worth the effort. She cited the instructions Outlook 2003 places before the alt text for every image (explaining the image is blocked and how to show it) as the reasoning behind this. It’s a mouthful. And it precedes any alt tag text the sender might have included. So even when there were alt tags, they weren’t prominently placed or easy to read or skim. Based on this, the value of alt tags is minimal. I’m not sure I’d bother. The only problem with this assertion is that not everyone uses Outlook 2003. In most of the popular email environments, such as Yahoo, Gmail, Thunderbird for example, alt text is displayed unimpaired for every image in your email and can go a long way to encouraging your recipients to enable images. But there’s another benefit that needs to be considered. What about accessibility? To many email readers, there’s an even more important reason to ensure descriptive alt text for every image in your email – accessibility. Any of your recipients who are visually impaired use the alt text you specify for each to get a better understanding of your email content, especially if that image has some relevance/importance to the content of your email. Jennifer Kyrnin has put together some nice suggestions on how to write alt tags for accessibility that are worth a look. The magic of CSS While alt tags are extremely important, there’s an alternative CSS technique we can use in our HTML emails that in my opinion beats the pants off the old images/alt text approach. This technique, explored in detail by Mark Wyner a few months back, includes the use of background images via CSS instead of simply placing the image in your XHTML/HTML content. Using this approach, Mark can display styled and well formatted alt text when images are off, replaced with the image itself when images are on. No ugly placeholder images with a big red X, no messy instructions in Outlook, just a nicely styled text alternative or the image itself. Further to this, the content is completely accessible for the visually impaired. Talk about a win/win! So, I guess the takeaways are: Always use alt text for the images in your email Try to keep them as descriptive as possible (see here for more on this) If possible, try and use the CSS background image approach to avoid the ugly placeholder issue altogether.

Blog Post

Inside the New .Mac Webmail Client

Apple has introduced a new webmail client for their .Mac customers. It’s a truly phenomenal webmail client, functioning nearly parallel to that of their desktop client, Mail. For a brief moment I became disoriented, because while in my browser I was experiencing what I do every day in Mail. Whoa. Of course my first thoughts were concerns for how they may now be handling HTML emails. As I noted in a previous article, .Mac’s previous webmail client had amazing support for CSS and standards-based markup. The two major oddities were easily remedied, and we were on our way. So how does the new .Mac perform? I ran some tests and the results are in: the plane has crashed into the mountain! (A reference for the Lebowski fans out there.) Testing: Round One My first tests lead me to believe that .Mac’s support for CSS completely disappeared. (And that consequently produced a brief daydream wherein I was Tony Soprano chasing down the .Mac developers for some revenge.) Quickly realizing there were roughly 10,000 lines of AJAX markup (have I mentioned how cool the interface is?) in the .Mac interface, I turned to the amazing Web Developer extension for Firefox to help me locate the markup for my rendered test-message. Once I was in, it didn’t take long to locate the problem. The new .Mac takes an approach similar to that of Yahoo, whereby a message ID is applied to a new all-encompassing container DIV and every style is prefixed with the respective ID to create child selectors… Original HTML: <div id="BodyImposter"> <h1>Headline h1</h1> <p>Lorem ipsum dolor sit amet…</p> </div> Original CSS: #BodyImposter { [properties] } #BodyImposter h1 { [properties] } Modified HTML: <div id="messageCanvas_070C9153"> <div id="BodyImposter"> <h1>Headline h1</h1> <p>Lorem ipsum dolor sit amet…</p> </div> </div> Modified CSS: #messageCanvas_070C9153 > #BodyImposter { [properties] } #messageCanvas_070C9153 > #BodyImposter h1 { [properties] } This process is obviously aimed at foiling any modifications to the .Mac GUI caused by the use of type selectors. And if properly executed it would not impact the appearance of the source email. However, .Mac adds a gratuitous DIV just inside the new #messageCanvas DIV, consequently rendering all CSS useless… .Mac-rendered HTML: <div id="messageCanvas_070C9153"> <div> <div id="BodyImposter"> <h1>Headline h1</h1> <p>Lorem ipsum dolor sit amet…</p> </div> </div> </div> In order for the .Mac styles to work, #messageCanvas_070C9153 > #BodyImposter would need to become #messageCanvas_070C9153 > div > #BodyImposter. Such a seemingly harmless little DIV topples the entire email. The .Mac developers obviously didn’t thoroughly test this process. Testing: Round Two I ran a second test to see if I could overcome this problem, but came up short. I added my own child-selector system in the CSS, but did not add it to the HTML… My HTML: <div id="BodyImposter"> <h1>Headline h1</h1> <p>Lorem ipsum dolor sit amet…</p> </div> My CSS: div > #BodyImposter { [properties] } div > #BodyImposter h1 { [properties] } This would account for the gratuitous DIV that .Mac tosses into the mix because I didn’t actually add the new DIV to my HTML. Sure enough it worked like a charm, and .Mac’s support for the CSS in my test email was flawless. But using this process would render the CSS useless in every other email client because the new DIV would only appear in .Mac. Oh, the conundrum. Grim Conclusion So the result is that we’re at an impasse with .Mac: either we support other clients or we support .Mac. The former is the obvious choice, leaving us with .Mac emails looking like those rendered in Gmail and Hotmail. Bummer. I contacted Apple about this bug, but since they do not communicate directly with their customers we can only hope my message is routed/attended to by their .Mac developers. Until then, we just have to live with it. Unless someone out there has a creative solution up their sleeve? UPDATE: David/Rumble’s recommendation works wonders I ran a couple tests using this remedy, and all is well with .Mac. The downside is this solution requires a significant increase in markup because every selector must be declared twice. So for anyone considering this technique to preserve formatting in .Mac, I recommend first assessing how many .Mac addresses are on the subscription list.

Blog Post

AOL Delivery Issues

We’re currently experiencing problems delivering some campaigns to your AOL subscribers. We’ve been in talks with the AOL postmaster since the issue was identified and are hoping to have the issue resolved as soon as possible (the big guys aren’t the most nimble unfortunately). In the mean time, we’ll be delivering all your campaigns as normal, but holding off sending your emails to your AOL recipients until they can guarantee the issue is resolved. We’ll be posting an update here the moment they can give us that confirmation. Update (6pm US EST): We’ve just had confirmation from AOL that they’re aware of the issue and are resolving it now, just waiting for a final confirmation and green light. More here soon. Update (7.20pm US EST): The issue has now been resolved and we’ll be resuming delivery to your AOL recipients in the next 24 hours. Thanks for your patience.

Blog Post

Scheduled Maintenance This Sunday

We’ll be completing the final phase in our big infrastructure upgrade we mentioned a few weeks back this Sunday night morning. Because of this, you won’t be able to access your Campaign Monitor account for roughly six hours between 12.30am and 6.30am on Sunday morning US EST (convert this to your own time zone). We’ve gone very conservative with this window and are hoping to have this upgrade completed sooner. And don’t worry, the application will continue to tick along nicely behind the scenes adding new subscribers and tracking your campaigns, you just won’t be able to log in to the Campaign Monitor interface. New IP Range Our system upgrade also means we’ll be delivering your campaigns from a new set of IP addresses. In our continued commitment to getting your email delivered, we’ve been submitting these new IP’s to the big ISP’s like AOL, Hotmail and Yahoo! and many others to ensure we continue to be whitelisted. Our new IP range is: 72.15.222.60 - 72.15.222.74 (inclusive) Also, anyone who has whitelisted our old IP’s for their own server or corporate network or set up SPF/Sender ID records should update their mail servers and DNS accordingly. We’ll make an announcement here as soon as the upgrade is completed. Update: Please note that we’ve changed the maintenance times from Sunday night to very early Sunday morning starting at 12.30am. By the time most of you guys are out of bed, we’ll be good to go. Final update: DONE! Our infrastructure upgrade is now complete and we’re purring along nicely in our new data center. We’ve been doing some serious testing for the last few hours, but if you spot anything that looks out of the ordinary, don’t hesitate to drop us a line. Some subscriber list RSS feeds might not work for the next few hours until re-delegation is completed. Thanks for your patience, we’ve had a long day and it’s well past beer o’clock at the Freshview office!

Blog Post

Want to Join the Campaign Monitor Team?

We’re looking for an experienced, Sydney-based designer to join the Freshview team and help our Campaign Monitor and MailBuild customers (that’s you guys) kick even more ass than you already are. The responsibilities will be varied, including working with customers to improve how they use our products, putting together helpful articles and flexing your design muscle across our apps and web sites. This position is perfect for a designer who is looking to get their hands dirty in other fields like building communities online and educating other designers. If you’re interested, you can get the full scoop on the Freshview site. While we’re on the subject, we’re also on the hunt for an experienced .NET developer and Windows sys admin. It’s exciting times in the Freshview office.

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

See why 250,000 companies worldwide love Campaign Monitor.

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