Why your cold email goes to spam, and how SPF, DKIM and DMARC fix it

You bought the domain, loaded the list, wrote the sequence, and sent three hundred emails. Zero replies. Not "bad" replies. Zero. So you send one to your own personal Gmail to test, and there it is, sitting in the spam folder.

This is almost never a copywriting problem. Before any spam filter reads a single word of your message, it asks a much simpler question: can this domain prove it sent this? If the answer is no, nothing else in the email matters. That proof is three DNS records, and this is what each one does, how to set it up, and what still breaks after you do.

Why is my cold email going to spam?

In almost every case it is one of three things: the sending domain is not authenticated with SPF and DKIM, there is no DMARC record, or the From address does not align with the domain that actually passed authentication.

Google publishes the exact consequences. Its sender guidelines FAQ lists the failure conditions and what happens for each: messages that are not authenticated with both SPF and DKIM, a From header that does not align with authentication, missing forward and reverse DNS records, or mail not sent over TLS all result in "Temporary or Permanent Failure codes, or spam foldering." A missing DMARC record does not get you rejected by itself, but it does make you ineligible for help: Google lists "DMARC record is missing (Minimum policy of none, p=none)" as making delivery support and mitigations unavailable.

Two dates matter. The requirements took effect in February 2024, and Google states that starting November 2025 it is "ramping up its enforcement on non-compliant traffic," with messages that fail the requirements experiencing "temporary and permanent rejections." The grace period is over.

There is also a threshold worth knowing, because most people misread it. A bulk sender is any sender that sends close to 5,000 messages or more to personal Gmail accounts within 24 hours, and messages from the same primary domain all count toward that limit so splitting sends across mail.yourdomain.com and promo.yourdomain.com does not get you under it. And it is one way: senders who cross the threshold even once are permanently classified as bulk senders.

What SPF, DKIM and DMARC actually do

SPF says which servers are allowed to send for your domain. DKIM signs each message so the receiver can verify it was not altered. DMARC ties both to the address your recipient actually sees, and tells the receiver what to do when the check fails.

Record	Answers the question	Where it lives
SPF	Is this server allowed to send as this domain?	One TXT record on your domain
DKIM	Was this message signed by the domain, and unmodified in transit?	A TXT or CNAME record on a selector subdomain
DMARC	Does the visible From address match what passed, and what should happen if not?	One TXT record at _dmarc.yourdomain.com

The third one is the piece people skip, and it is the piece that makes the first two meaningful. SPF and DKIM can both pass for a domain that has nothing to do with the address in your recipient's inbox. DMARC is what closes that gap.

How do I set up SPF correctly?

Publish exactly one SPF TXT record on the sending domain, list every service that sends on your behalf, and end it with ~all. Two SPF records is the most common misconfiguration, and it fails the whole domain.

A working record for a domain sending through Google Workspace and Mailgun looks like this:

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

Three rules that catch most people:

• One record only. If your DNS has two TXT records starting with v=spf1, SPF returns a permanent error and every message fails. Merge them into one.
• Ten lookup limit. Each include: costs a DNS lookup, and nested includes cost more. Past ten, SPF errors out. Audit what you actually still send from.
• Every sender listed. Your CRM, your cold email tool, your invoicing app, your form notifications. If it sends as your domain and it is not in the record, it fails.

Google's failure codes are specific enough to diagnose from a bounce. Code 4.7.27 means mail was rate limited because SPF did not pass; 5.7.27 means it was blocked for the same reason.

How do I set up DKIM?

Generate a key in your sending platform, publish the record it gives you at the selector it specifies, then turn signing on. The last step is the one that gets forgotten.

DKIM is per platform, not per domain. Google Workspace, Mailgun, SendGrid and your CRM each generate their own key and each needs its own record. Every one of them will hand you a hostname like google._domainkey.yourdomain.com and a long value to paste in.

The trap is that publishing the record does not enable signing. In Google Workspace you generate the key, add the DNS record, and then have to click "Start authentication" separately. Skip that and DKIM stays off while the DNS looks perfect. Codes 4.7.30 and 5.7.30 both mean DKIM did not pass.

