TLDR

Today I put three senders on our own domain: a Microsoft 365 mailbox, MailerLite, and Resend. The part that almost broke it was not warmup. It was DNS: two tools each wanted their own SPF record, and one wanted an MX record that would have collided with our mailbox.

The direct answer: a working cold email setup needs exactly one SPF record per domain that stays under 10 DNS lookups, a DKIM key for every service that sends as you, a DMARC record (at least p=none) with reporting turned on, and a From domain that aligns with SPF or DKIM. Send from a separate domain, ramp volume slowly, verify every sender with Gmail’s “Show original,” and treat the 0.3% spam complaint line from Google and Yahoo as a hard ceiling.

What the inbox providers actually require

Most cold email advice is written by tool vendors. Start with the rules from the companies that run the inboxes instead.

Google (Gmail). Every sender must set up SPF or DKIM, have valid forward and reverse DNS, use TLS, and keep the spam rate reported in Postmaster Tools below 0.3%. Senders of more than 5,000 messages a day to personal Gmail accounts must have both SPF and DKIM, a DMARC record (p=none is acceptable), a From domain aligned with SPF or DKIM, and one-click unsubscribe on marketing messages. Google recommends staying under 0.1% spam rate. (Google Email sender guidelines)

Two details in Google’s FAQ matter for cold email strategy. Volume is counted by primary domain, so mail from outreach.yourco.com and yourco.com adds up together. And a sender that crosses the bulk threshold once is “permanently considered” a bulk sender. (Google Email sender guidelines FAQ)

Yahoo. The same structure: SPF or DKIM for everyone; SPF and DKIM, DMARC at p=none or stricter that passes, aligned From domain, one-click unsubscribe, and unsubscribes honored within 2 days for bulk senders. Spam rate below 0.3%. (Yahoo Sender Best Practices)

Microsoft (Outlook.com, Hotmail, Live). Senders of 5,000 or more messages to Microsoft consumer services from the same From domain must publish SPF and DKIM, publish a DMARC record of at least p=none, and pass DMARC with alignment. Mail that fails can be rejected with 550 5.7.515 Access denied, sending domain does not meet the required authentication level. (Microsoft Support: Fix NDR error 550 5.7.515; Microsoft announcement)

One honest note: Google’s guidelines also say not to buy lists or send to people who did not sign up. Authentication proves who you are; it does not make unwanted email wanted. This setup keeps relevant B2B outreach from being filtered for technical reasons. It will not rescue a bad list or offer.

Step 1: Decide which domain sends

You have three realistic choices. None is best for everyone.

A separate domain (for example tryyourco.com)

  • Choose this if: you plan meaningful daily volume, or your main domain carries invoices, support and sales replies you cannot afford to lose.
  • Skip this if: you send a handful of hand-written emails a day and the extra domain would look odd to buyers who check.
  • Trade-off: it needs its own mailboxes, its own DNS records and its own warmup, and it starts with no reputation.

A subdomain (for example go.yourco.com)

  • Choose this if: you want brand continuity and separate DNS records, and your total volume stays well below the bulk thresholds.
  • Skip this if: you expect to cross 5,000 a day. Google counts subdomain volume toward the primary domain, so a subdomain does not separate you from Google’s bulk rules.
  • Trade-off: reputation is not fully isolated from the parent domain.

Your primary domain

  • Choose this if: the outreach is low volume, personal, and replies need to land in the same inbox your team already uses.
  • Skip this if: any of the email is high volume or automated.
  • Trade-off: if complaints climb, the domain that carries your day-to-day business mail takes the hit.

Every vendor guide we reviewed defaults to a separate domain. The deciding variables are volume and risk tolerance.

Step 2: Build one SPF record, and count the lookups

SPF is a TXT record listing who may send mail for your domain. Two rules from the standard cause most failures.

