Test emails could be hurting your domain's sending reputation

The most important thing to remember about testing emails is that the sending reputation of your production domain could be damaged if you’re not careful. If you send test emails from your production domain to fake addresses, or real addresses with low engagement, this can hurt the reputation of your domain and affect delivery in the future. So how do you send test emails?

Learn more about transactional email best practices.

Before you start sending emails to real users in your production environment, it’s always a good idea to start by sending test messages. You might even configure non-production environments to streamline the process of testing your emails. This gives you a safe environment to work out any kinks in your sending. Beyond the basics of how the emails look once they reach the inbox, testing helps you avoid a few other issues as well.

• A dedicated test environment with its own sandboxed email sending minimizes the chance you’ll accidentally spam your real customers with test emails.
• Testing sending locally or using a dedicated staging or development domain can avoid damaging your production domain’s reputation from development tactics that might generate a high bounce rate or low engagement.
• A good approach to testing emails in staging on their own domain can help catch broken assets and formatting issues that can be caused by environment configuration problems.
• Using tools designed specifically to receive and test emails can save you time from setting up dummy mailboxes across the various email providers.
• Using locally hosted tools for catching emails can save you from wasting time waiting for emails to arrive in test inboxes.
• A proper staging environment with SPF, DKIM, and DMARC can help you understand authentication configuration and catch issues before they affect your production delivery.

There’s no question that setting up your environments and tools to optimize email testing can save time and protect you from risky mistakes. So, now that we know why it matters, let’s dive into the best way to handle things.

Where and how should I send test emails? #

You should always have a separate test environment to use, so you don’t accidentally start emailing real users in a production database. Another good practice is to have a specific server in your Postmark account just for testing. This way you won’t cloud the statistics from your production server with numbers from the test sends. 

Emails sent from your test environment should generally be sent to valid email addresses on your own domain. We quite often see customers sending tests to addresses on example.com, gmail.com, test.com and abc.com. This is definitely a practice to avoid. Sending test emails to fake addresses or addresses that don’t belong to you can generate a ton of bounces in your activity. In addition to the unnecessary noise in your activity feed, this is something email providers frown on. So bounces reflect poorly on your domain reputation and could ultimately affect your delivery rates.

Also, if you start sending 500 of the same message—on purpose or on accident—to a Gmail.com address, Gmail isn’t going to like that. Remember, great reputation and delivery stem from only sending transactional emails. So any bulk or other non-transactional emails like test messages can negatively affect your delivery. To ensure you’re following best practices you could set up a mailbox on your domain like: devtesting@yourdomain.com and send all of your test emails there. Another option would be to set up a development subdomain domain like testing@dev.yourdomain.com and have all of the test messages go there instead.

If you want to test delivery to other providers like Gmail, Hotmail, Yahoo, etc., it is ok to send a few test messages to those domains. Just make sure you’re sending to a real address that you set up and aren’t sending hundreds at a time.

Testing in development #

Postmark has a Testing option you can use when sending via the API. We have a test API Token “POSTMARK_API_TEST” which you can use instead of your real API Token. This will allow you to make sure the API call you are using is valid and get a real response back. Using this method will not allow you to see the messages in your activity, nor will they get sent out, but it will tell you if your messages are being accepted.

There are also some great tools available to help you simulate sending emails from your testing environment. Tools like MailCatcher, Mailtrap, MailHog, Dumbster, or MockSMTP provide dedicated email address or locally hosted tools specifically designed to help with email in your development and test environments. When the messages are “sent” you can view the full content and RAW message parts as well. This can be helpful in troubleshooting problems with the emails before they are sent to your customers.

Use test@blackhole.postmarkapp.com. Using this for the recipient will send a test message that’s shown in Postmark’s Activity and Postmark will drop the message on our end. It’s also worth noting with this option that each email sent to that address will count towards your monthly limit.

New test environment features on the way #

We’ve had a lot of requests from customers about building a more robust testing environment inside Postmark. So we’ve given this a lot of thought and are discussing some great new features specifically geared for testing.

We’ve talked about adding a Test API Token for Account level functions to go along with the Server Test Token already available. More features we’re looking into include: API error and bounce error generators, Sandbox email addresses, and the ability to demarcate certain servers as test servers and also having special "test" email addresses to help with bounce handing. If you have any other ideas, we'd love to hear them! Send us a message to support@postmarkapp.com