How to set up email for newsletters and password resets

Your newsletter and password resets shouldn't come from the same email address. Google explicitly recommends separating them, yet changing the From address alone won't guarantee either reaches the inbox.

Before you rewrite another subject line, check which service sends each message and whether that service passes authentication. Then check whether people asked for the email and can stop receiving it.

You can't guarantee inbox placement. You can remove avoidable problems without turning email into your full-time job.

How to avoid spam filters when sending emails

Authenticate your sending domains, send marketing only to people who opted in, and make unsubscribing easy. Those are the starting points in Google's sender guidance, not a promise that every message will reach the inbox.

Google's requirements apply to personal Gmail accounts, including addresses ending in gmail.com and googlemail.com. The guidance separates requirements for all senders from additional requirements for senders exceeding 5,000 messages a day to Gmail accounts. Don't assume every rule has the same scope.

For all senders, the listed requirements include SPF or DKIM authentication, valid forward and reverse DNS records, and an encrypted TLS connection. Your email provider may handle parts of that setup. Check what it actually handles rather than assuming a paid account covers everything.

Start with a short review:

• Identify every service that sends email using your domain.
• Check authentication on real messages from each service.
• Separate newsletters from password resets and receipts.
• Check how people join and leave your mailing list.
• Watch Gmail spam complaints when reporting data is available.

This isn't a reason to ignore the message itself. Google's guidance also asks senders to respect what recipients expect to receive. A technically correct email can still be unwanted.

But a list of supposedly dangerous words doesn't answer whether your newsletter service authenticates properly. It doesn't tell you whether a signup form collected consent, either.

Fix the setup and permission checks before you spend another afternoon polishing subject lines. Treat inbox placement as something you monitor, not something a copy tweak can guarantee. If you're short on time, start with a newsletter and a password reset you can inspect yourself.

Newsletters and password resets need different sending addresses

Google recommends sending subscription messages and transactional messages from different email addresses. Its subscription guidelines name newsletters and marketing emails as subscription messages, and password resets and receipts as transactional messages.

The distinction is about why someone receives the message. A newsletter goes to a list that people can leave. A password reset follows an explicit request from someone trying to access their account.

For your product, the address split could look like this:

• newsletter@your-domain sends the newsletter.
• offers@your-domain sends a separate promotional subscription.
• accounts@your-domain sends password resets and receipts.

Those are examples, not required address names. The useful change is separating messages people subscribe to from messages they request while using your product.

Check the visible From address inside each sending service. A newsletter template and a password-reset template can look completely different while still using the same sender address. Different templates don't satisfy a recommendation to use different addresses.

Google also recommends identifying each subscription list. Its guidance allows a human-readable identifier in the List-id header or a unique From address for different subscriptions. If you offer separate newsletters, make it clear which subscription each message belongs to.

Don't turn this into a claim about complete protection. Google's recommendation to use different addresses doesn't promise separate reputations or guaranteed delivery. Changing hello@ to newsletter@ is one setup change, not proof that the rest of your email is safe.

Make the split, record it, and test both types of message. You still need to check authentication for every service sending them.

Check SPF and DKIM before adding DMARC

Verify that legitimate email passes SPF and DKIM before adding a DMARC policy. That's the sequence in Google's advice on common sender issues, and it applies whether you send large or small volumes.

SPF, DKIM, and DMARC are email authentication tools. They help receiving systems identify legitimate senders and help protect your domain from impersonation. They don't establish that a recipient wanted your newsletter.

The distinction between a minimum requirement and a recommended setup matters here. Google's general sender requirements list SPF or DKIM for all senders. Its troubleshooting advice recommends setting up both, verifying legitimate messages, and then adding DMARC.

Don't stop after checking the service you use most often. If one provider sends your newsletter and another sends login emails, inspect messages from both. A successful newsletter test doesn't tell you whether the other provider's messages pass.

Use a small, repeatable check:

1. Send a real newsletter test through the newsletter service.
2. Request a password reset through your product.
3. Inspect the authentication results for each received message.
4. Fix failures using your domain provider's and sending service's instructions.
5. Add DMARC after you've verified legitimate messages pass SPF and DKIM.

Record what you checked. “We set up email last year” isn't useful evidence when you've since changed providers or added another tool.

You don't need to guess which DNS records to paste from a generic blog post. Follow the instructions for your actual providers, then verify the result on messages they send.

The goal is a working setup across your legitimate senders. A settings page showing that one domain is connected isn't enough to establish that every email your product sends passes authentication.

What should your email audit include?

An email audit should connect each message type to its sending service, From address, and authentication results. That turns Google's advice to authenticate all sending domains into something you can check instead of something you vaguely remember doing.

Keep it in a document you already use. You don't need another dashboard to discover that nobody knows which service sends your receipts.

Use a table like this, replacing every placeholder with your own setup:

