How to keep newsletters from hurting password reset emails
Your newsletter and your password resets shouldn't depend on the same sending reputation. A reader who dislikes a promotion shouldn't make it harder for a paying customer to get back into your app.
Before you automate another campaign, check what sends from your domain, how each sender proves its identity, and which messages share a subdomain. Then check whether those messages actually reach the inbox.
Separate essential product mail from marketing before you send more marketing. That won't guarantee inbox placement. It gives you a cleaner setup to manage, test, and troubleshoot without treating every email as the same kind of message.
Which email deliverability best practices should you start with?
Start by separating marketing from essential product mail, authenticating every sender, and checking inbox placement. Those steps give you a useful baseline before you increase volume or add another automation.
The Spamhaus deliverability guide explains that providers judge the quality of your mail, rather than relying on your email service's ability to get messages accepted. Both IP addresses and domains carry reputations. Authentication gives receiving systems more information to use when they judge a message.
That matters if you run a small SaaS business. Buying an email service doesn't hand over every decision that affects delivery. You still choose who receives messages and what those people receive. You also choose whether a newsletter uses the same sending setup as a password reset.
Use this order for your first review:
- List every service that sends email using your domain.
- Separate newsletters and promotions from essential product messages.
- Check SPF, DKIM, and DMARC for each sending setup.
- Confirm that recipients asked for your marketing and can easily leave.
- Watch bounces, complaints, reputation, and inbox placement.
Treat that list as a release check, not a one-off cleanup. A new support tool or an abandoned signup sequence can change what leaves your domain.
Don't start by shopping for a replacement provider unless you've identified a problem the provider can solve. First establish what you send, who gets it, and whether your setup matches your intent. Moving an unwanted newsletter to a different service doesn't make readers want it.
Separate newsletters and password resets onto different subdomains
Use one subdomain for marketing and another for essential product messages. The Emailit checklist recommends separate subdomains so each kind of mail can build its own reputation.
A straightforward setup looks like this:
Purpose Example subdomain Messages Marketing news.example.com Newsletters and promotions Essential product mail notify.example.com Password resets, receipts, and account alerts
The names aren't special. What matters is that you deliberately assign different kinds of email to different sending setups. Don't assume two different addresses on the same domain create the separation you want.
For each subdomain, check which service sends the messages and how that service authenticates them. Make the intended use clear in your own notes. Your newsletter tool should use the marketing setup. Your app should send account access messages through the setup you chose for essential mail.
Separate subdomains reduce risk, but they don't create a perfect firewall. Shared infrastructure and the reputation of the broader domain can still connect them. Don't promise yourself that a badly run newsletter can never affect anything else.
The practical benefit is a clearer boundary. You can review a promotion without treating it like a receipt. You can investigate a missing reset without first untangling every campaign you've ever sent.
If everything currently uses one sending setup, map the messages before changing anything. Pick a quiet window to move marketing, authenticate the new setup, and test both kinds of mail. Keep working password resets working while you make the change.
Check authentication for every service that sends as you
SPF, DKIM, and DMARC help receiving systems check who sent a message. They don't guarantee that the message belongs in the inbox.
The Emailit authentication guidance says to verify every sending domain, including subdomains. It also explains that DMARC needs a passing SPF or DKIM check whose domain aligns with the visible From address.
In plain language:
- SPF tells receivers which systems may send mail for a domain.
- DKIM adds a signature that receivers can check against the signing domain.
- DMARC checks that the authenticated identity lines up with the domain readers see in the From address.
You don't need to build these checks yourself. You do need to follow your provider's setup instructions and verify that the messages your app actually sends pass them.
Start with a list of senders. Include your app, newsletter platform, and support software. For each one, record the visible From address, sending subdomain, and provider. Then check a real message from that service rather than relying only on a green status badge in a dashboard.
Be careful when copying instructions between providers. Emailit says it handles SPF and DKIM after domain verification, while you add DMARC yourself. That describes its service, not a promise about every email tool you use.
Emailit recommends starting DMARC in monitoring mode with p=none, collecting reports, and moving toward p=quarantine and p=reject after legitimate mail passes. Don't jump to a stricter policy while you've still got unknown senders. First find the services your business depends on and confirm that their messages authenticate correctly.
Send marketing only to people who asked for it
Send newsletters to people who asked for newsletters, and give them an obvious way to stop. A valid sending setup can't make an unwanted message welcome.
The Spamhaus guide puts the quality of the mail you send at the centre of deliverability. Its point is useful here: your provider can't replace the decisions you make about your audience.
For a SaaS product, separate the reason you have someone's address from the reason you're emailing them. A person may need an account receipt without wanting your weekly product commentary. Don't quietly treat those as the same request.
Before launching a marketing sequence, write down three things:
- Where the recipient asked to receive it.
- What you told them they would receive.
- How they can unsubscribe from future marketing.
If you can't answer those questions, pause the sequence. An address in your database isn't enough to explain why a promotion should arrive today.
Make unsubscribing easy to find and easy to finish. Test the whole path yourself. Check that leaving a newsletter actually stops the next newsletter, including messages queued through another tool.
Keep that choice separate from essential account messages. Someone who leaves your marketing list may still need a password reset or a receipt. Your sending setup and audience rules should reflect that difference.
For a solo builder, a short, clear signup promise is easier to maintain than a clever collection of overlapping lists. Tell people what they'll get. Send that. Let them leave without needing a support ticket. That's a rule you can check every time you add an automation.
A successful send doesn't prove inbox placement
A successful send doesn't tell you whether a person can find your message in their inbox. Check where messages land instead of treating the send result as the end of the job.
Mailgun's 2025 survey found that 87% of respondents didn't test inbox placement. Its chapter on improving deliverability connects reaching the inbox with the customer experience. A password reset that a customer can't find makes that connection concrete.
Test the email that your product really sends. A manually composed message from your own mailbox doesn't check the path used by your app.
For a password reset, walk through the customer journey:
- Request a reset from the product.
- Check whether the message arrives and where it lands.
- Confirm that the sender name and address make sense.
- Open the message and use the link.
- Record the result and the sending setup you tested.
Repeat the exercise for your newsletter using its own subdomain and provider. Keep the results separate so a working newsletter doesn't hide a broken account message, or the reverse.
A test gives you evidence about those messages and mailboxes. It isn't a guarantee that every recipient will see the same result. Use it to find obvious failures and compare results after changes.
Measure the outcome the customer needs: a usable message they can find. Your provider accepting a request is useful technical evidence. It isn't the whole customer experience. Keep both facts in view when you review whether email is working.
Watch complaints and bounces before increasing volume
Track bounces, spam complaints, and domain reputation alongside inbox tests. These checks answer different questions, so don't compress them into one comforting delivery number.
The Emailit checklist tells senders to revisit their setup when bounce or complaint rates climb. That's a useful trigger for a small SaaS business: investigate a change before sending more messages through the same setup.
Keep the review simple enough that you'll actually do it:
- Bounces: Which messages failed, and what reasons did the provider report?
- Complaints: Which campaign or signup path produced messages people marked as spam?
- Domain reputation: What do the available reports say about the domains you send from?
- Inbox tests: Where did your essential messages and newsletters land?
Look at marketing and essential mail separately. A combined report can make it harder to connect a problem to the message that caused it. Label each sending setup clearly in your notes and dashboards.
When something changes, check recent edits before making several more. Did you add a new list? Change the From address? Connect another tool? Turn on a sequence that had been sitting unused?
Don't invent a universal safe threshold from a number quoted without context. The supplied guides don't establish one complaint or bounce rate that guarantees inbox placement across providers.
Instead, decide what would make you pause a send and who checks the issue. If you're the only person running the product, write that decision down anyway. A short rule you follow beats a dashboard you only open after a customer asks where their reset email went.
Give every new email automation a release check
Check each new automation before it sends to customers. A working newsletter setup doesn't prove that a newly connected support tool or onboarding sequence uses the same authentication correctly.
The Emailit checklist calls for verifying each sending domain and using DMARC reports to see services sending as your domain. Turn that guidance into a short record attached to the automation itself.
Your release check can fit on one page:
- Purpose: Is this essential product mail or optional marketing?
- Audience: Why should these people receive this message?
- Sender: Which tool, From address, and subdomain will it use?
- Authentication: Have you checked SPF, DKIM, and DMARC on a real message?
- Recipient controls: Can people leave optional mail without losing essential account messages?
- Testing: Have you triggered the actual workflow and checked where its email lands?
- Monitoring: Where will you check bounces, complaints, and changes in reputation?
Keep the record plain. You don't need a new project management system to document an email sequence. A note beside its settings is enough if you can find it when something breaks.
Also record how to pause the automation. If a campaign starts sending to the wrong audience, you shouldn't have to discover its off switch under pressure.
Start with your password reset today. Trigger it, inspect the sender, and confirm which subdomain it uses. Then inspect your newsletter. If both rely on the same setup, plan the separation before adding another campaign. You can keep publishing useful content without making access to your product depend on how readers feel about your latest promotion.
Sources
- https://info.spamhaus.com/hubfs/Know%20How%20-%20Email%20Deliverability/Spamhaus%20eBook_Email%20Deliverability%20101.pdfinfo.spamhaus.com
- Email deliverability best practices · Emailit Docsemailit.com
- Best Practices to Improve Email Deliverability - Transactional Email API Service For Developers | Mailgun mailgun.com