That’s where Mailtrap Email Testing comes into play. And today, we’ll teach you how to execute various tests in Salesforce using Mailtrap.

What is Mailtrap Email Testing?

Mailtrap Email Testing is an Email Sandbox – a safe environment to inspect and debug emails in staging and development environments. It captures all the SMTP traffic and traps your test emails in a virtual inbox. Email Testing is part of the Mailtrap Email Delivery Platform.

Some of the features of Email Testing include

• A fake SMTP server to eliminate the risk of spamming users;

• HTML analysis to check how your emails will render in different email clients;

• Spam analysis for popular spam filters and blacklists;

• SMTP and API for easy integration;

• Ready-made code snippets for popular languages and frameworks;

• Multiple inboxes for different projects and stages.

Try Email Testing for Free

When should you use Mailtrap Email Testing?

There are several use cases where you should opt for Mailtrap Email Testing. Let’s quickly discuss each of them below.

Avoiding spamming users with test emails

You can easily avoid annoying your recipients by using Mailtrap Email Testing. It will create sort of a barrier between Salesforce and your contacts. As a result, all your test emails will end up in a virtual inbox.

Testing email format and content

With Email Testing, you can easily check HTML/CSS in your templates for different email clients. You’ll see a detailed chart with problematic lines of code marked in red. Each problematic element has a description of the support level for each client.

On top of that, Email Testing has a Spam Analysis feature.

The feature is particularly important for your deliverability and sender reputation. Why? The score gives you a clear indication if mailbox providers may automatically label your email template as spam. Plus, you get to see if your domain or IP appear in any of the blacklists.

That way, you’ll get the chance to make the emails less spammy in staging and protect your sender reputation in production.

Additionally, you can test your pre-made templates with Mailtrap API with which you can easily switch from staging to production once you’re ready to start sending.

All you have to do is enable sandbox, specify the inbox ID to receive template test, and then send it through the API in the production environment.

Try Email Testing for Free

Keeping all test emails in one place

Email Testing captures all your outgoing Salesforce emails and keeps them organized in different inboxes for various projects and testing stages.

So, Email Testing and Salesforce create a robust combo for in-depth testing and debugging.

How to test email deliverability

For the instructions below, we’ll assume that you already have a Salesforce account up and running.

But to start testing, you’ll also need to set up a Mailtrap account (if you have it already, you can skip this step).

1. Go to Mailtrap’s sign up page and choose the desired method of registration;

2. Go to Email Testing → Inboxes to find your first inbox created by default. It’s called ‘My Inbox’ but you can easily rename it by clicking the pencil icon on the right. It’s also possible to create additional projects and inboxes if needed.

3. Click on your inbox and hit Show Credentials to reveal the credentials for the fake SMTP server.

4. Go to your Salesforce account and navigate to Setup → Email (under Administration) → Email Relays.

5. Click Create Email Relay and fill out the form with Email Testing’s SMTP credentials as in the example below:

6. Click Enable SMTP Auth to connect to the SMTP server with authentication. Enter your SMTP username and password.

7. Click Save. Head to Email Domain Filters and click Create Email Domain Filter. This step is necessary to activate the relay.

8. There, enter ‘*’ as the default wildcard for Sender Domain and Recipient Domain. Then mark the Active checkbox, otherwise the relay won’t be applied. Click Save.

Now it’s time to send test emails with Apex and see if they will be delivered to the Email Testing’s virtual inbox. For more details on sending emails with Apex, check out this blog post.

In your Salesforce account, navigate to Setup and type Apex Classes in a quick find box.

Click New to create a new Apex class that will send a simple email. Paste the following snippet and press Save.

Don’t forget to substitute recipient@example.com and no-reply@example.com with actual email addresses.

public class SendSingleEmail {
    public void sendSingleEmailMethod(){

        Messaging.reserveSingleEmailCapacity(2);
        Messaging.SingleEmailMessage mymail = new Messaging.SingleEmailMessage();

        // Ensure that addresses are correctly formatted and matching case
        String[] toAddresses = new String[] {'recipient@example.com'};

        mymail.setToAddresses(toAddresses);
        mymail.setReplyTo('no-reply@example.com');
        mymail.setSenderDisplayName('Salesforce Support');
        mymail.setSubject('Test Email ');
        mymail.setPlainTextBody('This is the first test email sent from Salesforce with Mailtrap Email Testing');
        mymail.setHtmlBody('<p>This is the first test email sent from Salesforce with Mailtrap Email Testing</p>');

        Messaging.sendEmail(new Messaging.SingleEmailMessage[] { mymail });
    }
}

Copy

Go back to the Apex classes page, click Developer Console, and open the class we just created. Under debug, choose Open Execute Anonymous Window.

Type the following line of code and click Execute.

sendSingleEmail obj = new sendSingleEmail();
obj.sendSingleEmailMethod();

Copy

Under logs, a success message will appear. Head to your Mailtrap Email Testing inbox and you’ll see the test email there. This confirms that Salesforce deliverability doesn’t have any issues.

How to test email templates

Testing email templates is quite easy in Salesforce. And since we already have email relay configured, we just need to take a couple of additional steps. To make our tests interesting and leverage the full capabilities of Email Testing, let’s send text and HTML templates separately.

Testing text templates

We’ll create a sample text template in Salesforce.

1. Go to Setup → Email → Classic Email Templates and click New Template.

2. Select Text as the template type and press Next.

3. Configure the desired merged fields. For this example, we chose Contact Fields as the field type and the First Name as the field. Then, choose the folder in which the template will be saved, mark the checkbox next to Available For Use, name the template, and enter the subject line and body text. Don’t forget to insert the auto-generated merge field. Save the template.

4. Click Send Test and Verify Merge Fields.

5. In the pop-up window, choose the contact you want to test the template for. Tick Send email preview to and enter your email address.

6. Click OK. Now check your Email Testing inbox. The test template will be right there. However, you won’t find it in your real inbox since we sent it through the fake SMTP server.

Testing HTML templates

Just like in the previous example, we should start by creating a template, but instead of text, let’s select Custom (without using Classic Letterhead). Click Next.

Select the folder, make the template available for use, give it a unique name, and set the subject. The Encoding should be set to Unicode (UTF-8) as per HTML specifications.

In the next step, we can add an HTML body. This time we’ll skip the merge field and concentrate on testing the HTML content.

Then we need to configure the text version of the email. That way, the body text of the email will still be visible even if the email client doesn’t render the HTML properly. Click Save.

You will see the preview of the email. Let’s send it as we did before and inspect it in our virtual inbox.

1. Start by checking the email preview in different devices. You can check mobile, tablet, and desktop views.

2. Then let’s move to the HTML Source tab. There, you’ll see all the problematic elements marked with a red exclamation icon.

3. Go to the HTML Check tab to inspect client support in more detail. Here, you can filter results by a specific client/device or view the overall HTML support percentage. Check out our knowledge base article to learn how HTML check works and how to interpret data.

After analyzing the HTML check results, you can adjust the code and correct/remove elements that might stop your Salesforce emails from rendering in your contacts’ inboxes.

How to test email alerts

With Mailtrap, you can test any type of Salesforce email alert. The following sections detail all the steps, but we’ll start by creating an alert first.

1. Search for Email Alerts, then click the New Email Alert button.

2. Fill out the fields based on your testing needs and click Save. Keep in mind that the fields labeled red are mandatory. Also, we used an exemplary object and email template, so you may need to change that based on your testing needs.

Testing Email Alerts

An Email Alert can be sent via Workflow Rules, Process Builder, and the Flow.

Here are the steps for each method.

Create a simple Workflow rule

1. Navigate to the Workflow Rules and click the New Rule button.

2. Select Contact as the object.

3. Under Evaluation Criteria, choose created, and every time it’s added. Then, in Rule Criteria, choose Contact Email under Fields, set the Operator to not equal to, and the Value as null. Lastly, click the Save & Next button.

4. Thereon, click the Add Workflow Action button and select Existing Action.

5. Choose the email alert that you previously created and click the Save button.

6. Go to the Workflow Rules one more time and activate the process.

Test the Workflow Rule Email Alert

1. Go to any contact record and edit any field. The workflow rule should send an email alert when a contact record is created or edited. Then, click the Save button.

2. Go to Mailtrap and make sure that the email is delivered.

Create a simple Process Builder

1. Navigate to the Process Builder, then click New.

2. Fill out the fields based on your testing needs, and click the Save button.
   Tip: Make the Process, API name, and Description congruent for easier reference. Keep the variable under The process starts when at A record changes.

3. Choose the Contact object and in the Start the process field select only when a record is created option, then click the Save button.

4. Add Criteria based on your testing needs – we built the Process based on the example used in this article.

5. Click the IMMEDIATE_ACTIONS tile, and under the Action Type choose Email Alerts, then select the email alert created in the previous steps, and click the Save button.

6. Activate the Process Builder.

Test the Process Builder Email Alerts

Tip: If you want to get an email only from the Process Builder, deactivate Workflow rules before creating a new contact. Otherwise, the Workflow rule will be executed too as this rule also meets the criteria.

1. Go to the Contact tab and create a new contact.

2. Go to Mailtrap and make sure that the email is delivered.

Create a simple flow

1. Navigate to Flows and click the New Flow button.

2. Select Record-Triggered Flow and click the Create button.

3. Configure Start as per your testing needs and click the Done button. Note that you should keep the Configure Trigger option as A record is created or updated.

4. Click the white dot to add a new element.

5. Under Shortcuts choose Send Email Alert.

6. Fill out the fields to label and describe the action, then hit the Done button.

7. Save the Flow.

8. Activate the Flow.

Test the Flow Email Alert

Tip: If you want to get email only from Flow, deactivate Workflow rules and Process Builder before creating a new contact. Otherwise, the Workflow rule and Process Builder will also be executed as they meet the criteria.

