Self-Hosted Email Deliverability: SPF, DKIM, DMARC, Warm-Up

If your self-hosted newsletter lands in spam, the cause is almost never the writing. It is a missing DNS record, a cold sending IP, or a list full of people who stopped opening months ago. Since February 2024, Gmail and Yahoo enforce explicit technical requirements for senders, and since May 2025, Outlook rejects non-compliant bulk mail outright. The fix is a known checklist: four authentication records, a deliberate warm-up, disciplined list hygiene, and two free monitoring tools. This post is that checklist, written for someone running Listmonk, Mautic, or their own mail setup on a VPS.

The rules mailbox providers now enforce

Three sets of requirements define the game, and they are public documents, not folklore.

Google. Since February 1, 2024, every sender to personal Gmail accounts must publish SPF or DKIM, have valid forward and reverse DNS for sending IPs, send over TLS, and keep the spam rate in Postmaster Tools below 0.3%. If you send 5,000 or more messages per day to Gmail, the bar rises: SPF and DKIM, a DMARC record (p=none is acceptable), alignment between the From domain and the SPF or DKIM domain, and one-click unsubscribe for marketing mail. Unauthenticated mail can be rejected with a 5.7.26 error. Source: Google email sender guidelines.

Yahoo. Yahoo's rules, enforced from February 2024, mirror Google's: SPF or DKIM for everyone; SPF plus DKIM plus a passing DMARC policy for bulk senders; spam complaint rate below 0.3%; and one-click List-Unsubscribe, with unsubscribe requests honored within two days. Yahoo also recommends a minimum 1024-bit DKIM key and segregating bulk mail from transactional mail on separate IPs. Source: Yahoo Sender Hub best practices.

Microsoft. From May 5, 2025, domains sending 5,000 or more messages per day to Outlook.com consumer addresses must pass SPF, DKIM, and DMARC (at least p=none, aligned with SPF or DKIM). Non-compliant messages are not junked; they are rejected with "550; 5.7.515 Access denied, sending domain does not meet the required authentication level." Source: Microsoft's announcement on the Exchange team blog.

Two takeaways. First, the 5,000-per-day threshold applies per mailbox provider, and a modest newsletter can cross it if a third of your list uses Gmail. Second, even below the threshold, the "all senders" requirements still apply to you. Treat the bulk-sender bar as your target regardless of size, because it is also simply what good looks like.

The four records that decide whether you exist

Everything in this section is DNS. If you can edit your domain's zone file, you can do all of it in an afternoon.

SPF: who may send for your domain

SPF is a TXT record listing the hosts allowed to send mail for your domain. If you send through Amazon SES, it looks like this:

v=spf1 include:amazonses.com ~all

Three ways to break it, all common:

• Two SPF records. A domain must have exactly one TXT record starting with v=spf1. Two records produce a permanent error, and many receivers treat that as a failure. Merge them into one.
• More than 10 DNS lookups. The SPF specification (RFC 7208, section 4.6.4) caps the number of mechanisms that trigger DNS lookups, such as include, a, and mx, at 10. Every SaaS tool you add ("include our mail service") spends some of that budget. Exceed it and SPF evaluation fails. Microsoft's sender FAQ calls this out explicitly.
• Using +all or ending without ~all or -all. +all authorizes the entire internet to send as you. Start with ~all (softfail) while you verify, then move to -all.

DKIM: prove the message is yours and unchanged

DKIM adds a cryptographic signature to each message; receivers verify it against a public key you publish in DNS. For a newsletter through a relay like SES, the provider gives you the records to publish (SES uses three CNAME records per domain). Two things matter operationally:

• Key length. 1024-bit is the stated minimum for both Gmail and Yahoo; Google recommends 2048-bit. Use 2048 where your provider supports it.
• The signing domain. DKIM alignment for DMARC means the domain in the DKIM signature matches the domain in your From header. Sign with your own domain, not the relay's default.

DMARC: tie it together and get reports

DMARC does two jobs: it tells receivers what to do when SPF and DKIM both fail for mail claiming to be from your domain, and it sends you aggregate reports about who is sending mail using your domain. A starting record:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

The deployment path recommended by dmarc.org is deliberate: publish p=none with a reporting address, read the reports for a few weeks to find every legitimate sender (your newsletter tool, your CRM, your invoicing app), fix their SPF/DKIM alignment, then move to p=quarantine and finally p=reject. Skipping to p=reject on day one is how companies break their own password-reset emails. For Gmail, Yahoo, and Outlook compliance, p=none is technically enough, but p=none gives you no protection against spoofing, so treat it as a waypoint, not a destination.

PTR: the one record you cannot set yourself

