Your cold email is landing in spam and it is probably not your copy: the complete SPF, DKIM, DMARC and MTA-STS setup, with the DNS records written out

Since February 2024, Google and Yahoo enforce authentication on bulk senders. Microsoft followed in May 2025 for anyone sending over 5,000 a day to Outlook, Hotmail or Live addresses. If you send cold email without all three of SPF, DKIM and DMARC passing, you are not fighting a filter, you are failing a doorman check before the filter ever reads your subject line.

I get asked to look at "bad copy" a lot. Maybe a third of the time the copy is fine and the domain is broken. So here is the whole authentication layer, written the way I wish someone had written it for me, with the actual records.

What each one does, briefly

SPF answers "is this server allowed to send for this domain". It is a DNS TXT record listing allowed senders. It checks the envelope sender (the Return-Path), not the From: header your recipient sees.

DKIM answers "was this message modified in transit, and does the domain vouch for it". Your sending server signs the message with a private key. The public key sits in DNS. The receiver verifies the signature.

DMARC ties them together. It requires that SPF or DKIM not only pass but pass for the same domain shown in the From: header. That is called alignment, and it is the part almost everyone misses. It also tells receivers what to do on failure and where to send reports.

You can pass SPF and DKIM and still fail DMARC. That happens constantly.

SPF, and the ten-lookup cliff

One record per domain. Never two. Two SPF records is a permerror and the whole thing fails.

v=spf1 include:spf.your-mailbox-provider.com include:spf.your-sending-tool.com ~all

The parts:

• v=spf1 version, always first
• include: pulls in your provider's list of sending IPs
• ip4: / ip6: for your own servers
• ~all softfail for everything else
• -all hardfail

Use ~all unless you have a specific reason not to. -all is stricter but it will bite you the day you forward mail or add a new tool and forget the record. The difference in practice is small, because DMARC is what actually determines the outcome.

The ten-lookup limit is the thing that breaks people. SPF evaluation is capped at 10 DNS lookups. Every include:, a, mx, ptr and redirect counts, and includes nest. A single mailbox provider's include commonly costs three or four lookups on its own, because their record includes further records. Stack your mailbox provider plus a CRM plus a helpdesk plus a marketing tool and you are over. Over the limit is a permerror, and a permerror means SPF fails for everything, including mail that would otherwise have passed.

Check it with any SPF flattening or lookup counter tool before you assume you are fine. If you are over, either drop unused includes or flatten to raw IPs and accept that you now have to maintain them.

Two things include: is not: it is not permission for that provider to send as you in a way you control, and it does nothing for alignment on its own.

DKIM, and why 1024 bits is not enough anymore

Your ESP generates a keypair and gives you a public key to publish. The record lives at a selector:

selector1._domainkey.yourdomain.com TXT v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...

The selector is just a label, so you can have several keys at once. That matters when you rotate.

Use 2048-bit keys. Many older setups issue 1024-bit, and some receivers now treat those as weak. If your ESP offers a choice, pick 2048. If the record is too long for a single TXT string, split it into chunks inside the same record, most DNS hosts do this automatically.

Rotate keys roughly every six months to a year. The sane rotation is: publish the new selector, wait for propagation, switch the signer to it, leave the old selector published for a couple of weeks, then remove.

One rule people break: sign with the domain in your From: header. If you send From: you@company.com but the DKIM signature is d=esp-tracking.net, it verifies fine and still fails DMARC alignment.

DMARC, and the field everyone gets wrong

Start here:

_dmarc.yourdomain.com TXT v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1

p=none means "do nothing, just report". Run it for two to four weeks and read the reports. You will find sending sources you forgot existed. Then move to p=quarantine, then p=reject.

Do not start at p=reject. You will silently kill your own invoicing system, your helpdesk, or whatever tool someone in ops set up two years ago.

The tags worth knowing:

• p= policy: none, quarantine, reject
• rua= where aggregate reports go, daily XML summaries
• ruf= forensic reports, mostly ignored by receivers now, and they can contain message content, so think before enabling
• pct= percentage of failing mail the policy applies to, useful for a staged rollout at 10, then 50, then 100
• sp= policy for subdomains
• adkim= and aspf= alignment mode, r for relaxed, s for strict

Relaxed alignment (r) is the default and it is what you want. Relaxed means the organizational domain has to match, so mail.company.com aligns with company.com. Strict means exact match. Almost every reported "DMARC fails and I do not know why" I have looked at was strict mode plus a subdomain sender.

Aggregate reports arrive as XML and are unreadable by eye. Pipe them into any free DMARC report parser. What you are looking for is any source sending as you that you cannot account for.

The alignment trap, spelled out