1. Go to the Contact tab and create a new contact.

2. Go to Mailtrap and make sure that the email is delivered.

How to test bulk email handling

With the help of Mailtrap Email Testing, you can test bulk email handling in Salesforce. This test will validate the Apex limits and check if your bulk emails are getting delivered properly.

Just like with previous tests, Email Testing’s SMTP credentials should be set up as an email relay.

The first step is to create a sufficient amount of contact data by importing data with a Data Import Wizard or adding a couple of sample contacts manually. For the latter, press on the application icon and choose Marketing.

Under the Contacts tab, click New. Enter the name of the contact, create a new account to associate with the contact, and enter the email address. Save the settings and repeat the process for any other contact you want to add.

Once you’re done, your contacts list should look something like this:

Next, create a sample template, open it and note the template’s ID. It’s located in the URL and starts with 00X.

At this point, we can start writing an Apex Class.

Add a new class in Apex classes with the following script:

public class BulkEmailHandler {
    public static void sendBulkEmail(List<Id> contactIds) {
        Messaging.reserveMassEmailCapacity(contactIds.size());

        Messaging.MassEmailMessage mail = new Messaging.MassEmailMessage();

        mail.setTargetObjectIds(contactIds);
        mail.setTemplateId('your_template_id'); // replace 'your_template_id' with the actual ID of your email template
        mail.setSaveAsActivity(false);

        Messaging.sendEmail(new Messaging.MassEmailMessage[] { mail });
    }
}

Copy

This piece of code requires contact IDs. So, to run the script, we should ask Apex to grab contact IDs first and then send an email. Open the developer console and in the Open Execute Anonymous Window, add the following lines:

List<Contact> contacts = [SELECT Id FROM Contact LIMIT 10];
List<Id> contactIds = new List<Id>();
for (Contact c : contacts) {
    contactIds.add(c.Id);
}
BulkEmailHandler.sendBulkEmail(contactIds);

Copy

Press Execute. In a few seconds, the emails will pop up in your Mailtrap virtual inbox indicating that your Salesforce platform can successfully send bulk emails.

Note: The code piece above will send an email to 50 contacts by default. You should update your SOQL query if you need to send more. Also, depending on the type of your Salesforce org and the package you’re using, your daily email sending volume may also be limited.

Wrapping up

This wraps up our tutorial on testing emails in Salesforce with Mailtrap Email Testing. Now you can successfully inspect and debug email deliverability, text and HTML templates, and bulk email handling.

Don’t forget to organize your virtual inbox by creating different projects and inboxes. That will simplify the testing process and keep your data in one place.

To learn more about Mailtrap, click here.

Sign Up for Free

We appreciate you chose this amazing article to know how to use Mailtrap with Salesforce to test emails. To read more interesting articles on the related topics, follow Mailtrap blog!

Email clients with no standards

While coding a web page, an engineer takes the following factors into consideration:

• operating system

• browser type

• screen size

When building an HTML email template, in addition to the operating system and screen size, one has to account for the email client.

There is a wide selection of email clients that encompasses several web and desktop solutions, where the way an email is displayed depends largely on the rendering engine a system uses.

Of course, a universal set of standards would be much easier for email clients to support and for developers to comply with. But, unfortunately, we don’t have any. Every email client plays by its own rules. That’s why the rendering of CSS by various email clients may differ significantly.

Top 10 email clients in 2018

In June 2018, Litmus released an Email Client Market Share report which was based on 1.04B email opens data they gathered worldwide. One can review this report to get an idea about the core market players and their shares in this area.

Email Client Market Share, 2018

Know what email clients your target audience prefers

Although having access to the general stats provided by Litmus is great, we would recommend you check what devices and email clients your target audience uses. Having this information at hand will simplify the email development process by reducing the number of devices and email clients an engineer has to tailor an email for.

If you are using Mailchimp, go to List and check the following stats:

Email clients per sending list in Mailchimp

If you are using Sendgrid, go to Stats, and then Email Clients & Devices. Sendgrid will provide you with several respective categories: Top Devices, Top Webmail Clients, and Top Desktop Clients.

The top devices used to open Mailtrap email campaigns in Sendgrid

The top webmail clients used to open Mailtrap email campaigns in Sendgrid

The top desktop email clients used to open Mailtrap email campaigns in Sendgrid

Outlook email client

According to the Litmus Email Client Market Share report, Outlook ranks #5 with a 7% market share. However, not everyone knows that Outlook for Windows still uses the Microsoft Word engine for rendering. At the same time, Outlook for Mac supports almost any kind of HTML and CSS formatting.

Below are only some of the aspects a developer should bear in mind when adjusting an email template for an Outlook email client:

• Outlook does not “understand” HTML bulleted list tags

• Outlook uses Times New Roman as the default font

• Outlook may add a page break to an email if it exceeds 1800px

• Outlook cleans up paragraph and margin spacing

• Outlook does not support background images

Of course, some of the above-mentioned cases may be solved by using a “table” tag structure in an email template, while others require special tricks and workarounds that engineers may apply to ensure correct email rendering.

The best ways to create HTML emails

There are some aspects that one should consider when building HTML email templates. Let’s review the suggestions below.

Use simple design

We recommend developers keep the email design simple. Apply grid-based layers and stay away from the elements that include positioning or HTML floats.

Adjust HTML emails to different screen sizes

With Apple iPhone email client ranking #1 in the recent Litmus report, one can see clearly that it is crucial for an email template to display well not only on desktop but also on tablet and smartphone.
To succeed with this task, one can try using scalable, fluid, or responsive design. So, let’s dive a bit deeper into each type of design to choose the one which will suit your requirements best.

Scalable HTML email design

This type of design presumes the presence of a minimum number of structural elements in an email. That’s why it usually consists of one text column that can be easily scaled for all types of devices, one image, and a Call to Action (CTA) button.

Fluid HTML email design

The fluid design uses percentages to adjust to a recipient’s screen size by filling up all space in an email just like fluid would do in an empty container. However, to make sure an email’s content does not cover all the available screen area, it is recommended to configure the table’s maximum width. It’s a common practice to set the default width to 600px.

Responsive HTML email design

Utilizing responsive design, in turn, allows sending customized HTML email templates that may automatically adjust not only the size but also the content depending on a recipient’s device and screen size. The desktop and the mobile version of an email may differ significantly from each other or may be alike. In the end, a desktop version of an email may include more or different components than a mobile version and vice versa, which makes this type of design universal for all devices and screen sizes (existing and newly introduced).

Media queries, introduced in CSS3, empower responsive design. The top email clients are well aware of what media queries are. However, it’s worth keeping in mind that there are still email clients that won’t succeed with their rendering at all.

Think about mobile users

Working with HTML email design, one should remember the golden rule – mobile design goes first. I.e., a mobile version should be checked first to decrease the loading time on small devices. For instance, the first condition may be set as “larger than 768 pixels”.

Choose the right fonts

Many email clients won’t be able to render Google Fonts properly. In this case, one should opt for the common fonts that the major email clients interpret well. Such as Times New Roman, Arial, Georgia, and Verdana.

Take images seriously

Some email clients block images by default and some users may amend their inbox settings to block images if the client isn’t doing it. So, it is best to follow the advice below when coding an email template:

• Accompany your image header with text to make sure that a user will still understand what the email is about, even if the image gets blocked.

• Don’t build HTML emails that consist of one or two large images only. If one of them or both are not displayed properly, it will ruin the entire email campaign.

• Keep your emails simple by adding just enough images and text to guarantee that your message still makes sense even if all images are blocked.

• If your email includes a call to action (CTA) in the form of a button, don’t use an image to format the CTA. Instead, you can try to create a padding-based button. This simple method uses both HTML and CSS for button building.

Last but not least: keep in mind the email size. The maximum file size limits for emails are pretty high, but the recommended size of the email body should not exceed 250KB.

For more development tips and code samples, check our guide on building HTML Email.

Otherwise, you can try using an HTML email builder. They usually come with a set of customizable email templates, which can be used in any email sending system. In this post, we have reviewed the ten tools suitable for both developers’ and marketers’ needs.

HTML email testing

Before sending out an HTML email campaign, it is worth checking whether your emails will get delivered to recipients or end up marked as spam, as well as getting some email rendering advice.

For this, we recommend using a solution such as Mailtrap Email Sandbox, which provides you with a safe environment for inspecting and debugging testing emails, so you don’t accidentally end up spamming recipients.

Mailtrap Email Sandbox comes in especially handy for testing HTML emails as it provides a range of features intended specifically for this purpose. So, once you send your first test email to Mailtrap Email Sandbox (process described in detail here), you will be able to:

• View how your email is rendered by a browser and check its responsiveness in the HTML tab.

Mailtrap Email Sandbox HTML tab

• Scan through your email’s HTML code for problematic elements, gain insight into which email clients don’t support or only partially support those problematic elements. Furthermore, in the HTML Check tab, you can get an estimate of how your email code is supported across popular email clients.

Mailtrap Email Sandbox HTML Check tab

• View the HTML markup in the HTML Source tab.

Mailtrap Email Sandbox HTML Source tab

• View the email’s text part (the message displayed when the HTML cannot be) in the Text tab.

Mailtrap Email Sandbox Text tab

• Preview the email in raw format in the Raw tab.

Mailtrap Email Sandbox Raw tab

Other features of Mailtrap Email Sandbox include multiple virtual inboxes for different projects and project stages, blacklist reports for your sender IP/domain, spam analysis, manual and automatic email forwarding to whitelisted recipients, and insight into detailed tech info – essentially everything one needs for advanced email testing.

To get started with this solution, all you need to do is sign up for a free Mailtrap account and complete a 5-minute setup. After that, you can start exploring all the mentioned Email Sandbox features.

Inspect Your Emails

Conclusion