Reverse DNS maps your sending IP back to a hostname, and that hostname's A record must resolve back to the same IP. Google requires this of all senders; Yahoo asks for non-generic PTR records that reflect your domain. If you send through SES or another relay, the provider owns the IPs and handles PTR. If you run your own MTA on a VPS, you set PTR through your hosting provider's control panel, and many cloud providers refuse to set it on default instances at all. This single record is a recurring reason the "I'll run my own SMTP server" plan stalls.

Shared IP, dedicated IP, or your own server

This decision drives both cost and how much of this guide you have to do by hand.

Shared IP pool on a relay (the default). You send through SES, Mailgun, or similar, mixed with their other customers. Amazon SES à la carte pricing is $0.10 per 1,000 emails, so a 25,000-subscriber weekly newsletter costs about $13 a month in sending fees. The relay manages the pool's reputation and warm-up. The risk is neighbor noise: another sender's bad behavior can drag the pool. In practice the large providers police their pools aggressively, and for lists under roughly 50,000 this is the right choice. If you are weighing the platform costs around this, our breakdown of Listmonk vs Mailchimp cost at 25,000 subscribers runs the numbers.

Dedicated IP on a relay. You rent an IP only you send from. SES charges $24.95 per month per standard dedicated IP, or $15 per month per account plus a per-email fee for the managed option, per the Amazon SES pricing page. You get full control of the IP's reputation, and full responsibility: a fresh dedicated IP has zero reputation and must be warmed up (next section). A dedicated IP earns its keep when you send high, steady volume, think 100,000+ messages a month on a regular cadence. Below that, or with irregular sending, the IP never stays warm and you are worse off than on a good shared pool.

Your own MTA. Maximum control, maximum work: PTR records, blocklist monitoring, feedback loops, warm-up, and abuse handling are all yours. Choose this only with a specific reason, such as data residency, and a person who owns it. For everyone else, the pragmatic architecture is a self-hosted front end like Listmonk, the open-source newsletter manager (a single Go binary plus PostgreSQL), sending through a relay's SMTP or API. We published a step-by-step guide to self-hosting a newsletter with Listmonk and Amazon SES that covers the wiring.

A four-week warm-up plan for a new IP

Warm-up is how a new IP builds reputation: start small, send to your most engaged subscribers first, and grow volume while the metrics stay clean. Here is a concrete schedule for a 25,000-subscriber list moving to a new dedicated IP, sending one campaign per week.

Week 1: 250 to 500 per day. Send only to subscribers who opened in the last 30 days. That is typically 20 to 30% of a healthy list, so you are sending to your best 5,000 to 7,500 people in small daily slices. Same time each day.

Week 2: 1,000 to 2,000 per day. Expand to subscribers active in the last 90 days. Roughly double every two to three days.

Week 3: 4,000 to 8,000 per day. Add the rest of the engaged list. Start including older segments in small test slices.

Week 4: full volume, in tranches. Send the whole list, but split the send across the day rather than in one burst.

The gates that matter between steps:

• Spam rate in Postmaster Tools stays well under 0.3%. If it climbs toward that line, hold volume flat until it drops. 0.3% is the published ceiling for both Google and Yahoo, not a target.
• Delivery errors stay boring. A spike in 4xx deferrals from one provider means that provider is throttling you; slow down there.
• Complaints and bounces trend down, not up. SES can push bounce, complaint, and delivery events to SNS, so wire those into something you actually watch; this is the kind of glue we build with business automation workflows when a team has no one staring at dashboards.

Two rules override the calendar. Engaged subscribers first, always, because their opens and clicks are the reputation signal. And never double volume on a day when any gate looks wrong. A warm-up that takes five weeks beats one that takes three weeks and lands you on a blocklist in week six.

List hygiene: the part you cannot automate away

Authentication gets you evaluated. List quality decides the verdict. The requirements documents are blunt about this:

• Confirm opt-in. Yahoo explicitly recommends confirming subscriptions by email before adding addresses. Double opt-in also kills typos and bot signups at the source.
• Never buy a list. Both Google and Yahoo say it directly. Purchased lists are the fastest route to spam traps, which are addresses that exist only to identify senders with bad sourcing.
• Remove hard bounces immediately. An address that does not exist is a reputation cost every time you mail it. Your relay reports these; suppress them on the first event, not after a quarterly cleanup.
• Suppress complainers. When someone hits "report spam," that is an unsubscribe with extra damage. Yahoo's Complaint Feedback Loop, available once you sign with DKIM, sends you a copy of each complaint so you can remove the address.
• Honor unsubscribes within two days, and make the link obvious. One-click List-Unsubscribe (RFC 8058) is a hard requirement for bulk senders at all three major providers.
• Re-confirm or sunset inactive subscribers. Someone who has not opened in six months is not an asset; they are a future spam complaint. Send a re-confirmation campaign, then stop mailing the ones who do not respond.

A smaller list that opens is worth more to your deliverability than a bigger list that ignores you. This is the least technical section of this post and the one that most determines whether the technical work pays off.