What DMARC policy should I start with?

Start at p=none with a reporting address. It changes nothing about how your mail is handled and gives you two weeks of data on who is sending as your domain. Tighten from there.

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100

Then move up as your own mail proves itself: p=none to observe, p=quarantine to send failures to spam, p=reject to refuse them at the door. Most small businesses can reach p=reject within a month if they only send from services they have actually configured.

One subtlety that trips up people who did everything else right. Google requires bulk senders to set up both SPF and DKIM, but only one of them needs to be aligned with the From header to satisfy the alignment requirement. Aligned means the organizational domain matches. Google's own recommendation goes further: it advises all senders to fully align DMARC to both SPF and DKIM, and says it is likely that alignment with both will eventually be a requirement. Build it that way now.

Missing DMARC and misalignment have their own codes too: 4.7.31 means the domain has no DMARC record or the record specifies no policy, and 4.7.32 means the From header is not aligned with the authenticated SPF or DKIM domain.

Why authentication alone will not save your cold email

Authentication proves identity. It does not prove you are welcome. Gmail also measures how recipients react to you, and that number is unforgiving.

Google asks senders to keep user-reported spam rate below 0.1% and never let it reach 0.3%, and notes that rates above 0.1% already hurt inbox delivery for bulk senders. At 0.1%, one complaint in a thousand messages is your ceiling. On a list of two thousand, three annoyed people is enough to start the slide. And senders above 0.3% are ineligible for mitigation until they stay below it for seven consecutive days.

So the records are necessary, not sufficient. What still has to be true:

• Warm up the domain. A domain that sent nothing yesterday and two thousand messages today looks exactly like a spammer. Ramp over two to four weeks.
• Send from a subdomain for cold outreach. Keep the reputation risk off the domain your invoices and client mail depend on.
• Clean the list before you load it. Bounces to dead addresses damage reputation faster than almost anything else.
• Make replies possible. Deliverability gets you seen. A reply still needs a reason to write back, and a system to catch it when they do.

That last point is where most cold email actually leaks. When authentication is fixed and volume is up, replies arrive faster than anyone reads them. I built an n8n workflow that catches every reply, classifies sentiment with an LLM, and routes hot leads into the CRM as opportunities for exactly this reason. Fixing delivery without fixing intake just moves the bottleneck.

How do I check whether my domain is set up right?

Send one message to a personal Gmail address, open it, and read the authentication results in the original headers. Three PASS lines means you are done.

1. Send to a personal Gmail address, not a Workspace one. Google's sender requirements and enforcement apply only to mail sent to personal Gmail accounts, not to Google Workspace inbound or intra-domain messages.
2. Open the message, then choose Show original from the message menu.
3. Read the top three lines. You want SPF: PASS, DKIM: PASS, DMARC: PASS. Anything else names your problem.
4. If you send at volume, register the domain in Google Postmaster Tools, which reports your spam rate and authentication daily.

For a full worked example, the DNS and SMTP configuration case study walks through a real build: a Mailgun domain wired into Namecheap DNS with SPF, DKIM, MX, CNAME and DMARC all verified, then connected to a CRM through a dedicated sending key.

Sources

• Email sender guidelines FAQ — Google, Gmail Help. Enforcement table, error codes, bulk sender definition, spam rate thresholds, DMARC alignment.
• RFC 8058 — the one-click unsubscribe specification Google requires for marketing mail.
• Google Postmaster Tools — where spam rate and authentication results are reported per domain.

The order to do it in

1. Pick a sending domain or subdomain and decide what it is for.
2. Publish one SPF record listing every sender.
3. Generate and publish DKIM per platform, then switch signing on.
4. Publish _dmarc at p=none with a reporting address.
5. Verify with a real send to a personal Gmail account.
6. Warm up over two to four weeks while watching Postmaster Tools.
7. Tighten DMARC to quarantine, then reject.

None of this is difficult. It is fiddly, unforgiving of typos, and completely invisible when it works, which is why it stays broken in so many businesses for months.