We hope that this blog post addressed some of the core aspects you should be paying attention to when crafting an email template. In addition, we just wanted to remind you one more time how important HTML emails testing is 😉

We appreciate you chose this article to know how to build HTML email template. To read more article on related topics, follow Mailtrap blog!

In today’s blog post, we’ll guide you through the maze of email bounce rates and provide useful tips for keeping them in check.

What is email bounce rate?

An email bounce rate is the percentage of emails that couldn’t be delivered from the total number of sent emails. Email bounce itself is a delivery failure, either temporary or permanent.

Let’s say you want to surprise a friend you haven’t seen for ages. You search for their address in your address book and head to their apartment. When you arrive, you find out that they don’t live there anymore. You go back home feeling frustrated.

Well, that’s what happens to your emails when they can’t reach your recipient’s email address. Sad bounced emails return back to you.

Generally, there are two types of email bounces:

• Soft bounce: a temporary issue with delivery. It usually means that there’s a problem with the recipient’s email server or mailbox. Typical causes include full inbox, server overload or error, and spam filters. Since soft bounces are temporary, mail servers will attempt to deliver emails again later.

• Hard bounce: a permanent delivery failure. Hard bounces have a greater impact on sender reputation and email deliverability. Common causes include invalid email addresses, improperly configured (or not configured) email authentication protocols, or blacklisted IPs. Unlike soft bounces, mail servers won’t attempt to resend hard-bounced emails.

Read this blog post for more information on the differences between soft and hard bounces.

How to calculate email bounce rate

To calculate the email bounce rate, we have to divide the number of bounces by the number of total sent emails. Then we have to multiply the result by 100 to calculate the percentage. So, the formula would be:

Bounce rate = number of bounced emails ÷ number of emails sent × 100

If you send 1,000 emails and 100 of them bounce, the bounce rate would be 10%.

Those who send mass emails will probably have a hard time calculating bounce rates manually. If you’re sending emails from an email service provider (ESP), you should have statistical data for bounced rates.

Mailtrap Email Sending, for instance, has in-depth actionable analytics with drill-down reports and helicopter-view dashboards. That also includes email bounce rate data.

As an example, let’s see how to check your email bounce rate in Mailtrap.

1. Sign into your account, choose Email Sending, and select ‘Stats’ in the left navigation panel.

2. There, you’ll see the overall bounce rate for all domains in a selected timeframe. With quick filters, you can see stats for a specific domain.

1. To explore trends, scroll down to find a dedicated chart for bounced rates. The critical threshold is 5% – the rates above that will be indicated with a red line.

1. By clicking bounced emails, you’ll be redirected to Email Logs to find the reasons behind each bounce.

2. It’s also possible to check bounce rates for different mailbox providers and categories and filter them for a specific domain, time frame, category, or provider.

Email bounce rate benchmark

So, what is a good email bounce rate? Based on cross-industry research, anything below 2% is considered to be a normal bounce rate. 2% to 5% is a warning level, while above 5% is critical.

Email providers regularly conduct research to figure out typical email bounce rates. However, those reports are usually based on the campaign data gathered from their users. While the scope of the research makes us believe that the results are objective, we should still take those numbers with a grain of salt.

With that in mind, we decided to provide several examples of reports that have found typical bounce rates. That way, we won’t rely on one source of data.

Mailchimp email marketing benchmarks and statistics

In 2019, Mailchimp created a comprehensive report on essential email marketing metrics, such as average open rates, click rates, soft and hard bounces, and unsubscribe rates. They analyzed campaigns with at least 1,000 recipients.

Mailchimp found that the Construction industry had the highest average hard bounce rate, amounting to 1.28%. The lowest, on the other hand, was in the Daily Deals/E-Coupons industry with 0.13%.

MailerLite email marketing benchmarks

MailerLite analyzed 2022 data from 40,000 accounts. They included the campaigns that were sent to at least 10 subscribers. As a result, their dataset included around 1M campaigns.

In their report, Publishing companies had the lowest bounce rates (0.2%), while the highest bounce rates (1.32%) were in Architecture and Construction industries.

Benchmark Email report

Benchmark email report analyzed a smaller group of users (≈7,470), and their numbers show a slightly different picture.

Advertising/Marketing/PR/Media/Design industries had critically high email bounce rates, averaging 12.27%. In their report, Retail/Consumer Services had the lowest average email bounce rate (6.08%).

Constant Contact average industry rates for emails

Constant Contact analyzes data from over 200 million emails each month. Their report shows higher bounce rates compared to that of Mailchimp and MailerLite as well:

• Legal Services – 16.27%

• Manufacturing and Distribution – 14.73%

• Real Estate – 12.72%

• Repair and Maintenance – 5.92%

We can make three main conclusions from the reports we saw above:

• The source of analysis makes a huge difference in average results;

• The acceptable email bounce rate is still below 2% regardless of industry averages;

• The bounce rates differ depending on the industry.

What causes high bounce rates?

High bounce rates for email marketing campaigns and transactional messages can have multiple causes:

• Old or poorly maintained subscriber lists including bought email lists, unverified email addresses, and lists full of inactive subscribers.

• Spammy subject lines or content

• Unreliable email infrastructure with blacklisted IPs, unauthenticated domains, and spam-abused systems

• Public domains such as @gmail.com or @yahoo.com.

How to decrease the email bounce rate? 6 tips to follow

Not all is lost if your email bounce rates are high. By taking the necessary measures, you can gradually reduce them. Here’s how to improve email bounce rate and keep it as low as possible.

Use legitimate practices while building email lists

Marketing email campaigns rely on email lists and building them requires a lot of time and effort. The easy way out is to purchase ready-made lists and blast out thousands of emails right away. But an easy way certainly doesn’t mean the best way.

Bought email lists usually contain spam traps. Those are recycled email addresses that are no longer in use by real recipients. If you send an email to such addresses, you’ll immediately be labeled as a spammer. As a result, your bounce rates will increase and email deliverability will suffer.

The good practice is to build permission-based email lists i.e. ask your users whether they want to receive marketing emails or not. This can be done by adding a consent checkbox in your sign-up forms. Double opt-in (sending a confirmation email after the user consents to receive marketing emails) is even better.

Showing up unannounced is creepy both in real life and in the world of emails.

All of these measures will reduce your chances of landing in spam folders and getting high bounce rates.

Clean up and validate your mailing list regularly

Email lists are like cars – you’ll face serious consequences unless you maintain them regularly. To do so, you should regularly go through your subscriber list and remove inactive users. Most marketing tools have the option to automate that process.

Another step you should take is validating your lists to remove invalid addresses. These are addresses that don’t exist anymore or have typos. Email bounce rate tools such as ZeroBounce, NeverBounce, Verifalia, etc. will help you check your email lists and keep valid email addresses in them. They won’t be 100% accurate, but they will help you maintain acceptable bounce rates.

Test your emails before sending them to intended recipients

Testing your emails before sending them to recipients is always a good idea. It will help you eliminate any sending issues beforehand and test email bounce rate to some extent. There are two ways to go about it: messing with dummy email accounts and using dedicated tools. We don’t recommend the first option because it requires too much effort and doesn’t provide comprehensive insights.

One tool you could use is Mailtrap Email Testing. It’s part of the Mailtrap Email Delivery Platform. Email Testing provides you with a Sandbox to inspect and debug your emails in a staging environment. As it captures all the SMTP traffic, you can safely check the email-sending capabilities of your app and see if your emails get delivered to the inboxes.

Try Mailtrap Email Testing for Free

Apart from that, Email Testing has a Spam Analysis feature that shows you Spam and Blacklist reports. By viewing those, you’ll see where your IP and domain reputation stands. If your spam score is high, it’s likely that your emails will bounce or get blocked by the recipient’s mail server.

Start Testing for Free

Your testing workflows can be a separate measure to send well-crafted emails or be part of email sending reputation audit. The latter is a comprehensive ‘investigation’ that reveals the main culprits behind your email deliverability. That way, you’ll know for sure what’s causing your bounce rates and work in that direction.

Alternatively, you could hire email deliverability consultants who will conduct the audit, provide feedback, and help you plan all the deliverability-related steps.

Send emails from a reliable email infrastructure

Sending emails from a reliable email infrastructure is a surefire way to reduce and prevent high bounce rates. It will also help you maintain good deliverability rates. The reason is simple: reputable ESPs have a good IP reputation for their shared IPs, as well as an option to use dedicated IPs if the sending volume is high enough. On top, they take strict security measures to keep the spammers at bay.

Typically, ESPs and sending solutions require you to authenticate your domains with SPF, DKIM, and DMARC records before you start sending. This adds to your domain’s credibility and lowers the chances of landing in spam folders. Not only that, Google and Yahoo now require regular and high-volume senders to have these records in place. You don’t have that option with free email accounts and email domains. Large volumes of emails coming from such addresses immediately raise the yellow flag (a.k.a. spam) among ISPs.

Using an ESP is sort of an industry-standard whether you’re sending email blasts, general marketing campaigns, or transactional emails.

One such software is Mailtrap Email Sending we mentioned above – the second solution offered by Mailtrap. It’s an email infrastructure to reach your recipients’ inboxes. This platform has RESTful API and SMTP services.

Try Mailtrap Email Sending for Free

To keep your bounce rates in check, Email Sending provides ready-made DNS records for authentication protocols. It runs regular security checks to prevent spam abuse and protect the reputation of shared IPs. As you start sending at least 100K emails a month, you get the option to use a dedicated IP included in your plan. Dedicated IPs have auto warm-ups to prevent email bounces and spam complaints.

Email Sending also has strict policies regarding bounce rates. If your emails soft bounce, the platform will attempt to send them 10 more times. If the outcomes are unsuccessful, the emails will be hard bounced and added to your stats.