This is the single most common failure and it deserves its own section.

You send from you@company.com. Your sending tool uses its own Return-Path, something like bounces@esp-provider.net. SPF checks the Return-Path, so SPF passes for esp-provider.net. DKIM signs with d=esp-provider.net, so DKIM passes for esp-provider.net.

Both pass. DMARC still fails, because neither passing domain matches company.com in the From: header.

The fix is a custom return path, sometimes called a custom bounce domain or custom MAIL FROM. Your ESP gives you a CNAME:

bounce.company.com CNAME esp-bounce-host.net

Now the Return-Path is a subdomain of yours, SPF passes for it, and relaxed alignment matches it to company.com. Set this up. It is usually a single record in your ESP's settings and it converts a permanent DMARC failure into a pass.

MTA-STS and TLS-RPT, the part almost nobody does

SMTP encryption is opportunistic by default, which means it can be stripped. MTA-STS tells senders to require TLS to your domain.

You need three things:

A DNS record: _mta-sts.yourdomain.com TXT v=STSv1; id=20260806000000

A policy file served over HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt: version: STSv1 mode: enforce mx: mail.yourdomain.com max_age: 604800

And start in mode: testing before enforce, same logic as p=none.

Add TLS reporting alongside it: _smtp._tls.yourdomain.com TXT v=TLSRPTv1; rua=mailto:tls@yourdomain.com

This does not directly change inbox placement. It signals a properly run domain, and it protects against downgrade attacks on mail coming to you. It costs an afternoon.

BIMI is the other one people ask about. It puts your logo in the inbox. It requires DMARC at enforcement plus, for Gmail and Apple, a Verified Mark Certificate that costs over a thousand dollars a year and needs a registered trademark. Skip it until the rest is solid and you have volume that justifies it.

Reverse DNS, and the checks nobody mentions

If you send from your own IP, the PTR record for that IP must resolve to a hostname, and that hostname must resolve back to the same IP. Broken PTR is an instant negative signal. If you are on a shared ESP, this is their problem, not yours.

Also worth checking:

List-Unsubscribe. Since the 2024 rules, bulk senders need one-click unsubscribe. Two headers: List-Unsubscribe: <https://yourdomain.com/u/abc123>, <mailto:unsub@yourdomain.com> List-Unsubscribe-Post: List-Unsubscribe=One-Click The POST header is what makes it one-click. Without it you have the old two-step version and Google counts it as non-compliant.

Spam rate under 0.3% in Google Postmaster Tools, per Google's own threshold. Above 0.1% and you should already be worried. Register your domain in Postmaster Tools, it is free and it is the only direct view into how Gmail sees you.

Cold email specifics

Everything above applies to anyone sending email. These are the parts specific to outbound.

Send from a separate domain. Buy a lookalike, getcompany.com or company-hq.com, and run cold outreach from that. Authenticate it properly, exactly as described above. If it burns, your main domain and everything that runs on it stays clean. This is not optional at any real volume.

Warm up for two to four weeks. New domains and new IPs have no reputation. Start at five to ten a day per mailbox, increase gradually. There is no fixed schedule that works everywhere, so watch bounce rate and spam complaints instead of following a calendar.

Cap volume per mailbox. 30 to 50 a day is the range that holds up. Add mailboxes for more volume, do not push a single one harder.

Give the domain age before it sends. A domain registered this week that starts sending cold email is the strongest possible negative signal. Register, set up authentication, park it for a few weeks.

Watch bounces hard. Anything above 3 to 5 percent means your list is bad and continuing will hurt the domain. Verify before sending, and remove hard bounces immediately rather than at the end of a sequence.

The order to do this in

1. Buy the sending domain, set up mailboxes
2. Publish SPF, one record, verify you are under ten lookups
3. Enable DKIM at 2048 bits, verify the signing domain matches your From:
4. Set up the custom return path so alignment passes
5. Publish DMARC at p=none with an rua address
6. Read the reports for two to four weeks
7. Move to p=quarantine, then p=reject
8. Add MTA-STS in testing mode, then enforce, plus TLS-RPT
9. Register in Google Postmaster Tools
10. Warm up, then send

Steps 2 through 5 take under an hour once you know what you are doing. Step 6 is waiting.

How to check your work

Send a message to a Gmail account you control, open it, and use "Show original". You want three lines all reading PASS: SPF, DKIM, DMARC. If any says NEUTRAL, SOFTFAIL or FAIL, go back.

There are plenty of free tools that will mail you a report, and any of them are fine. But the Gmail headers are the ground truth for the mailbox you most care about.

Post your DMARC record if something is failing and you cannot work out why. The alignment issue is nearly always visible from the record plus one header dump.