Why your cold email lands in spam (and the DNS records that fix it)

There is a specific, deflating moment in every founder's outbound journey: you write forty careful emails, send them to people who genuinely should want your product, and hear nothing. Not rejection — silence. When you finally test your own domain against a seed inbox, you find all forty sitting in spam. The copy was never the problem. The infrastructure was.

Mailbox providers like Gmail and Microsoft decide where your message lands before a human ever sees it, and the first thing they evaluate is not your subject line. It is whether your domain can prove, cryptographically and via DNS, that the message is legitimate. This post walks through exactly what they check, why unauthenticated mail fails, and the three records that fix the majority of spam placement problems.

How inbox placement actually gets decided

When your message arrives at Gmail's servers, it passes through three gates in order. First, authentication: does the sending server have permission to send for this domain, and is the message unaltered? Second, reputation: what is the sending history of this domain and this IP — bounce rates, complaint rates, volume patterns? Third, engagement and content: do recipients open, reply, and move these messages, and does the content pattern-match known spam?

The gates are sequential in effect. If you fail authentication, your reputation barely matters — since February 2024, Google and Yahoo both require SPF and DKIM for bulk senders and reject or junk mail that fails. If your authentication passes but your domain is three days old with no sending history, you fail the reputation gate instead. Most "my cold email doesn't work" problems live at gate one or gate two, which is good news: those gates are mechanical, and mechanical problems have mechanical fixes.

The three DNS records that do the work

SPF: the list of allowed senders

SPF (Sender Policy Framework) is a TXT record on your domain that lists every server allowed to send mail on its behalf. When a receiving server gets a message claiming to be from you@yourdomain.com, it looks up that record and checks whether the connecting IP is on the list. A minimal record for a domain sending through one provider looks like this:

v=spf1 include:_spf.google.com ~all

Two failure modes matter. A missing record means every receiver treats your mail as unverifiable. And a record with more than 10 DNS lookups — easy to hit if you have stacked include: statements from years of tools — returns a permanent error that counts as a failure. Audit your includes and remove services you no longer use.

DKIM: the tamper-proof signature

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every outgoing message, generated with a private key your sending provider holds. The matching public key is published as a TXT record on a subdomain like selector1._domainkey.yourdomain.com. Receivers verify the signature against the public key; if the message was altered in transit or the key doesn't match, DKIM fails. Unlike SPF, DKIM survives forwarding, which is why receivers weight it heavily. You don't generate this key yourself — your provider does, and you publish the record they give you.

DMARC: the policy that ties it together

DMARC answers the question the other two records leave open: what should a receiver do when authentication fails, and — critically — do the authenticated domains actually match the one in the From header? A starter policy looks like this:

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

Start with p=none, which enforces nothing but sends you aggregate reports on who is sending as your domain. Once your legitimate mail passes cleanly for a few weeks, tighten to p=quarantine. Since 2024, having a DMARC record at all is a hard requirement at Google and Yahoo for anyone sending 5,000+ messages a day — but even at low volume, its absence is a negative signal.

The problems DNS can't fix

Perfect authentication gets you to the reputation gate; it doesn't get you through it. Three habits do the rest of the damage:

• Sending from a cold domain. A domain with no sending history that suddenly sends 200 messages a day looks exactly like a compromised account. New domains need weeks of gradually increasing, engaged sending before they carry real volume — this is what warmup is for.
• Sending from your primary domain. One bad campaign can poison the domain your entire company depends on. Use separate sending domains (yourdomain-hq.com, tryyourdomain.com) so outbound risk never touches your root.
• Unvalidated lists. Every hard bounce tells the receiver you don't know who you're mailing. A bounce rate above 2% erodes reputation fast; above 5% and you're in serious trouble. Validate before you send, not after.

The 20-minute fix, in order

1. Buy a dedicated sending domain and set up mailboxes on it — leave your primary domain out of outbound entirely.
2. Publish SPF listing only your actual sending provider, and confirm you're under the 10-lookup limit.
3. Enable DKIM at your provider and publish the key they generate.
4. Publish DMARC at p=none with a reporting address, and plan to tighten it after two clean weeks.
5. Wait for propagation (minutes to a few hours for most registrars), then verify all three records before sending a single message.
6. Warm the mailboxes up before real campaigns, and validate every list before import.

None of this is glamorous, which is exactly why it's a competitive advantage: most of your competitors skip it. When you add a domain in SendCanyon, we list the SPF, DKIM, and DMARC records to publish, check them against live DNS, and block campaign sending until all three verify — so the failure mode described in this post is one you simply can't ship.

Fix the records, respect the ramp, validate the list. Then — and only then — does the quality of your copy start to matter.