Ask why a cold email landed in spam and most answers reach for folklore: the wrong subject line, too many links, a word the filter supposedly hates. Some of that is superstition dressed as expertise. The real mechanism is duller and checkable: can the receiving server prove the mail is really from you, does your sending identity have any history, and does your behavior look like something a person would do. Get those three right and word choice barely matters.
Prove it's you: SPF, DKIM, and DMARC, precisely
These three exist to answer one question a receiving mail server has to ask about every message: is this actually from the domain it claims to be from, or is someone forging that domain? Without an answer, the server has no basis for trust and defaults to suspicion, because forging a "From" address costs a spammer nothing.
SPF (Sender Policy Framework) is a DNS text record you publish that lists which mail servers are allowed to send on behalf of your domain. The receiving server checks the server that actually delivered the message against that list. If it's not on the list, that's a strike against the message.
DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to each outgoing message, generated with a private key only your sending system holds. The receiving server fetches the matching public key from your DNS and checks the signature. A valid signature proves the message left a server that had your private key and wasn't altered in transit. A missing or broken one is a second strike.
DMARC sits on top of both. It's a DNS record that tells receiving servers what to do when SPF or DKIM fail: ignore it, quarantine it, or reject it outright. It also requires the domain that SPF or DKIM authenticated to match the domain in the visible "From" address, which closes a gap the other two leave open on their own. Without a DMARC policy, a receiving server has no instruction for what a failure should cost the message, so different providers guess differently, and your delivery gets inconsistent for causes that sit entirely outside what you wrote.
All three published correctly is table stakes, not an advantage. It's the minimum a receiving server needs before it will consider anything else about you at all.
A new domain has no history, and history is what's actually being judged
Authentication proves identity. It says nothing about reputation, and reputation is built the same way anyone's is: over time, through repeated behavior a third party can observe. A domain or mailbox with no sending history gives a mailbox provider nothing to check it against, so it gets treated cautiously by default, regardless of how careful your content is.
Warming is the process of manufacturing that history before you need it. Send a small, steady volume from a new domain or mailbox, and increase it gradually over several weeks, so that by the time you want to send real volume, there's an established pattern of a sender who behaves consistently rather than a domain that appeared yesterday and immediately fired off a few hundred messages. A cold domain sending two hundred messages on day one looks like a burst, whatever the message says, because volume that appears from nowhere is exactly the shape of an abuse pattern, and mailbox providers are built to notice that shape first and read content second.
It's also worth sending cold outreach from a dedicated sending domain or subdomain rather than the root domain your invoices, support replies, and password resets depend on. If a sending mistake damages reputation, you want that damage contained to the domain built for it, not spreading to the one your existing customers rely on to hear from you at all.
Opens are close to worthless now; replies are the real signal
Open tracking works by loading a tiny image, and "opened" gets logged the moment that image loads. Several major mail clients now pre-fetch images automatically, before a human has looked at anything, specifically to protect user privacy from senders trying to track them. That means a real, meaningful slice of your open rate is a mail client behaving like a mail client, not a person behaving like a buyer. Treat the number accordingly.
A reply is a much harder signal to fake, because producing a coherent one requires an actual person to read your message and decide it deserves a response. Mailbox providers weigh engagement of that kind heavily, precisely because it's expensive to manufacture at scale. On the other side of the ledger, two signals are almost purely negative and mailbox providers act on them directly: a hard bounce, meaning the address doesn't exist, and a spam complaint, meaning a human pressed the button. Both cost you reputation in a way no clever subject line earns back.
List hygiene is most of the mechanism, not a nice-to-have
Repeatedly sending to a dead address looks, from a mailbox provider's side, identical to what an automated system with no idea whether anyone's home would do. So the moment an address hard-bounces, stop sending to it, permanently, and confirm your sending tool actually does this rather than assuming it does.
Avoid sending cold outreach to role addresses like a generic sales or info inbox: they get read by whoever's turn it is, get reported as spam at a higher rate than a named person's address, and rarely produce the kind of individual reply that builds reputation. And be careful with old or scraped contact lists. Stale data raises your bounce rate directly, and a portion of old, abandoned addresses on any list have quietly become spam-trap addresses maintained specifically to catch senders who aren't checking their lists. Verified, recently confirmed addresses aren't a luxury at low volume. They're the cheapest lever you have, because at forty sends a week you can actually check them.
Most of this you can and should check yourself before sending anything at scale. Some of it is easier to get right when the software sending on your behalf refuses to skip it: Rocketship checks that your sending domain is actually authenticated before your first message leaves it, and it drops a hard-bounced address rather than quietly sending to it again next week. That's not a feature so much as an admission that the mechanics above are unglamorous enough that a startup writing its own code every morning will eventually forget one of them, and the cost of forgetting lands on a domain you'll want intact for years.
None of this is about outsmarting a filter
A filter isn't looking for clever phrasing to catch you on. It's looking for evidence that you're a real, consistent, accountable sender: authenticated, built up gradually, replied to by actual humans, and careful about who's still on your list. A startup that does those four things honestly doesn't need a trick for the fifth. There isn't one worth having.