Only one SPF record per domain. RFC 7208 says a domain “MUST NOT have multiple records” that would select more than one SPF policy, and if more than one is found the check returns a permanent error. (RFC 7208, section 3.2 and 4.5) In plain terms: when your newsletter tool tells you to “add this SPF record,” and you already have one for your mailbox, you do not add a second record. You merge the new include: into the existing one.

Here is ours after adding a second sending service:

v=spf1 include:_spf.mlsend.com include:secureserver.net -all

One record, both senders, ending in -all (anything not listed fails).

No more than 10 DNS lookups. The include, a, mx, ptr and exists mechanisms and the redirect modifier each trigger a lookup, and implementations “MUST” stop at 10 and return a permanent error. Void lookups (queries that return nothing) should be capped at two. (RFC 7208, section 4.6.4) The trap: an include: counts as one lookup for you, but every include inside the vendor’s record counts too. Three or four tools can quietly push a record past 10, and nothing in your DNS dashboard will warn you. You need a checker that resolves the includes recursively.

Step 3: Watch for MX conflicts when you add a sending service

Some sending services ask you to add an MX record, usually so they can receive bounces or replies. If that record goes on your root domain, it can compete with the MX records your mailbox provider already uses, and inbound mail can start going to the wrong place.

The fix we used: put any sending service’s receiving or bounce records on a subdomain the service owns (many services default to something like send.yourco.com or bounce.yourco.com), and leave the root domain’s MX records pointing only at your mailbox provider. Before you click “verify” in any tool, look at what it asks you to add at the root.

Step 4: Turn on DKIM for every service that sends as you

DKIM signs each message with a key published in your DNS. Every service that sends mail with your From address needs its own DKIM record, usually at a selector the service names (Microsoft 365 uses selector1 and selector2, other services use their own). Google requires keys of at least 1024 bits for personal Gmail delivery. (Google Email sender guidelines)

A practical note on checking DKIM: DNS cannot be searched for “all selectors.” Any outside scanner, ours included, tries a list of common selector names. If a scan reports no DKIM but your service says it is verified, check the selector name before assuming it is broken.

Step 5: Publish DMARC with reporting on

DMARC tells receivers what to do when a message fails SPF and DKIM alignment, and where to send reports. A starting record looks like this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourco.com

p=none meets the Google, Yahoo and Microsoft minimum. The rua address receives aggregate reports, which show every service sending as your domain. Yahoo strongly recommends including it. (Yahoo Sender Best Practices) Read those reports for a few weeks, fix any sender that fails, then move to p=quarantine and later p=reject.

We set ours to p=quarantine on day one because we knew every service sending as the domain and verified each one first. If you are not certain of your full sender list, start at p=none.

A standards update most guides have not caught: DMARC was republished as RFC 9989 in May 2026, replacing RFC 7489. It removes the pct tag that many guides still use for gradual rollout and adds a t (test mode) tag. If a guide tells you to roll out with pct=25, it predates the current standard.

Step 6: Add the transport records (MTA-STS and TLS-RPT)

Neither is required by Google, Yahoo or Microsoft. MTA-STS tells other servers to deliver to you only over verified TLS (RFC 8461); TLS-RPT asks them to report TLS failures (RFC 8460). Both protect inbound mail, so treat them as hygiene, not an outbound lever.

Step 7: Verify from a real message, not just a DNS checker

DNS checkers tell you a record exists. They do not tell you a specific sender passes. The test that settles it is free: send a message from each service to a Gmail address, open it, choose More, then “Show original.” (Gmail Help: Trace an email with its full header) The summary at the top shows SPF, DKIM and DMARC as PASS or FAIL.

That is how we confirmed our own setup: SPF, DKIM and DMARC all showed PASS for both the Microsoft 365 mailbox and the transactional sender. Repeat it every time you add a service.

Step 8: Warm up and ramp slowly