Hard-bounced emails are added to suppression lists automatically to protect your deliverability. You can view and manage those in the ‘Suppressions’ tab, and examine the reasons for each bounce. While you can reactivate any suppressed email address, we strongly recommend against activating invalid addresses.

Start Sending for Free

Craft non-spammy email content

The spammy email content is another reason why your emails might get considered as spam and bounce. That’s why you should avoid spammy words (‘big bucks’, ‘free money’, ‘million dollars’, etc.) in your subject lines and copies.

Use A/B testing whenever possible. Whether you’re talking to new subscribers or trying to conduct surveys, it’s a good idea to test various portions of emails separately. Run A/B testing campaigns for subject lines, CTAs, email bodies, body formats, and other parts of your emails. That way, you’ll be sending the content your audience likes, which leads to fewer spam complaints.

Create and follow email marketing strategy

An email marketing strategy is a detailed roadmap for your campaigns. As it’s based on comprehensive research, it allows you to tailor your tactics and campaigns to your audiences. With a strategy, you won’t send random emails to random people. Each step will be carefully calculated, resulting in better open, click, and click-through rates. Good audience engagement improves your sender reputation and helps maintain low bounce rates.

Key takeaways

Let’s end this blog post with a few key takeaways:

• Email bounce rate affects your email deliverability

• To keep bounce rates low, you should avoid buying mailing lists and run permission-based email marketing

• Email list validation is a great way to reduce hard bounces

• Email infrastructure impacts your bounce rates

• It’s important to develop an email marketing strategy and run high-quality campaigns.

And with this good-ol’ meme, farewell folks!

We appreciate the you chose this article to find out what is average email bounce rate. If you want to find more interesting content on related topics, follow Mailtrap blog!

I’ve recently explored a few approaches and will share my experience in this tutorial. I’ll cover native methods such as unit tests + aiosmtpd, Python’s subprocess function, as well as unit tests’ mock object library.

I’ll also demonstrate how to integrate and test emails in Python with Mailtrap Email Testing.

Native ways of testing emails in Python

Let’s start with the native ways of testing Python emails.

Using unit tests and aiosmtpd

Aiosmtpd is a library that lets you set up a local SMTP (Simple Mail Transfer Protocol) server. This will create a testing environment and handle email traffic internally. So, your test emails won’t reach the recipients. Refer to aiosmtpd’s GitHub page for more information.

I’ll create a test for a simple text email.

Prerequisites:

• Python 3.7 and up.

Note: I added the code snippets below in the tests.py file.

To install aiosmtpd, run the pip install aiosmtpd command.

Run the server with python -m aiosmtpd -n command.

I’ll use the unit test framework, a standard library in all versions of Python since 2.1, and the smtplib library. smtplib module uses standard RFC 821 protocol for formatting messages.

from unittest import TestCase
import smtplib

Create a class that will inherit the unit test from the TestCase object and configure the test case.

class EmailTestCase(TestCase):
    def test_send_email(self):
        sender_email = "your_email@gmail.com"
        receiver_email = "receiver_email@example.com"
        message = "This is a test email."

The sender_email and receiver_email variables can be populated with sample data as we simulate email sending. The message variable should contain the desired email body.

The next step is to send a test email using the smtplib.

with smtplib.SMTP(host="localhost", port=8025) as server:
            server.ehlo()
            server.sendmail(sender_email, receiver_email, message)

Here, we create a new instance of an SMTP client. By default, the server works on localhost with port number 8025. We also initiated an SMTP handshake with EHLO and added the sendmail method to send the emails. The sendmail method takes three arguments – sender_email, receiver_email, and message.

The script is now ready. Here’s the full sample:

from unittest import TestCase
import smtplib

class EmailTestCase(TestCase):
    def test_send_email(self):
        sender_email = "your_email@gmail.com"
        receiver_email = "receiver_email@example.com"
        message = "This is a test email."

        with smtplib.SMTP(host="localhost", port=8025) as server:
            server.ehlo()
            server.sendmail(sender_email, receiver_email, message)

To run the Python code, use the Run button.

If the test passes, you’ll see a message similar to the one below.

You’ll also see that the email was sent in the terminal.

Limitations of this approach

While this approach can be useful for testing simple email-sending scripts, I found that it has multiple limitations:

• Each time I ran the tests, I had to type aiosmtpd manually. This is okay for small and occasional tests, but it’s a huge pain during scaled testing.

• As we’re simulating the process of sending emails, we can’t test real-world email delivery.

• This setup doesn’t allow for testing high email load.

• It doesn’t allow testing advanced email functionalities or features, such as client rendering, for example.

Using Python’s subprocess function with unit tests and aiosmtpd

One way to automate processes while using unit tests and aisosmtpd is Python’s subprocess function. It allows us to run an external program from the Python script.

I first had to import the subprocess function and time module to improve and enhance the previous script. I’ll use the latter to wait for a few seconds before the server is ready.

from unittest import TestCase
import smtplib
import subprocess
import time

Then, I added the setUp method. It prepares the environment to run the server. subprocess.Popen function will execute the command in a new process.

In this case, the command is exec python -m aiosmtpd -n, meaning that the server will run in a new process.

shell-True will allow us to execute the command using the shell. We won’t have to create a new terminal. Rather, the process will run in the background.

As mentioned, time.sleep(2) will pause the execution of the script for 2 seconds to give the server enough time to be ready.

def setUp(self):
    self.process = subprocess.Popen(args='exec python -m aiosmtpd -n', shell=True)
    time.sleep(2)

The next step is to add a tearDown method, which will terminate the subprocess and wait for the process to finish termination.

def tearDown(self):
    self.process.kill()
    self.process.wait()

The test itself is essentially the same, but I added one more assertion. It checks if the server is working and the socket is open.

self.assertIsNotNone(server.sock)

Here’s the complete code sample:

from unittest import TestCase
import smtplib
import subprocess
import time

class EmailTestCase(TestCase):
    def setUp(self):
        self.process = subprocess.Popen(args='exec python -m aiosmtpd -n', shell=True)
        time.sleep(2)

    def test_send_email(self):
        sender_email = "your_email@gmail.com"
        receiver_email = "receiver_email@example.com"
        message = "This is a test email."
        with smtplib.SMTP(host="localhost", port=8025) as server:
            server.ehlo()
            server.sendmail(sender_email, receiver_email, message)
            self.assertIsNotNone(server.sock)

    def tearDown(self):
        self.process.kill()
        self.process.wait()

At this point, we can run the script with the Run button.

The tests were successful, meaning the server was turned on and off as expected.

Running the script from the console

As you’ll notice, I used the Run button to run the scripts in the previous examples. I’ll add the if statement to run the code from the console, modify the unit test import, and reference the unittest.TestCase with the EmailTestCase class definition.

import unittest
import smtplib
import subprocess
import time

class EmailTestCase(unittest.TestCase):

    def setUp(self):
        self.process = subprocess.Popen(args='exec python -m aiosmtpd -n', shell=True)
        time.sleep(2)

    def test_send_email(self):
        sender_email = "your_email@gmail.com"
        receiver_email = "receiver_email@example.com"
        message = "This is a test email."

        with smtplib.SMTP(host="localhost", port=8025) as server:
            server.ehlo()
            server.sendmail(sender_email, receiver_email, message)
            self.assertIsNotNone(server.sock)

    def tearDown(self):
        self.process.kill()
        self.process.wait()

if __name__ == '__main__':
    unittest.main()

With the updated setup, we can now run the code directly from the console using the python tests.py command.

Testing if the script can read files

The last modification in the script was to enable it to read emails from the file. This would allow me to test if the variables in the template were substituted correctly. I went with the simple setup once again.

So, I created a new template file with only a message variable.

I went back to the tests.py file and added a with statement which would be responsible for opening and closing files.

with open('template.html') as file:
    template = file.read()

Using the format function, I added the message to the template.

template = template.format(message=message)

And inserted the template into the sendmail function.

server.sendmail(sender_email, receiver_email, template)

The whole script will look something like this:

import unittest
import smtplib
import subprocess
import time

class EmailTestCase(unittest.TestCase):

    def setUp(self):
        self.process = subprocess.Popen(args='exec python -m aiosmtpd -n', shell=True)
        time.sleep(2)

    def test_send_email(self):
        sender_email = "your_email@gmail.com"
        receiver_email = "receiver_email@example.com"
        message = "This is a test email."

        with open('template.html') as file:
            template = file.read()

        template = template.format(message=message)
        with smtplib.SMTP(host="localhost", port=8025) as server:
            server.ehlo()
            server.sendmail(sender_email, receiver_email, template)
            self.assertIsNotNone(server.sock)

    def tearDown(self):
        self.process.kill()
        self.process.wait()

if __name__ == '__main__':
    unittest.main()

Run the code with python test.py and check the output. The message variable was replaced correctly, so the test was successful.

Limitations of this approach

Similar to using aiosmtpd and unit tests, this expanded approach also has its limitations:

• Doesn’t allow for testing how complex HTML will render on mobile or desktop devices;

• Doesn’t allow for deliverability testing;

• Doesn’t allow for checking client support for HTML emails;

• Doesn’t allow for testing the communication between the script and external mail servers;

• Relies on aiosmtpd and port 8025. Tests may fail if the server isn’t set up correctly.

Using the unit test’s mock object library

Another option for testing emails in Python natively is the unit test’s mock object library. It lets you mock the SMTP server connection without sending the emails.

Here’s the script:

import unittest
from email.mime.text import MIMEText
from unittest.mock import patch
import smtplib

def send_email(server, port, subject, message, from_addr, to_addr):

    smtp_user = 'username'
    smtp_password = 'password'
    msg = MIMEText(message)
    msg['From'] = from_addr
    msg['To'] = to_addr
    msg['Subject'] = subject
    with smtplib.SMTP(server, port) as server:
        server.starttls()
        server.login(smtp_user, smtp_password)
        server.send_message(msg)
