Why you should separate transactional and marketing email

Your password reset and your weekly newsletter have almost nothing in common: different audiences, expectations, legal requirements, and engagement patterns. But most teams send them from the same domain and through the same infrastructure, then wonder why 2FA codes end up in spam after a marketing campaign goes sideways.

We've seen this play out more than once. A team sends a re-engagement campaign to users who haven't opened an email in the past 6 months. Complaints spike, and within a week, the transactional delivery rate drops. These two events don't seem connected unless you know to link them. By the time you're investigating why users can't log in, the real issue is a promotional email about a feature launch nobody requested.

The problem with one domain

When you send everything from yourapp.com, every message shares the same sender reputation. Mailbox providers like Gmail don't know or care that your password reset and your product announcement are different categories. They see one domain and judge it as a whole.

Marketing email, by nature, has lower engagement and higher complaint rates than transactional email. People ignore newsletters. They mark them as spam instead of unsubscribing because it's one click instead of two. Open rates of 20-25% are healthy for marketing, but for transactional, anything below 50% indicates a problem. When both types share a domain, the marketing numbers drag down the overall reputation.

A promotional campaign with a 0.2% complaint rate sounds harmless, but it's enough to make Gmail suspicious of everything you send. Order confirmations suddenly drift into Promotions, and verification codes land in spam. There's no alert when this happens, and most developers find out something is wrong only after it's already too late.

How subdomain separation works

The fix is straightforward: use separate subdomains for each email type. For example, use mail.yourapp.com for transactional emails and news.yourapp.com or marketing.yourapp.com for campaigns.

This way, each subdomain builds its own reputation with mailbox providers, and Gmail treats mail.yourapp.com and news.yourapp.com as separate senders with separate histories. As a result, a spike in complaints on your marketing subdomain doesn't affect your transactional reputation. Password resets still land in the inbox even when your newsletter is having a bad week.

Setup means configuring SPF, DKIM, and DMARC for each subdomain independently. That sounds like double the work, but in practice, it's a second set of DNS records. Lettr lets you configure multiple sending domains, each with its own authentication and reputation.

A common setup looks like this:

mail.yourapp.com     → password resets, verification codes, receipts, 2FA
news.yourapp.com     → newsletters, product updates, feature announcements

Once each subdomain is sending, register both in Google Postmaster Tools and watch their reputations as they diverge. The dashboards report per-domain spam rate, IP reputation, and auth pass rate.

Some teams add a third subdomain for onboarding drips, which sit between transactional and marketing in terms of engagement. Whether you need it depends on volume. If onboarding is a few thousand emails per month, bundling with marketing is fine. If it's a significant share of your sending, a dedicated subdomain lets you monitor its reputation independently.

The gray areas

Not every email easily falls into the categories of "transactional" or "marketing." A few common ones tend to confuse people.

Onboarding sequences

A welcome email sent immediately after signup feels transactional. The third email in a drip series, sent three days later and explaining features the user hasn't tried yet, feels more like marketing. The line shifts as the sequence progresses. The first message or two can go through transactional. Anything after that should go through marketing.

Review requests

"How was your recent purchase?" emails are triggered by a user action (buying something) and are intended to drive engagement, not to provide information. Most providers and regulators treat these emails as marketing. Send them through your marketing subdomain.

Account activity digests

A weekly summary of activity in your app is triggered automatically, not by a specific user action. These are closer to marketing than to transactional messages. They should include an unsubscribe option and be part of your marketing stream.

Renewal and expiration notices

"Your subscription expires in 3 days" is transactional. "Your subscription expired. Here's a 20% discount to come back" is marketing with a transactional wrapper. The discount makes it promotional.

Shipping and delivery updates

Clearly transactional. "Your package shipped" belongs in the transactional stream. But if you add product recommendations below the tracking number, you're drifting into promotional territory for both filters and regulators.

When in doubt, consider it marketing

Reason is simple: the downside of sending a borderline email through marketing is slightly lower open rates. The downside of sending it through transactional and having it generate complaints is damage to the reputation of the emails your users actually depend on.

Auditing your current setup

If you're already sending email and haven't separated streams, start by figuring out what you're actually working with.

