Google and Yahoo updated their sender requirements to drop unauthenticated messages from any domain dispatching more than 5,000 emails a day. If your DNS records do not explicitly prove you own that domain, the receiving mail server drops the connection before reading your subject line.
Most founders spend hours tweaking preview text, testing emojis, and agonising over calls to action because the open rate dropped three points last Tuesday. But when an email lands in spam, the copy is almost never why. The receiving server makes its decision during the initial SMTP handshake—long before it parses the body text. Email deliverability isn't a writing challenge; it's network plumbing.
The three records that decide your fate
Every inbox provider runs an automated security gate at the front door. That gate looks for three specific DNS TXT records attached to your sending domain: SPF, DKIM, and DMARC.
SPF (Sender Policy Framework) is an explicit list of IP addresses permitted to send email on your domain's behalf. If you send transactional receipts through Postmark and marketing updates through Loops, both need to be listed. Leave one off, and receiving servers flag the message as suspicious.
DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every outgoing header. Your mail server signs it with a private key, and the receiving server verifies it using the public key published in your DNS. It proves the message wasn't intercepted or modified in transit.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells receiving inbox servers what to do when SPF or DKIM checks fail. A policy set to p=none merely collects diagnostic reports; inbox providers treat it as a temporary training mode. To reliably reach the inbox, that policy needs to step up to p=quarantine or p=reject. (We still see fast-growing companies operating with no DMARC policy at all, wondering why their password reset emails land in junk folders.)
When all three align, receiving mail servers trust that the sender is actually who they claim to be. Without them, even the most thoughtful letter written to a warm contact looks indistinguishable from a phishing attempt.
Why rewriting your copy won't fix a cold IP
Once authentication checks out, inbox providers evaluate sender reputation. Mail servers track every IP address and domain name like a credit agency tracks debt, maintaining continuous scorecards based on historical sending volume and recipient behavior.
If a domain suddenly blasts 50,000 messages after three months of total silence, receiving servers pause or throttle the incoming connections. They want to see consistent sending curves, low hard-bounce rates (typically under 0.5%), and zero hits on trap addresses. Spam traps are dead email addresses maintained by anti-spam organizations specifically to catch senders who buy lists or neglect list maintenance. Hitting just one can sink a domain's sending score overnight.
A team that suspects a deliverability problem usually responds by rewriting subject lines or removing trigger words like "free" or "discount." In reality, modern spam filters care far less about vocabulary than they do about engagement loops and technical alignment. If 15% of your list hasn't opened an email in six months and you keep sending to them, Gmail's algorithms learn that your content is unwanted. No amount of copy polish counteracts a high complaint rate or a flood of hard bounces.
The maintenance cost of staying out of spam
Email infrastructure isn't something you configure once on a Sunday afternoon and forget forever. Third-party tools update their sending IP pools, custom Return-Path domains break during provider migrations, and DKIM keys require periodic rotation.
Effective email operations rely on continuous monitoring:
- Tracking hard vs. soft bounces at the server log level to strip dead addresses immediately.
- Enforcing automatic sunset policies that unsubscribe contacts who have ignored the last thirty dispatches.
- Monitoring Google Postmaster Tools and Microsoft Smart Network Data Services (SNDS) for domain reputation drops.
- Separating transactional infrastructure (password resets, billing receipts) onto isolated subdomains like
auth.yourdomain.comso marketing campaigns never compromise critical application mail.
This is pure infrastructure maintenance. It requires checking server headers, verifying TLS connection security, and configuring webhook listeners for feedback loops. It is systematic, technical work—and it belongs entirely in the background, handled by automated pipelines or dedicated systems rather than the founder who should be focusing on the core product.
What clean delivery actually looks like
When a system is built correctly, email deliverability becomes invisible. Messages land in the primary inbox within seconds because every DNS record aligns, every key rotates on schedule, and bad addresses get purged automatically before they drag down sender health.
Setting this up requires three distinct layers:
- Hardened DNS infrastructure with aligned SPF, DKIM, and strict DMARC policies enforced on custom subdomains.
- Webhooks hooked directly into your application database to suppress bounced addresses and unsubscribe requests in real time.
- Automated warm-up ramps for any new IP or sending domain to establish a trustworthy track record before launching major dispatches.
When the underlying machinery functions properly, you never have to guess why a broadcast missed half your audience. The infrastructure earns trust silently on every dispatch, leaving you free to write messages people actually want to read.
Weekly Briefing
The studio briefing.
What we’re building across the portfolio, every Monday.
Written by
Founder, Total Ventures
Solo-founder building and operating a multi-brand product studio with AI agents. Writing about building, operating, and shipping.