class TestEmailSending(unittest.TestCase):
    @patch('smtplib.SMTP')
    def test_send_email(self, mock_smtp):
        # Arrange: Setup our expectations
        subject = "Test Subject"
        message = "Hello, this is a test."
        from_addr = 'from@example.com'
        to_addr = 'to@example.com'
        server = "sandbox.smtp.mailtrap.io"
        port = 587
        # Act: Call the send_email function
        send_email(server, port, subject, message, from_addr, to_addr)

        # Assert: Check if the right calls were made on the SMTP object
        mock_smtp.assert_called_with(server, port)
        instance = mock_smtp.return_value.__enter__.return_value
        instance.send_message.assert_called_once()
        call_args = instance.send_message.call_args[0]
        sent_email = call_args[0]

        # Verify the email content
        self.assertEqual(sent_email['Subject'], subject)
        self.assertEqual(sent_email['From'], from_addr)
        self.assertEqual(sent_email['To'], to_addr)
        self.assertEqual(sent_email.get_payload(), message)

if __name__ == '__main__':
    unittest.main()

The provided code defines a function and includes a test class, TestEmailSending, using Python’s unit test framework to test this function.

The send_email function takes server details, subject, message body, sender’s address, and recipient’s address as parameters, creates an email (MIMEText) object with these details, and then logs into an SMTP server to send it.

In the test case, the smtplib.SMTP class is mocked using the unittest.mock.patch, allowing the test to verify that the SMTP server is called with the correct parameters without actually sending an email.

The test checks if the send_message method of the SMTP instance is called correctly and asserts that the email’s subject, from address, to address, and payload match the expected values.

Limitations of this approach

• The mock object library isn’t sufficient for detecting issues with implementation;

• Doesn’t allow for checking client support for HTML emails;

• Doesn’t allow for testing how complex HTML will render on mobile or desktop devices.

How to test emails in Python with Mailtrap via SMTP

To address the limitations of the native methods, I decided to use Mailtrap Email Testing. It’s an Email Sandbox that provides a safe environment for inspecting and debugging emails in staging, QA, and dev environments.

I used Email Testing to run functional and deliverability tests, check email formatting, analyze the content for spam, check attachments, and test error handling.

You’ll need an account to use it, and you can quickly create it by opening the signup page. Once the account is up and running, we can go straight to testing.

Functional testing

We’ll need a slightly different script in this case. Create a new EmailTestCase class and add sample data. Here, test_mailtrap is a method that will send a test email to Mailtrap.

import unittest

class EmailTestCase(unittest.TestCase):

    def test_mailtrap(self):
        sender_email = 'sender@example.com'
        recipient_email = 'recipient@example.com'
        subject = 'Test Email'
        body = 'This is a test email sent from the SMTP server.'

The next step is to import the built-in EmailMessage object.

from email.message import EmailMessage

Using it, we’ll build a message and add the sample data to it.

msg = EmailMessage()
msg['From'] = sender_email
msg['To'] = recipient_email
msg['Subject'] = subject
msg.set_content(body)

The last step is to connect to Mailtrap Email Testing’s fake SMTP server. For that, I’ll use smtplib and the with statement. At this point, I’ll need Email Testing’s SMTP credentials. To access them, go to Email Testing → My Inbox → SMTP Settings and click Show Credentials.

Copy the Host, Username, and Password, and return to the Python project. Create a new instance of the SMTP client and connect to the server using the host and port.

Call the server.login method and pass a username and password to it.

with smtplib.SMTP(host="sandbox.smtp.mailtrap.io", port=2525) as server:
    server.login(user="your_username", PASSWORD)
    server.send_message(msg)

Note: Your_username is a placeholder. You should add your actual username here.

For security reasons, I’ve stored the password in a separate folder. So, I’ll import it.

from variables import PASSWORD

The email-testing script is now ready.

import unittest
import smtplib

from email.message import EmailMessage

from variables import PASSWORD

class EmailTestCase(unittest.TestCase):

    def test_mailtrap(self):
        sender_email = 'sender@example.com'
        recipient_email = 'recipient@example.com'
        subject = 'Test Email'
        body = 'This is a test email sent from the SMTP server.'
        msg = EmailMessage()
        msg['From'] = sender_email
        msg['To'] = recipient_email
        msg['Subject'] = subject
        msg.set_content(body)

        with smtplib.SMTP(host="sandbox.smtp.mailtrap.io", port=2525) as server:
            server.login(user="your_username", PASSWORD)
            server.send_message(msg)

if __name__ == '__main__':
    unittest.main()

I ran the code with the python tests.py command. And the email arrived in the Email Testing inbox within seconds.

Test results:

• Verified whether the EmailMessage object was correctly populated with the sender’s email, recipient’s email address, subject, and body text. I checked the body by going to the Text tab and verified from, to, and subject from the Tech Info and Raw tabs.

• Revealed that the code established an SMTP connection successfully.

• Revealed that the SMTP authentication process was correct.

• Confirmed that the text message formatting was correct and, as a result, it was successfully sent through the SMTP server.

• Verified that send_message method of the smtplib.SMTP class was called with the correct parameters.

Checking email formatting and HTML code

Next up in my tests were:

• Checking whether the message body in plain text and HTML versions would be the same;

• Checking the mobile, desktop, and tablet previews;

• Analyzing HTML code to see if it contained any unsupported elements.

For that, I sent a simple HTML email to my virtual inbox using the following lines of code. I used an email-sending script, not a unit test in this case, since the email would still get captured in the inbox. For more information on sending HTML emails from Python, refer to this blog post.

import smtplib
from email.mime.text import MIMEText
from email.mime.multipart import MIMEMultipart

port = 2525
smtp_server = "sandbox.smtp.mailtrap.io"
login = "your_username"
password = "your_password"

sender_email = "sender@example.com"
receiver_email = "recipient@example.com"
message = MIMEMultipart("alternative")
message["Subject"] = "HTML test"
message["From"] = sender_email
message["To"] = receiver_email

# write the text/plain part
text = """\
Hi,
Check out the new post on the Mailtrap blog:
SMTP Server for Testing: Cloud-based or Local?
https://blog.mailtrap.io/2018/09/27/cloud-or-local-smtp-server/
Feel free to let us know what content would be useful for you!"""

# write the HTML part
html = """\
<html>
  <body>
    <p>Hi,<br>
      Check out the new post on the Mailtrap blog:</p>
    <p><a href="https://blog.mailtrap.io/2018/09/27/cloud-or-local-smtp-server">SMTP Server for Testing: Cloud-based or Local?</a></p>
    <p> Feel free to <strong>let us</strong> know what content would be useful for you!</p>
  </body>
</html>
"""

# convert both parts to MIMEText objects and add them to the MIMEMultipart message
part1 = MIMEText(text, "plain")
part2 = MIMEText(html, "html")
message.attach(part1)
message.attach(part2)

with smtplib.SMTP("sandbox.smtp.mailtrap.io", 2525) as server:
    server.login(login, password)
    server.sendmail(
        sender_email, receiver_email, message.as_string()
    )

print('Sent')

Test results:

• Verified that the HTML message wasn’t broken on mobile, desktop, or tablet views.

• Confirmed that the text content was the same as the HTML content.

• Found out that my email contained one element that email clients would support partially or wouldn’t support at all.

Deliverability testing

To extend my tests, I opened the Spam Analysis tab. This showed the Spam Report with spam score, as well as spam points with descriptions. This is useful for improving the template if it exceeds the threshold of 5. Spam tests are run with the help of the SpamAssassin filter.

Test results:

• Verified that the spam score of the email was below the threshold of 5.

• Checked the Blacklist Report to see if my domain would be listed in any of the blocklists.

• Verified that my emails would be delivered to the recipients’ inboxes if I were to send them on prod.

Checking the attachments

I also wanted to see if the email-sending script would attach, encode, and send attachments correctly. Attachments are MIME objects. Encoding implies using a base64 module that encodes all binary data with ASCII characters.

I simply added Email Testing SMTP credentials to this script and waited for the email to arrive in the virtual inbox.

import smtplib

from email import encoders
from email.mime.base import MIMEBase
from email.mime.multipart import MIMEMultipart
from email.mime.text import MIMEText

port = 2525
smtp_server = "sandbox.smtp.mailtrap.io"
login = "your_username" 
password = "your_password"

subject = "An example of boarding pass"
sender_email = "mailtrap@example.com"
receiver_email = "new@example.com"

message = MIMEMultipart()
message["From"] = sender_email
message["To"] = receiver_email
message["Subject"] = subject

body = "This is an example of how you can send a boarding pass in attachment with Python"
message.attach(MIMEText(body, "plain"))

filename = "yourBP.pdf"

with open(filename, "rb") as attachment:
    part = MIMEBase("application", "octet-stream")
    part.set_payload(attachment.read())

encoders.encode_base64(part)

part.add_header(
    "Content-Disposition",
    f"attachment; filename= {filename}",
)

message.attach(part)
text = message.as_string()

with smtplib.SMTP("sandbox.smtp.mailtrap.io", 2525) as server:
    server.login(login, password)
    server.sendmail(
        sender_email, receiver_email, text
    )
print('Sent')

This code snippet sends an email with a PDF attachment. It assumes that the file is located in the same directory in which you run your Python script. The attach method adds the attachment to the message and converts it into a string.

With a similar method, you could also test other types of attachments. In that case, you should simply use an appropriate class such as email.mime.audio.MIMEAudio or email.mime.image.MIMEImage. Read Python docs for more information.

This is what it will look like in the Email Testing inbox.

Test results:

• Verified that the script sends an email with an attachment successfully;

• Verified that the file path was configured properly.

Testing error handling

The final test I ran with SMTP was to check error handling. I sent emails using the smtplib module once again, but this time with try and except blocks.