• List every email your application sends. Not just the ones you remember building. Grep your codebase for every call to your email service. Check your provider's dashboard for message types or tags. If you have them, pull SMTP logs. Most teams discover emails they had forgotten about during this step.
• Classify each one. Ask two questions: Was this triggered by a specific user action? Does the user need this information to complete what they started? If both are yes, it's transactional. If either is no, it's marketing. For gray areas, apply the "when in doubt, consider it marketing" rule.
• Check your DNS. Run dig TXT yourapp.com to review your SPF, DKIM, and DMARC records. If you're sending everything from the root domain, you'll see a single set of records. Note which services are authorized in your SPF record, as you'll need equivalent records for the new subdomains.
• Check complaint and bounce rates by email type. Lettr surfaces these via webhooks and the events API. Your overall bounce rate may look healthy even when one specific campaign is responsible for most of the damage. The whole-domain average hides this.
• Set up Postmaster Tools and feedback loops. Postmaster shows Gmail's view of your domain, including spam rate, reputation, and auth. Feedback loops at Yahoo and Microsoft forward complaints so you can automatically suppress complainers. Without these signals, you're flying blind whether or not the streams are separated.

Migrating to separated streams

It is important not to do this all at once. A gradual migration is safer and easier to debug.

1. Set up your subdomains. Create DNS records for mail.yourapp.com and news.yourapp.com, and configure SPF, DKIM, and DMARC for each. Lettr verifies domain authentication during setup, so you'll know immediately if anything is misconfigured.
2. Audit your From addresses now, not later. Every email template must use the correct subdomain in its From header. A password reset sent "from" your marketing subdomain defeats the purpose. This step is easy to forget once migration is underway, so do it before you flip traffic and check again afterward.
3. Move transactional first. Move your most critical messages (password resets, verification codes, 2FA) to the transactional subdomain first. These are the emails where delivery failures have the most impact, so you want them isolated and monitored before you touch anything else.
4. Warm up the new subdomains. Brand-new subdomains have no reputation history. Mailbox providers treat them with suspicion until they build a track record. Start at a low volume and scale up over one to two weeks. Don't migrate your highest-volume email types on day one.
5. Move marketing email. Once transactional is stable, route marketing emails through news.yourapp.com. Start with smaller campaigns and ramp up. If your marketing was dragging the shared domain down, you may see transactional delivery improve after the split.
6. Monitor both streams independently. The key point is that each stream has its own health metrics. Track bounce, complaint, and open rates per subdomain. A problem in one stream should be visible without noise from the other.

The legal reinforcement

Separation isn't only a deliverability decision. Transactional and marketing emails are governed by different legal rules, and mixing them creates compliance risk on top of inbox placement risk.

Under CAN-SPAM, transactional emails are largely exempt from opt-out requirements. You don't need an unsubscribe link in a password reset. Marketing emails require one, and the FTC has fined companies for noncompliance.

GDPR treats transactional email as necessary for contract performance: you bought something, so you get a receipt, and no separate consent is needed. Marketing emails require explicit opt-in consent, and recipients can withdraw at any time. Canada's CASL has similar carve-outs for transactional messages tied to an existing business relationship.

Gmail is particularly aggressive here. Its filters evaluate content signals, not your internal categorization. If your transactional email looks promotional, Gmail treats it as promotional, regardless of what triggered the send.

What a well-separated setup looks like

Once you've migrated, each subdomain has its own SPF, DKIM, and DMARC records, builds reputation independently, and a problem in one subdomain stays contained.

Transactional should have near-zero complaints because every email in it was directly triggered by a user action. If your transactional complaint rate is above 0.01%, you likely have a classification problem: something in that stream is actually marketing.

Marketing will naturally receive more complaints and have lower engagement. That's fine. Those numbers don't affect your transactional delivery, which is the whole reason you separated them.

The cost of not doing this

Separation takes a few hours to configure and a week or two to migrate. Skipping it has no immediate cost, which is why most teams don't bother until something breaks. The asymmetry lies in recovery: once a shared domain's reputation drops, there's no shortcut back. You earn it back through weeks of consistent good behavior at a lower volume.

In the meantime, some of your transactional email ends up in spam. Users can't log in, verify accounts, or view receipts, and support tickets pile up while reputation slowly recovers. The fix is two subdomains and two sets of DNS records, set up before you ever need them.

If you're using Lettr, multiple sending domains are supported out of the box. DNS verification typically completes in under five minutes once your records propagate.