Message Sending service From address SPF result DKIM result DMARC checked Newsletter Enter provider Enter address Record result Record result Record status Password reset Enter provider Enter address Record result Record result Record status Receipt Enter provider Enter address Record result Record result Record status

Add each message type your product actually sends. If an old integration still sends email, include it until you've confirmed it's no longer in use.

Fill the table from actual messages, not just provider settings. Record the date you checked each row so you can tell whether the result predates a provider change.

For subscription messages, add a note about where people opt in and how they unsubscribe. That keeps the technical check tied to the recipient's experience.

Mark unknown results as unknown. An empty cell is a task, not a pass. If you can't identify the sending service, trace that message before changing domain settings.

Then make the next action specific: fix the newsletter sender address, investigate a failed authentication result, or test the unsubscribe flow. The audit earns its place by telling you what to do next, not by looking complete.

How should people join your marketing list?

Send marketing email only to people who explicitly opted in to receive it from your sending address. Google's advice on user choice states that expectation directly and asks senders to keep volume reasonable and content relevant to recipients.

A product account and a newsletter subscription are different requests. Don't treat an email address collected for access to your app as proof that the person asked for every campaign you might send.

Google's subscription guidance also recommends confirming an email address after someone enters it on your website or app. Google calls this double consent.

For a small SaaS product, review the signup path from the user's side:

• Read the text next to the newsletter signup field.
• Submit an address and check the confirmation message.
• Confirm the address and inspect the first subscription email.
• Check that the sender matches what the signup promised.

Make the promise concrete. If you're offering a newsletter about using your product, say that. If you're offering promotional messages, don't disguise the choice as a necessary account step.

Keep the expected volume clear enough that you can check your own behavior against it. Google's guidance doesn't supply a universal sending frequency that makes every audience happy. It asks you to send at a volume recipients expect.

That matters when you're building a content engine. Automating more posts shouldn't silently become permission to send more email. A publishing schedule is your choice; subscribing is the reader's choice.

Before importing an existing contact list, check what those people actually agreed to receive. If you can't establish explicit permission for the marketing email, don't treat a valid address as a green light to send it.

Make unsubscribing work without extra steps

Implement one-click unsubscribe for subscription emails and honor requests within 48 hours. Both points appear in Google's subscription guidelines, which say unsubscribing should require no additional user action.

A link that sends someone through another task doesn't meet that description. Don't require them to log into your product, remember a password, or explain why they're leaving before you stop the subscription.

Test the path as a subscriber. Sending yourself a preview isn't enough if the preview doesn't exercise the same unsubscribe flow as a real subscription message.

Use an address you control to check the whole sequence:

1. Join the subscription through the real signup form.
2. Confirm the address and receive a subscription message.
3. Use the unsubscribe action.
4. Check that your sending service records the request.
5. Verify that later sends exclude the unsubscribed address within 48 hours.

If your app stores subscription choices separately from your email provider, check both places. Don't assume one system's update reached the other without testing it.

Keep this review focused on the subscription someone left. Google distinguishes subscription messages from transactional messages such as password resets, purchase receipts, and one-time passwords. A reader leaving your newsletter hasn't necessarily stopped needing access to their account.

A preference page can offer choices, but it shouldn't replace a working one-click unsubscribe action. Let the reader leave without completing a negotiation.

For a solo builder, the useful outcome is simple: you know where the request lands, what stops future sends, and whether the change happens within the stated window. If you can't answer those questions, fix the flow before scheduling another campaign.

What should you monitor after fixing the setup?

Monitor Gmail complaints in Postmaster Tools when data is available, and keep reported spam rates below 0.3%. Google's sender guidelines treat spam complaints as part of sending responsibly, alongside authentication and the other technical requirements.

That threshold isn't a target to use up. It also isn't a promise that a rate below it guarantees inbox placement. Don't turn one reported number into a clean bill of health for every message you send.

If complaint data isn't available, don't label the missing report as zero complaints. You still have checks you can run: test authentication, review how recipients joined, and verify that unsubscribing works.

When a problem appears, keep the investigation narrow enough to act on. Record which message you sent, which provider sent it, and which address it used. Then check what changed before the problem appeared.

Useful questions include:

• Did you switch the service sending this message?
• Did you change its From address or domain setup?
• Did the recipients explicitly request this subscription?
• Did the campaign match the content and volume they expected?
• Did unsubscribe requests stop later subscription messages?

Those questions don't diagnose every delivery problem. They give you evidence to inspect before you start guessing about individual words in a subject line.

A different From address doesn't guarantee a different reputation or an inbox slot. Keep that limit attached to the advice to separate newsletters from password resets. The address split is a sensible step, not complete protection.

Before your next campaign, fill in the audit for your newsletter and your password-reset email. Send one test of each, record the authentication results, and fix any unknowns. Then test the newsletter's unsubscribe action before you press send.