import smtplib
from socket import gaierror

port = 2525
smtp_server = "sandbox.smtp.mailtrap.io"
login = "your_username"
password = "your_password"
sender = "sender@example.com"
receiver = "recipient@example.com"
message = f"""\
Subject: Test email
To: {receiver}
From: {sender}

This is my test message with Python."""

try:
    with smtplib.SMTP(smtp_server, port) as server:
        server.login(login, password)
        server.sendmail(sender, receiver, message)
    print('Sent')
except (gaierror, ConnectionRefusedError):
    print('Failed to connect to the server. Bad connection settings?')
except smtplib.SMTPServerDisconnected:
    print('Failed to connect to the server. Wrong user/password?')
except smtplib.SMTPException as e:
    print('SMTP error occurred: ' + str(e))

This script will:

• Catch gaierror and ConnectionRefusedError exceptions if there are issues connecting to the SMTP server;

• Catch smtplib.SMTPServerDisconnected exception if the server disconnects unexpectedly (when login credentials are invalid, for example);

• Catch smtplib.SMTPException exception for all the other SMTP errors.

• Print the specific error message received from the server.

Start Testing Python Emails with Mailtrap

How to test emails in Python with Mailtrap via API

Mailtrap Email Testing also provides an option to test your emails using API. It’s based on REST principles and returns calls as JSON objects. All the details about the Email Testing API are covered in the API docs.

To make API requests, you’ll need your API token and inbox ID.

1. Go to Settings → API Tokens, and click Add Token.

1. Create a token for the desired project and inbox.

1. Once the token is ready, go to the desired inbox. Check the URL – the inbox ID is the 7-digit number between inboxes/ and /messages.

A sample API request looks something like this:

import http.client

conn = http.client.HTTPSConnection("sandbox.api.mailtrap.io")

payload = "{\n  \"to\": [\n    {\n      \"email\": \"john_doe@example.com\",\n      \"name\": \"John Doe\"\n    }\n  ],\n  \"cc\": [\n    {\n      \"email\": \"jane_doe@example.com\",\n      \"name\": \"Jane Doe\"\n    }\n  ],\n  \"bcc\": [\n    {\n      \"email\": \"james_doe@example.com\",\n      \"name\": \"Jim Doe\"\n    }\n  ],\n  \"from\": {\n    \"email\": \"sales@example.com\",\n    \"name\": \"Example Sales Team\"\n  },\n  \"attachments\": [\n    {\n      \"content\": \"PCFET0NUWVBFIGh0bWw+CjxodG1sIGxhbmc9ImVuIj4KCiAgICA8aGVhZD4KICAgICAgICA8bWV0YSBjaGFyc2V0PSJVVEYtOCI+CiAgICAgICAgPG1ldGEgaHR0cC1lcXVpdj0iWC1VQS1Db21wYXRpYmxlIiBjb250ZW50PSJJRT1lZGdlIj4KICAgICAgICA8bWV0YSBuYW1lPSJ2aWV3cG9ydCIgY29udGVudD0id2lkdGg9ZGV2aWNlLXdpZHRoLCBpbml0aWFsLXNjYWxlPTEuMCI+CiAgICAgICAgPHRpdGxlPkRvY3VtZW50PC90aXRsZT4KICAgIDwvaGVhZD4KCiAgICA8Ym9keT4KCiAgICA8L2JvZHk+Cgo8L2h0bWw+Cg==\",\n      \"filename\": \"index.html\",\n      \"type\": \"text/html\",\n      \"disposition\": \"attachment\"\n    }\n  ],\n  \"custom_variables\": {\n    \"user_id\": \"45982\",\n    \"batch_id\": \"PSJ-12\"\n  },\n  \"headers\": {\n    \"X-Message-Source\": \"dev.mydomain.com\"\n  },\n  \"subject\": \"Your Example Order Confirmation\",\n  \"text\": \"Congratulations on your order no. 1234\",\n  \"category\": \"API Test\"\n}"

headers = {
    'Content-Type': "application/json",
    'Accept': "application/json",
    'Api-Token': "your_api_token"
}

conn.request("POST", "/api/send/your_inbox_id", payload, headers)

res = conn.getresponse()
data = res.read()

print(data.decode("utf-8"))

Once again, examine the API docs and this page, in particular, to learn how to send API requests in Python (or other languages), send a sample request, and check out the sample response.

Wrapping up

Python’s native methods are sufficient to test email-sending and run other functional tests. However, to check the spam score, the connection with external servers, or HTML/CSS, you’ll need a dedicated testing tool such as Mailtrap Email Testing.

If you want to learn more about email-sending and testing in Python, then check out our blog posts:

• How to Send an Email in Python

• How to Send Emails in Python with Gmail

• Python Options to Validate Email

• Mail Merge with Python

• How to Send an Email With Yagmail

We’ve also covered sending emails in popular Python frameworks, such as Django and Flask.

Keep an eye on our blog as we publish more testing topics, such as how to test emails, email testing for beginners, email sandboxing, and others.

Don’t let Python’s snake crush your emails. Good luck!

Thank you for choosing this article! To discover more articles about testing emails using Python follow Mailtrap blog!

For about a month, I tested the most popular options on the market to find the best email preview tools. I split them into two segments: tools tailored to developers’ needs and tools created with marketers in mind.

Below I’ll share my findings and personal experience and add to that with valuable information gathered from other users.

Selection criteria for email rendering and preview tools

Based on the role, requirements for email rendering and preview tools will vary significantly. So, I decided to compile different criteria for developers and marketers.

Choosing email rendering tools for software engineers

To find the most functional email rendering tools for software developers, I used the following criteria:

• A wide selection of email clients. This is an absolute must, as recipients view emails from various webmail and desktop clients.

• Ease of integration. The ability to integrate the tool into an email-sending script or project for accurate and comprehensive testing.

• Automated testing. With this feature, the checks will be performed on every email before they are sent.

• The ability to test attachments, broken links, and loading speed.

• HTML code checking. This ensures the code will be rendered accurately across email clients.

• Mail merge testing. The ability to verify merge fields and ensure personalized variables are correct.

• Sandbox environment. A virtual environment that will capture your test emails and prevent them from reaching your recipients.

• Spam checker. This will locate parts of your email (be it body, headers, or SMTP transaction info) that can be seen as spammy and harm your email deliverability.

Choosing email preview software for marketers

Unlike developers, marketers are mainly concerned with email design. So, I mainly focused on that in my selection criteria:

• A wide selection of email clients. This one is common among the two groups.

• The ability to preview emails across different devices. Modern emails should be mobile, desktop, and tablet-optimized.

• Ease of integration. However, this time we’re looking for integration options that don’t require coding (plugins for Email Service Providers or CRM platforms, ready-made apps or platforms, etc.).

• Spam and blacklist checker. Ideally, this feature should check the email for common spam triggers, test it against popular spam filters, and provide information about blacklisted IP addresses.

• The ability to check the buttons and links.

• Value for money. We believe this criterion is more indicative of the products’ worth than affordability. It shows how many features are included in the set pricing and how many of them are limited to the higher-paying plans.

Best email preview and email rendering tools

Before we dive into the reviews, let’s take a look at TL;DR comparison charts for the chosen email preview and email rendering tools.

Email rendering tools for software engineers: comparison chart

Email preview tools for marketers: comparison chart

Note: All prices are monthly rates. Most tools have discounts on annual subscriptions. Pricing is up-to-date at the time of publishing.

3 Email rendering tools for software engineers and QAs

Now it’s finally time to share my findings.

To run the tests, I needed an HTML template. So, I went straight to Mailtrap Email Sending’s transactional email templates feature. I found a great Welcome Email template created by one of my colleagues and got down to business.

Mailtrap

Mailtrap is an email delivery platform that has both Email Sending and Email Testing solutions. For the purposes of this article, I’ll be focusing on Email Testing.

Email Testing is an Email Sandbox that captures all the SMTP traffic and provides a safe environment to analyze and debug your emails.

Creating an account and getting started is super straightforward. You just sign up, verify your email, and then you’ve got access to the platform.

I then went to the Email Testing tab, accessed My Inbox, tweaked the cURL with the HTML template, and sent the email.

Within seconds, I had the email in the virtual inbox. I didn’t have to use dummy email addresses or borrow real ones from my friends. Since the tool leverages the fake SMTP server, sample emails were enough.

First, I checked mobile, desktop, and tablet previews to test how the email looks on these devices.

Then, I navigated to the HTML Source tab. I found that the HTML contained elements that some email clients wouldn’t support. To examine the client support level further, I opened the HTML Check tab.

In its original form, the recipients who used Apple Mail on Desktop, Mobile, or the Web would have no trouble accessing my emails (the support was 100%). But the client support level was 77% for Gmail, 84% for Outlook, 71% for Yahoo! Mail, and 85% for other email clients.

One last step of the HTML check was to compare the text and HTML versions of the email. In this case, they matched.

I was quite impressed with the results I got from the HTML checker.

I didn’t forget to click the buttons to ensure the links weren’t broken.

Finally, I headed over to the Spam Analysis tab. The score was 1.6, which meant I had nothing to worry about. I scrolled down to the Blacklist Report to verify that my IP wasn’t blacklisted.

What I found particularly interesting was that apart from the email template, you can also test email app load, email forwarding, BCC, and message headers. It’s possible to use Email Testing API with popular automation testing tools and software, including Selenium, Cucumber, Protractor, etc.

Features

• HTML Check tab to check the emails for elements that won’t be supported (or be partially supported) by email clients

• Spam Analysis to view the spam score and check the Blacklist report

• SMTP and API integration options with code samples and official SDKs

• A custom inbox email address with the ability to create aliases to simulate sending emails to recipients and test email app load (available starting from the Business plan)

