When sending bulk and transactional emails, you want to mitigate risk as much as possible by utilizing a subdomain approach instead of using a top-level domain.
Every domain has its own reputation, which is key for successful delivery to mailbox providers. Every mailbox provider measures reputation differently, so senders need to always do the right thing, including sending to only opted-in recipients and people engaging with your email. Being proactive and removing recipients who aren’t performing is crucial to maintaining a stellar reputation.
Often, you can do everything right but still have a problem along the way. Deliverability issues can occur, but you don’t want them to affect all the different types of email that you send.
By sending through subdomains, senders can minimize this risk and the impact radius of certain issues that occur and isolate problems more effectively.
The subdomain approach
Let’s look at Company X, which sends emails from their top-level domain of example.com. Their company sends personal correspondence (interoffice email), newsletters, marketing campaigns, and transactional email. They send it all using example.com.
Because of an errant data issue, they accidentally send a marketing campaign to past unsubscribed users, and their domain gets flagged by a major blocklist provider like Spamhaus. Until the issue is resolved, all their various types of emails are blocked, including the valuable personal correspondence and transactional emails.
If they had set up a subdomain, the damage would have been isolated to the subdomain that sent the specific campaign and wouldn’t have affected other types of emails. They could have configured and mapped the following subdomains to different types of email sends:
-
Personal correspondence: example.com
-
Newsletters: news.example.com
-
Marketing: offers.example.com
-
Transactional: orders.example.com
How to set up subdomains for your emails
If you’re using Oracle Cloud Infrastructure (OCI)’s email domains feature, you can manage both the top-level-domain (TLD) and subdomains that you want to send from.
The newly created subdomain inherits the TLD’s reputation initially, and then it works on its own to increase (or decrease) its reputation based on the quality and engagement it receives. However, when those subdomains are created, the sender must enable SPF and DKIM to the subdomains because they don’t inherit their TLD’s authentication.
From there, you can send the appropriate type of email using its specific subdomain.
Use the following tips for better utilization:
-
Dedicating the TLD to only personal correspondence is a best practice because you can put enhanced security measures into place to protect the brand from any issues with virtually zero chance for down time from blocklistings.
-
You always want your transactional mail to be on its own subdomain so that it performs with a stellar reputation and little-to-no deliverability issues because of typically high engagement levels.
-
After moving bulk email to its own subdomain, you can identify some areas for improvement, such as list hygiene and overall sending practices. The reputation might be lower than what it was in the past on the TLD. Over time, you can build your reputation up.
Final thoughts
Through subdomains senders can get more granular with reporting by type of email, troubleshoot errors in deliverability, and sometimes fix blocklistings and greylistings with more refinement, avoiding costly service interruptions. Using subdomains helps with faster rehabbing that you might need for different email streams and provides a baseline of performance across the given streams to base future performance on.
This approach takes some work and patience. When changes are made, senders must be ready to potentially face an underperforming email stream. However, with time and best practices, those email streams can perform better than sending off just one TLD.
For more information on utilizing a subdomain approach, see the following resources: