Sending a newsletter through your hosting account is the fastest route to a blocklist. Hosting mail servers are built for transactional messages: a password reset, an order confirmation, and sending a thousand at once looks exactly like what a compromised account does.
The rule is short: bulk mail goes through a service built for it. Everything below is about doing that properly.
Why not from hosting
Three reasons, and each is sufficient on its own.
Sending limits. Hosting accounts cap outbound messages per hour, and exceeding it either queues or suspends the account.
Shared reputation. Your server's address is shared with other accounts. A newsletter that generates complaints damages their mail as well as yours, and theirs damages yours.
No feedback. A sending service tells you what bounced, who complained and who never opens. Your mail server tells you almost nothing, so a list rots silently. What to do when you are blocklisted walks through the recovery you are avoiding.
Transactional and bulk are different systems
Worth separating deliberately, because they have opposite requirements.
Transactional mail goes to one person who just did something, must arrive within seconds, and must never be filtered.
Bulk mail goes to many people who signed up at some point, can take an hour, and is expected to be filtered if it is unwanted.
Mixing them on one sending identity means a newsletter's complaints affect delivery of your password resets. Use separate services, or at least separate subdomains, so the reputations do not share a fate.
Consent is the whole game
Deliverability is decided by how recipients react, not by your settings.
People who asked for your mail open it. People who did not mark it as spam, and enough of those teach every major provider to filter you, for every recipient, including the ones who wanted it.
So: no purchased lists, ever. No adding people who bought something without asking them. No importing a contact list from your phone.
Confirmed opt-in (where the subscriber clicks a link in a confirmation email) costs you some signups and gives you a list that performs. On a list built any other way, the first send is where you find out.
Authenticate for the sending domain
Whatever service you use, it sends on your behalf, and receiving servers check whether it is allowed to.
SPF must include the service. DKIM keys from the service must be published in your DNS. DMARC tells receivers what to do when those fail.
All three are DNS records the service will give you. Publishing them is the difference between mail that arrives and mail that is treated as forgery. There is more on the syntax, including the one-SPF-record rule that catches people adding a second service in understanding SPF, DKIM and DMARC.
Use a subdomain for bulk
Send newsletters from news.example.com rather than the domain your business mail uses.
Reputation is tracked per sending domain. A subdomain isolates the newsletter's reputation, so a bad campaign does not affect whether your invoices arrive.
Set it up before you need it; a new sending domain starts with no reputation, and moving to one during a delivery problem means starting from nothing at the worst moment.
Warm up a new list slowly
Sending fifty thousand messages from an address that has never sent any is the pattern of a compromised account, and providers treat it that way.
Start with your most engaged recipients, recent signups, people who bought something, in the low hundreds, and increase over a few weeks.
Good early engagement teaches providers that your mail is wanted. Poor early engagement teaches the opposite, and unteaching it takes months.
The mechanics that stop complaints
A visible unsubscribe link in every message, that works in one click and takes effect immediately. A subscriber who cannot find it uses the spam button instead, which costs you far more.
A list-unsubscribe header, which puts an unsubscribe control in the mail client itself. Providers weight this heavily.
A recognisable From name and a subject that matches the content. Mail that looks like something else is reported as something else.
And your postal address, which is a legal requirement in several jurisdictions and which recipients read as a sign of legitimacy.
Clean the list
Remove hard bounces immediately, continuing to send to addresses that do not exist is a strong negative signal.
Then remove people who have not opened anything in a year. It feels like throwing away reach and it improves delivery for everyone remaining, because engagement rate is what providers measure.
A smaller list that opens beats a larger one that does not, and the difference is not marginal.
Discussion lists are a different thing
Everything above is about broadcast. A mailing list where subscribers reply to each other (a group discussion) is a different application with its own software, and the forwarding involved creates its own authentication problems.
Modern list software handles that by rewriting the sender. If you are running one, use software that does, instead of a set of forwarders; a plain forwarder relays mail that fails the original sender's checks, and your domain is credited with it. Shared and role-based mailboxes deals with that mechanism.
Test before every send
Send to yourself at two or three major providers, not just your own domain.
Check where it landed, check the authentication results in the headers, and check the unsubscribe link actually works from the received copy rather than from the preview.
Five minutes, before the send that goes to everybody.
A domain or address with no sending history is judged cautiously, and its first large send is judged harshly. How to Warm Up a New Sending Domain explains building up to it.