• Sandbox environment to avoid spamming recipients.

• The ability to check the links and attachments.

Pros

• Can easily be integrated with the most popular programming languages and frameworks

• The tool is well-documented, making it easier to get started

• Tests can be performed in bulk

• Makes it possible to not only analyze the template but also test email functionality

Cons

• Email previews are limited to mobile, desktop, and tablet. No client preview is available.

Pricing

Mailtrap Email Testing has a generous free tier with the ability to test up to 100 emails per month. The free tier includes 1 inbox, an inbox capacity of 50 emails, and a threshold of 5 emails per 10s.

Paid plans start from $14.99 (Individual plan) a month and provide access to advanced features and higher limits. You’ll find detailed pricing information here.

Access to customer support is equal for every user regardless of the plan they are using, while priority support is available starting from the Individual tier.

What other users think (based on G2 and Capterra)

Mailtrap has 4.8 stars on G2 and 5 stars on Capterra.

Most users found Email Testing easy to set up and use. They were satisfied with the available features and praised how supportive the customer service was.

Some users were displeased that inbox email addresses are limited to higher-paying plans, while others wished to see more storage capacity on free and lower-tier plans.

Try Mailtrap for Free

Mailosaur

The second tool I tested was Mailosaur. It’s an end-to-end email testing solution very similar to Mailtrap Email Testing.

I created an account and started exploring the interface.

I clicked Begin Email Testing and I was taken to a step-by-step integration wizard. You have three options:

• Send an email to the generated email address (or its alias);

• Integrate Mailosaur with SMTP;

• Let the platform create a sample plain text email.

For the initial test, I went with the first option as it seemed to be the fastest. I copied the email address and sent an HTML email to it. I clicked the Inbox in the left navigation panel and the email had already arrived.

At this point, I was curious to see what elements of the email I could check. In the screenshot above, you can see a navigation panel on the right-hand side. Available options are Links, Codes (i.e. verification codes extracted from the email), Attachments, HTML Source, API Response, Screenshots (i.e. email client previews), Deliverability Report, and Original.

I played around with Links, Codes, and Attachments, and all of them yielded the expected results.

Then I opened the HTML Source tab which wasn’t what I expected it to be. The source code didn’t have any formatting, spacing, or indentations, making it hard to read and analyze. And unlike Mailtrap, it didn’t contain any information on supported/unsupported elements.

A nice surprise was the API Response tab which can potentially be quite useful to test how your API requests are performing.

The biggest jam of all was the Screenshots tab which enables you to generate screenshots for desired email clients. During the free trial, 85 email client previews were available (including dark mode and even iPhone 15 models). I played around with most of them and I must say, I was impressed. You can see some of the results in the image below.

Email previews from Mailosaur: (from left to right) Gmail App on iOS 14.2, Gmail App with Dark Mode on iOS 14.3, and iPhone 15

The next stop was the deliverability report. The platform scans your email to check if SPF, DKIM, and DMARC are configured properly for your domain. It also provides SpamAssassin results and checks the email for content indicators (‘spam triggers’). Mailosaur lists DNS records as well to help you detect issues and correct them

Finally, Original (EML) provides information about the email transaction and includes all the headers.

Another feature that I found quite useful was the ability to design and preview emails right within the platform. You simply copy and paste (or write from scratch) the HTML code and you immediately see what it looks like. As you edit the code, you can see the changes in design in live mode.

This feature includes email client screenshots as well.

I used more complex templates to test out this feature and I can safely say that Mailosaur really excels at previews.

Features

• SMTP and API integration with SDKs for Playwright, Cypress, Node.js, Python, Java, .NET, Ruby, PHP, and Go

• SMS Testing for companies that use SMS in addition to emails in their marketing communications

• Sandbox environment

• The ability to test multi-factor authentication

• Email previews for 85 email clients

• HTML code editor with real-time preview

Pros

• Easy integration and setup thanks to the step-by-step wizard and various integration options.

• A wide selection of email clients.

• The ability to create automated tests

• In addition to basics, documentation covers common testing scenarios

Cons

• The HTML Source tab doesn’t provide useful information

Pricing

Mailosaur doesn’t have a free tier, but they do offer a 14-day free trial for all pricing tiers. The cheapest plan starts at $9 per month for 50 emails/day which can be upgraded up to 1,000 for an additional fee.

Mailosaur seems to have only annual billing at this point, which can be inconvenient for individuals or small teams.

Advanced features such as automatic forwarding, connecting via POP3, or SMS testing are available starting from the Business plan.

What other users think (based on G2 and Capterra)

Mailosaur has a 4.9-star rating on G2 and a 4.8-star rating on Capterra.

Most users reported that the platform was easy to integrate with modern QA automation tools, the UI was intuitive, and it was easy to search the messages.

The common complaint they had was the occasional inability of Mailosaur API to read emails and the per-user surcharge on pricing plans.

HTML Email Check

HTML Email Check is a bit different from the previous tools. Instead of being a ‘traditional’ HTML email preview tool, it’s more like a markup validation software. While it does have the visual testing feature, it’s built to analyze the HTML, XHTML, and CSS in your code.

And when I say it’s an HTML code checker, I mean it. This feature is free, and you don’t even have to create an account.

All you have to do is paste your HTML code into the dedicated field, click Check Code, and you’ll immediately see a list of issues in your script. This list also includes the number of lines that were affected, as well as possible fixes.

As I scrolled down and examined the recommendations closely, I noticed that the check results included information about the affected email clients. So, some parts of my HTML code (<strong> and <div> tags) wouldn’t be supported by Gmail, Microsoft Outlook, and Yahoo! Mail.

My email had way more issues when it came to CSS. And I had a whole list of email clients along with short explanations. I found these short explanations useful, particularly for junior developers learning HTML and CSS.

The rest of the tests and features are paid. Once you upgrade to one of the plans, you get access to font, image, and link validation, as well as spam checker, visual tester, dark mode, accessibility validation, etc.

Accessibility validation is an important feature and I was very happy to see it on this platform. It checks your code for alt text and tags, provides recommendations on font size and readability, and validates dark mode. And all those tests are client-specific.

What’s not client-specific is the visual tester. I was able to test the email template on desktop, tablet, and mobile devices in portrait and landscape modes. But I couldn’t preview them in email clients the way I did with Mailosaur.

Overall, I really enjoyed using HTML Email Check as it has a minimal learning curve. In terms of creating an error-free HTML code, this tool is very hard to beat.

Features

• Accessibility and dark mode validation

• Comprehensive HTML and CSS checker

• Spam checker

• The ability to send test emails to real inboxes

Pros

• Runs validation checks against the most popular email clients

• Has an HTML email previewer

• Can be used in conjunction with your email service provider (ESP)

• Very easy to get started and use

• Provides recommendations to debug your HTML code

Cons

• The free email checker is limited in functionality

• Message preview is device-based

Pricing

HTML Email Check has three pricing tiers. The Standard plan costs $23.95 a month and provides access to core validation features. The Business plan will cost you $35.95 a month, but you’ll be able to use a spam checker, visual tester, email sending for test emails, and validation expert.

There’s also an Enterprise plan for $59.95 a month with access to accessibility, dark mode, and mobile validation, a developer checklist, 24/7 priority support, and a visual tester inspector.

HTML Email Check doesn’t have a free trial for the paid plans, but it does offer limited free email testing features.

What other users think (based on G2 and Capterra)

At the time of writing, HTML Email Check doesn’t have any reviews on G2 or Capterra.

4 Email preview tools for marketers

Below I’ll be diving into 4 email preview tools for marketers that proved to be most reliable and effective.

Litmus

Litmus has two tools for previewing emails: PutsMail (the free option) and Litmus itself (the paid version).

The free email preview tool is quite limited. You can use it to inline CSS or send test emails to sample email addresses you own, but I didn’t find it usable, especially compared to Litmus itself.

So, in this review, I’ll be concentrating on Litmus.

Getting started with this tool is quite easy – you just create an account, activate your free trial or subscription by entering your card details, and you’re ready to use the features right away.

To start testing, you can use one of their templates or build your own email from scratch. I chose the second option as I wanted to test a particular HTML email. This takes you to a builder, which previews the email as you enter the script.

The preview options are quite extensive and include dark mode, mobile and desktop views, image toggle, and different visual impairment options.

As expected, the Preview tab shows email previews for various email clients. But the information in the QA Checks tab is way more interesting.

Litmus shows your template’s preview text example and provides recommendations. For example, my template lacked preview text, so Litmus recommended adding it as the first element in the body and keeping the preview text length above 90 characters.

Note: Email preview text (or preheader text) is the short ‘description’ shown under the subject line in most email clients.

QA checks also included accessibility and loading speed tests. These were initial tests that allow you to improve your template as you’re building it.

As you move to the Previews & QA tab, you can see those test results (and some additional tests) in more detail.

Apart from the mentioned components, Litmus will check the subject line, links, and tracking, and run the spam tests.

Email Guardian is a great addition to these features. It monitors major email clients and notifies you of any important changes. This way, you can continuously improve selected templates to avoid issues with deliverability, accessibility, or rendering.

What I liked the most was the ability to sync Litmus with your ESP to test email marketing campaigns automatically. Integration options include HubSpot, Mailchimp, Campaign Monitor, Salesforce Marketing Cloud, and others.

On the downside, the platform can get a bit slow at times, especially while loading previews.

Features

• Integration with popular ESPs to test templates automatically

• Email Guardian that monitors email clients

• Real-time preview for more than 90 email clients

• Code and drag-and-drop template builder

• Extensive accessibility tests for various visual disabilities

Pros

• Easy-to-use, intuitive UI

• No coding is required (unless you’re building an HTML template script from scratch)

• Integration with collaboration tools

• An email testing checklist for building perfect emails

Cons

• ESP and code editor integrations are available only for higher-paying plans

