Do you have a builder document you can share with this behavior, or captures?
We do open email in a new window in our testing process. The preview pane should be the same rendering control, but its probably a narrower width.
Also, sometimes some designs do not render 100% if content at the bottom of the email hasn't loaded yet. It's possible the preview pane view only loads the first bit of content, and only when you open in a new window is the rest of the content loaded and then the preview pane updates. See if you have the same problem if you make the outlook window very large before loading the email. There's a free tool called 'fiddler' for Windows and i run that in the background to determine if all the assets of a message have loaded or not. Let me know if I can help out at all with this, as I work on Litmus' previews engine and know how the renders are created.
I am looking to buy an email list
This is the worst practice and I'm going to stop you right there. Buying a list is illegal in the United States. Don't do it.
Does anyone know the limit on emails that I can send with Outlook, Gmail or Mac Mail without having the server reject my email?
You are violating the providers Terms of Service by sending commercial email through their service. It's a terrible practice. Please do not do it.
My objective is not to spam and it's very targeted to a limited audience with an educational objective as opposed to trying to sell them something.
You've said your objective is not to spam but you are going to send a commercial email to people who didn't sign up to receive it. How is that targeted and how is that not spam?!
Have you run both variants through Litmus' Spam Testing? Emoji are widely used in email campaigns I think if they negatively affected deliverability we would have heard about it by now.
So my first instinct is to say, no, that spam filtering and delivery scores are not affected by Content Transfer encoding. Because Email is an old standard, email transmissions were originally written supporting only the ASCII character set. However, HTML and the web supports much broader character sets (UTF-8/16). In order to transmit that data over a medium that only supports ASCII we usually encode the UTF8 or other codepage using one of the transfer encodings then when clients go to render the message they can decode the more complex codepage and render emoji, foreign languages, etc etc.
So my guess is that the scores for spam are going to be determined after the email is decoded and that I couldn't see a good reason why delivery/spam software would care about encoding.
Yes, plans that are Plus and above (see https://litmus.com/pricing) have access to Email Analytics, which is where the above charts came from. We give you some HTML to paste in your email and we can help you see how engaged your customers are with your email. If you have any other questions feel free to reach out to firstname.lastname@example.org. Cheers!
can you provide an example url? Is everything in the URL properly HTML encoded?
Many corp users are behind proxies/firewalls and could rewrite URLs. do you have the user agent referrer for the links so you can narrow down their email client?
We definitely see this at Litmus from time to time. Some culprits:
Very large emails can cause outlook to crash. Try to keep total content low and do not include large assets if you can avoid it.
Bad image headers served from the image hosting. Sometimes we see image servers that use nonstandard HTTP codes.
My suggestion would be to debug by selectively removing content from the email one at a time. Start by removing all images and seeing if that loads. If so, great. Add them back one at a time until you get a fault and check the faulting image. Might be an unsupported image type (PNGs are not supported on very old Outlook instances. GZIP only images might be a problem on old versions too.)
Can you get the email to reliably break in Litmus testing too? We could load the email up in builder and give it a shot.
You're right but you aren't always guaranteed to get UTF-8 end-to-end like you would in the browser. Email transmission still is ASCII for a lot of architectures. I'm of the mind to HTML encode any non-ascii character, it's the safest practice and I believe there's tools out there that can do that for you.