There is no official warmup schedule from Google, Yahoo or Microsoft. What exists are vendor rules of thumb, and they do not agree:

  • Instantly suggests roughly 30 to 50 emails per account per day and three to four weeks of manual warmup. (Instantly)
  • Topo’s sample schedule starts at 10 to 20 per day and reaches 60 to 80 by week four. (Topo)
  • LeadMagic suggests two to four weeks, ramping from 5 to 10 up to 40 to 50 per mailbox per day, and pausing if bounces pass 2% or complaints pass 0.1%. (LeadMagic)

The shared principle is more useful than any single number: start low, raise volume in steps, and stop raising it the moment bounces or complaints move. Google’s 0.1% recommended and 0.3% maximum spam rates are the only thresholds here that come from an inbox provider. For how long to plan, and how to tell when warmup is actually done for Google and Microsoft separately, see email warmup: how long to warm up a new sending domain.

Step 9: Clean the list before the first send

Authentication does not offset a bad list. Bounces and complaints are the signals that sink a new domain fastest.

In a contact audit for a fractional executive firm, we reviewed 12,181 records and removed 2,920 of them, about 24%, before any outreach went out. A share like that, sent unchecked to a new domain, is the kind of bounce spike every guide above warns about.

Methodology note: the 12,181 and 2,920 figures come from a pre-launch audit of that client’s contact database. Records were removed as bad data before outreach; this page does not claim an email bounce rate from that program. The same client’s LinkedIn program reached a 21.9% reply rate across 6,615 contacts, with a 54.2% message open rate and 12.3% connection acceptance. Those are LinkedIn figures, measured on the LinkedIn channel only, and are not email deliverability results. See the fractional executive firm’s LinkedIn program.

The setup checklist

  1. Pick the sending domain based on volume and risk.
  2. One SPF record per domain, merged, under 10 lookups including nested includes, ending in -all or ~all.
  3. No sending-service MX records on the root domain; use a subdomain.
  4. DKIM for every service that sends as you.
  5. DMARC published with rua reporting; tighten after reports are clean.
  6. MTA-STS and TLS-RPT as hygiene.
  7. “Show original” test from every sender: SPF, DKIM, DMARC all PASS.
  8. Warm up and ramp in steps; watch bounces and complaints.
  9. Verify and clean the list before the first send.

FAQ

Do I need DMARC for cold email if I send fewer than 5,000 emails a day? Google and Yahoo only require DMARC for bulk senders, but Google’s FAQ says bulk status is permanent once you cross the line, and Microsoft applies its rules per From domain. Publishing p=none with reporting costs nothing and shows you every service sending as your domain.

Can I have two SPF records if I use two sending tools? No. RFC 7208 treats multiple SPF records as a permanent error, which means SPF fails for every message. Merge both tools’ include: entries into one record.

What happens if my SPF record goes over 10 lookups? Receivers return a permanent error and SPF fails. Remove services you no longer use, and check whether a vendor’s include contains several nested includes of its own.

Does a subdomain protect my main domain’s reputation? Partly. It gives you separate DNS records, but Google counts subdomain volume toward the primary domain for its bulk sender threshold, so it is not full separation.

How do I know my setup is working? Send a test from each service to Gmail and use “Show original.” All three of SPF, DKIM and DMARC should show PASS. Then watch Google Postmaster Tools for spam rate. (Set up Postmaster Tools)

Should I still use the pct tag to roll out DMARC? Not under the current standard. RFC 9989 (May 2026) removed pct. Use p=none with reports, then step up to quarantine and reject.

Check your own domain

If you want to know where your domain stands before you send, you can run a free check of your SPF, DKIM and DMARC records. It looks up your MX records, counts SPF lookups against the 10 limit, tries DKIM at common selectors, and reads your DMARC policy and reporting, MTA-STS, TLS-RPT and CAA records, along with your site’s search and AI visibility. If you would rather have someone build and watch the setup, that is our cold email setup and management service.

Sources

Ken Minier

Founder of Our Fractional CMO. Ken builds and runs B2B outbound programs across lead generation, LinkedIn, cold email and cold calling, and sets up the domains and DNS behind them. LinkedIn

Related