• Previews may take a while to load

• A bit pricey compared to its competitors

Pricing

Litmus has three pricing tiers: Litmus Basic, Litmus Plus, and Litmus Enterprise.

Litmus Basic starts at $99 a month and includes all the basic features you’d need. Litmus Plus will cost you $199 a month but it will give you access to spam tests, ESP integrations, code editor integrations, etc.

For Litmus Enterprise, you’ll need to request a custom quote.

Basic and Plus plans have a 7-day free trial for a detailed test run.

What other users think (based on G2 and Capterra)

Litmus has 4.7 stars on Capterra and 4.6 stars on G2.

Most users enjoyed the variety of features and the ease of using the platform. Some downsides they emphasized were the loading time of previews, expensive pricing, and hard-to-set-up analytics.

Email on Acid

Similar to Litmus, Email on Acid is an email builder and preview testing tool in one. It provides two types of testing: Email Testing which tests your template and Campaign Precheck which runs tests based on a predefined checklist.

Email Testing provides previews for more than 90 email clients, runs deliverability tests by checking feedback filters and authentication protocols, and validates URLs.

So, the results of Email Testing were nothing out of the ordinary and were similar to the info we received from other tools.

Where Email on Acid stands out is the Campaign Precheck. Initially, I didn’t think it would be much different from Email Testing. But Campaign Precheck is way more comprehensive and allows you to refine every aspect of your email before it gets to recipients.

To use this feature, you can either leverage Email on Acid’s default workflow or create your own. Since I wanted to see what the tool was capable of, I chose the recommended workflow.

Here’s what it does:

• Allows you to set the sender name, email subject line, and preheader text while previewing them on mobile, desktop, and webmail;

  

  • Helps you optimize the accessibility of the email through a step-by-step process and provides explanations for each step. I was able to hear the difference between screen reader behaviors with and without pre-defined language. Any issues can easily be fixed by clicking a button;

• Checks the links and provides an option to add UTM parameters to get more accurate results when you analyze the campaign in Google Analytics;

• Optimizes images and other media;

• Checks the email content for spelling errors;

• Checks the email for blocklisted domains;

• Runs the spam test on the subject line. While I like this feature, it can take a while to complete;

• Shows you previews for selected email clients;

• Provides a Precheck summary and allows you to see the changes made to the code.

Email on Acid has an email editor with templates. However, the designs seemed a bit outdated.

It’s also possible to set up email analytics but I haven’t given it a fair try as my focus was to test the email testing portion of the tool. The analytics feature allows you to track open rates, the effectiveness of call-to-action (CTA) buttons, click-through (CTR) rates, and other important metrics.

Features

• Multiple testing options to refine email templates before sending them to an email list

• A wide selection of email clients

• A step-by-step wizard that adjusts the code automatically without the users having to code themselves

• The ability to send test emails from ESP, Email on Acid platform, or a selected SMTP server for deliverability checks

Pros

• Minimal learning curve

• Easy to optimize the template and see the reason behind each modification

• Code editor with snippets and live preview

• Comprehensive tests

Cons

• Lacks regular and dark mode previews for the Gmail app on iOS and Android

• Spam tests take a while to load

• Lacks information on why the email failed the spam filter test

Pricing

Email on Acid has four pricing tiers: The Basics, Premium, Professional, and Enterprise.

The Basics costs $99/month and includes unlimited previews and projects, 1 user, partial content checking, and an email editor. Premium costs $179/month and provides access to full content checking, deliverability tests, 3 users, and email analytics for 500k opens/month.

Professional costs $599/month for 10 users, custom user permissions, dedicated support representative, and email analytics for 1.5M opens/month.

You should get a custom quote to use an Enterprise plan.

There’s a 7-day free trial for all paid plans.

What other users think (based on G2 and Capterra)

Email on Acid has 4.5 stars on G2 and 4.4 starts on Capterra.

Most users enjoy the results they get from Campaign Precheck tests, the fact that they don’t have to code to optimize the template, and how easy it is to use the platform.

Some disadvantages users highlighted were the lack of certain important clients and the occasional inaccuracy of email previews.

Email Preview Services (formerly PreviewMyEmail)

The third tool I chose for this list is Email Preview Services, formerly known as PreviewMyEmail. It’s suitable for developers and marketers.

For developers, it has a white-label API that can be used to preview email templates from any programming language. However, this feature is only available to enterprise users. That’s why I decided to include it here.

There are two ways of accessing inbox preview: by sending an email to the inbox address or inserting a template manually.

First, I opened the Preview tab, clicked Create a new test, and added my template manually. There’s a list of email clients and you can easily toggle between them if needed. I clicked Start Test and the previews started loading. I’d say the loading time was average.

While I liked the quality of the screenshots, client previews certainly lacked Android options and modern iPhone devices. Web browser and desktop email clients were more diverse, though.

Then I sent an email to an inbox email address and the results were exactly the same.

There’s also an option to create, store, download (HTML), or test templates right on the platform.

Finally, I ran the spam test. This test checks the sender score, authentication protocols, blacklists, links, images, and HTML code.

Overall, Email Preview Services provides high-quality previews at an affordable price. While it may lack the advanced features that Email on Acid and Litmus have, it still delivers great value for money.

Features

• Previews from around 50 email clients

• Spam and infrastructure checks

• Drag-and-drop email editor

• Analytics feature that provides data on which clients recipients use, unique total opens, geolocation, email address activity log, etc.

Pros

• High-quality preview screenshots

• Affordable pricing

• Straightforward platform and testing workflow

Cons

• Email client previews lack modern devices and operating systems

• Content and HTML checks could be more comprehensive

Pricing

Email Preview Services has four pricing plans: Standard, Business, Professional, and Enterprise.

If you choose the Standard plan, you’ll pay $25 a month for unlimited previews, 5 email spam and inbox tests, a simple editor, and 1 user. The Business plan is available for $45 a month and provides access to analytics, an advanced editor, 25 spam and inbox tests, and 1 user.

For more seats, analytics, and spam tests, you’ll have to opt either for a Professional ($160/month) or Enterprise ($399/month) plan.

A 7-day free trial is available for all paid plans.

What other users think (based on G2 and Capterra)

At the time of writing, Email Preview Services doesn’t have reviews on G2 and Capterra.

SendForensics

SendForensics is an email deliverability testing tool that allows you to preview and test email campaigns.

After signing up, you’re prompted to send an email to a specific email address.

Within seconds, you’ll see it on the SendForensics platform. At that point, the email has already been analyzed and you can access the results right away.

As you press your sending domain, you’re taken to a Snapshot that contains the overall results of the analysis. You can see deliverability score, infrastructure analysis, and content analysis.

The Content tab highlights problematic elements of your email content. It scans your email for spam triggers that can land you in a spam folder. In this tab, you’ll find potential issues with HTML code, link validation results, and improper data collection practices, if any.

I adjusted the template according to the platform’s recommendations and ran another test. That’s when I noticed that their content-checking feature wasn’t as robust as I expected. The recommendations can be ambiguous and unusable at times.

The good thing is, there’s an explanation for each recommendation. So, you can use your own expertise to filter out the results.

In terms of infrastructure, SendForensics checked if my IP was blacklisted and scanned my SPF, DKIM, and DMARC records. This is quite useful, especially if you’re trying to improve the template to ensure good deliverability rates. For more accurate and comprehensive checks, it’s possible to add an ESP plugin to SendForensics.

There’s also an option to check cookie forensics and legal compliance. This includes checking whether the email has an unsubscribe link in it.

The last tab is Previews which shows you how your email will look in different email clients. The results are actual screenshots, not simulations. This will help you avoid improper rendering as you send the campaigns to recipients.

Email Previews for Apple Mail (Desktop), AOL (Webmail), and Gmail (Webmail)

Features

• Deliverability analysis

• Content checks

• Email preview screenshots

• ESP plugins

• Customizable domain settings for accurate tests

Pros

• Recommendations that are easy to understand and implement

• Comprehensive deliverability checks

• Ready-to-use platform

• Integration with a third-party ESP

• Affordable compared to other preview tools

Cons

• You have to send emails to SendForensics over and over again to access analysis after modifying the template

• Content improvement recommendations aren’t always accurate

Pricing

SendForensics has four pricing plans: Brand at $49/month, Company at $79/month, Agency at $199, and Enterprise at $349.

The pricing plans aren’t feature-based, which means that most of the features are similar across the tiers. What differs is the number of domains, users, and DMARC reports per month.

The cheapest plan (Brand) has a 14-day free trial. A free plan isn’t available.

What other users think (based on G2 and Capterra)

SendForensics has 3.8 stars on G2 and 4.3 stars on Capterra.

This tool isn’t as popular as the others, so the rating is based on 6 reviews in total.

Most users liked the deliverability checks, value for money, and the ability to run unlimited tests.

Just like me, others also noticed that the content checks need a bit of improvement to be more accurate.

Key Takeaways

So, to conclude, here are some key takeaways from my research:

1. Finding decent email rendering and email preview tools isn’t easy, especially for developers

2. Pricing tends to be on the higher side for email preview tools created for marketers

3. There’s no such thing as a free email preview tool, but there certainly are free tiers with limited features and previews

4. Most email marketing platforms will allow you to preview emails before sending them and some will even have email client previews. Such platforms include Mailchimp, GetResponse, Constant Contact, and others.

5. Email marketing platforms won’t provide comprehensive previews and tests. For that, you will need to invest in a dedicated tool.

If you’re interested in email client testing and email testing in general, check out the recommended reads:

• Email Testing Checklist

• The Best Email Deliverability Testing Tools

• Email Client Testing Explained

Keep an eye on our blog as we’ll be covering even more testing topics in the upcoming months.

Good luck and preview away!

Thank you for reading this email! Find more email rendering tools in Mailtrap blog!