Monitoring: two free tools and a habit

Google Postmaster Tools is the closest thing to a ground truth for Gmail delivery. Add your DKIM or SPF domain at postmaster.google.com, verify it with a TXT or CNAME record at your DNS provider, and you get dashboards for spam rate, domain and IP reputation, authentication pass rates, and delivery errors. The setup documentation walks through it. Two caveats: data covers personal Gmail only, and low-volume days may show nothing at all, so check it weekly and read trends, not single days.

DMARC aggregate reports arrive as XML at the rua address in your DMARC record. They show every source sending mail as your domain and whether it passes. Raw XML is unreadable at volume, so point the address at a parser (open-source options like parsedmarc exist, as do hosted services). The payoff is catching legitimate services you forgot about, and catching strangers spoofing you early.

The habit that ties it together: after every campaign, spend five minutes on bounce rate, complaint rate, and Postmaster Tools. Deliverability problems are cheap to fix on day one and expensive on day thirty.

Common mistakes

The patterns behind most "our newsletter goes to spam" tickets:

• Two SPF records on the domain, created by adding each vendor's record without merging.
• SPF lookup limit exceeded after years of "just add this include" from SaaS vendors.
• Publishing p=reject before auditing, which rejects your own legitimate mail from services you forgot.
• Marketing and transactional mail mixed on one IP and domain, so a promotional campaign's complaints damage your invoice delivery. Yahoo explicitly recommends segregating them.
• Blasting a five-year-old export on a brand-new IP as the first send.
• No PTR record on a self-hosted MTA, or a generic one like ec2-12-34-56-78.compute-1.amazonaws.com.
• Setting everything up, then never looking at Postmaster Tools or DMARC reports again.
• Treating 0.3% spam rate as the goal. It is the cliff edge. Healthy newsletters sit far below it.

When self-hosting sending is the wrong choice

Honesty section, because this is a guide about self-hosted deliverability:

• Your list is small and you email irregularly. A shared IP pool on any reputable relay or a hosted newsletter service will outperform anything you warm up yourself, because warm-up requires consistency.
• Nobody owns it. Deliverability is an operational practice, not a one-time setup. If no one will check the dashboards after each campaign, pay for a service where that is someone else's job.
• You need rich engagement analytics fast. Listmonk tracks opens and clicks, but if your marketing team lives in journey builders and engagement scoring, a hosted platform fits better, and deliverability comes bundled. If you are running the same self-hosted-vs-hosted calculation for the rest of your stack, our cost breakdown of Twenty CRM vs HubSpot for a 20-person sales team shows how the trade-off plays out for CRM.

Frequently asked questions

Do I need DMARC if I send fewer than 5,000 emails a day?

Not strictly: Gmail and Yahoo require SPF or DKIM below the bulk threshold, and Microsoft's hard enforcement targets 5,000-plus senders. But a p=none record with a reporting address costs you nothing, gives you visibility into who sends as your domain, and future-proofs you as your list grows. Publish it.

How long does IP warm-up take?

Plan on three to five weeks for a mid-size list, as in the schedule above. The variable is your engaged segment size: if only 2,000 of your 25,000 subscribers are active, the early weeks move slower because you have fewer safe recipients. You cannot shortcut it by sending to unengaged addresses faster; that is how IPs get blocked before they ever warm.

Is a dedicated IP worth it for a 10,000-subscriber newsletter?

Usually no. At that volume, sending a few times a month, a dedicated IP never accumulates enough consistent signal to build a strong reputation, so you carry all the warm-up burden with none of the payoff. A well-managed shared pool, at $0.10 per 1,000 emails on SES, is the better tool. Reconsider when you pass roughly 100,000 messages a month on a steady cadence.

What spam complaint rate is acceptable?

Both Google and Yahoo publish 0.3% as the ceiling, measured against mail delivered to the inbox. Stay well below it; if you are regularly near 0.3%, you have a list-quality or expectation problem that thresholds will not save you from.

Does a 1024-bit DKIM key still work?

Yes. It meets the stated minimum for Gmail and Yahoo. Google recommends 2048-bit, so use 2048 if your relay or MTA supports it, but a working 1024-bit setup is not an emergency.

Can I skip warm-up if my domain already has a good reputation?

Domain reputation helps and increasingly matters, but IP reputation is still evaluated separately, so a cold IP with a good domain will still get throttled and filtered at volume. Warm the IP anyway; a strong domain makes the process smoother, not unnecessary.

Where to go from here

Deliverability is a checklist plus a habit: four DNS records, a patient warm-up, a clean list, and five minutes of monitoring per campaign. If you would rather have that stack, Listmonk on your infrastructure, SES underneath, authentication and monitoring configured and watched, deployed and run for you, that is exactly what our managed open-source stack service does for email, analytics, scheduling, and the rest of the self-hosted toolkit.