How to Build Cold Email Infrastructure in 2026

Cold email infrastructure is everything that carries an outreach email from a lead list to a reply: sending domains kept apart from your company's own, mailboxes on Google Workspace or Microsoft 365, the SPF, DKIM and DMARC records that authenticate them, warmup for new mailboxes, a sending engine that caps, paces and threads every message, and listeners that catch replies, bounces and unsubscribes. To build it, register a few domains, put a few mailboxes on each, publish SPF, a 2048-bit DKIM key and a DMARC record at p=none, warm every new mailbox, and keep each one far below its provider's daily limit while meeting the rules Gmail, Yahoo and Microsoft publish for bulk senders.

Each of those rule sets has a narrow scope. Gmail's sender guidelines apply to personal Gmail accounts, and Google states that they don't apply to messages sent to Google Workspace accounts, so a prospect on a company domain hosted by Google is outside them. Yahoo's cover Yahoo and AOL addresses, and Microsoft's high-volume rules cover consumer Outlook.com, Hotmail and Live addresses. One list can hold every kind of address, so the stack below meets the strictest bar of the three. We read every figure on Google, Microsoft, Yahoo, RFC Editor, Porkbun and Swarmhit pages on 21 October 2026, and the arithmetic is ours.

What does cold email infrastructure include?

Seven layers, and each one can be built or bought:

The first decision cuts across every layer. Cold email belongs in its own Google Workspace account or Microsoft 365 tenant, never in the one that carries your company's mail. Google's abuse policy reserves the right to suspend an entire account over domain-wide problems, and when a Microsoft 365 tenant passes its daily external limit, every user in it is blocked from sending outside the company. Seats cost the same in a second account, and a bad week of outreach then stays away from invoices and support mail.

How many domains and mailboxes do you need?

Divide the daily volume by what one mailbox sends, then divide the mailboxes by how many you put on each domain. With 30 emails per mailbox each weekday, Swarmhit's default daily cap per mailbox, three mailboxes per domain and 21.7 weekdays in a month:

Sending a thousand emails each weekday takes 34 mailboxes on 12 domains. The per-mailbox limits never come close. Thirty a day is 1.5 percent of a Google Workspace mailbox's daily message limit and 0.3 percent of a Microsoft 365 mailbox's daily recipient limit, both in the table below, so the number per mailbox is a choice about reputation and risk. Our guide to Gmail sending limits works through what a single spam complaint does to Google's spam rate at 150 emails a day.

Spreading mailboxes over several domains also matters for Gmail's rate limiting. Google says the quotas it applies to DKIM and SPF are specific to each domain, while the quota for an IP address is shared by every sender using that address, so ten domains get ten separate domain quotas at Gmail but still share the quota of any IP address they send from.

Which mailbox provider should you send from?

Both cost the same per seat, so the choice comes down to how each one fails when pushed:

Of the Outlook sending limits, the tenant limit is the one that decides a Microsoft build. For a tenant of 30 licences, the formula Microsoft published gives about 14,907 external recipients a day, about 497 per mailbox, which leaves ample room at 30 a day. In its first 30 days the same tenant gets about 1,491, about 50 per mailbox, and from day 31 to day 60 about 3,727, so in the first month a single mailbox that sends 1,500 emails blocks external sending for all 30.

The quota grows more slowly than the licence count, so each mailbox's share shrinks as a tenant grows. At 30 a mailbox, a new tenant runs short in its first 30 days once it has more than 61 licences, and the 154 mailboxes of the 100,000 row would get about 2,649 external recipients a day in their first month, about 17 each. Business Basic and Business Starter both stop at 300 users, so on those plans the 1,537 mailboxes of the last row need at least six tenants or Workspace accounts. On Microsoft 365, outreach also needs a custom domain, because mail from a tenant's onmicrosoft.com address is limited to 100 external recipients per organization a day.

How do you set up DNS on a sending domain?

Each sending domain needs SPF, DKIM and DMARC records beside the MX records its mailbox provider gives you. Google Workspace publishes DKIM as one TXT record, while Microsoft 365 asks for two CNAME records, selector1._domainkey and selector2._domainkey, that point to keys Microsoft holds. On Google Workspace, with Google's default DKIM selector and a 2048-bit key:

example.com.                    TXT  "v=spf1 include:_spf.google.com ~all"
google._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
_dmarc.example.com.             TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

On Microsoft 365, the SPF record Microsoft documents is v=spf1 include:spf.protection.outlook.com -all. Gmail, Yahoo and Outlook.com all accept DMARC at p=none from bulk senders, provided the From domain aligns with the SPF domain or the DKIM domain, and one of the two is enough, according to Google's email sender guidelines and its Yahoo and Microsoft equivalents. Leave out rua and receivers must not send you aggregate reports, the record of which sources pass and which fail. Gmail also requires every sender to have forward and reverse DNS for the sending IP and to use TLS. Both depend on the sending servers, which are Google's or Microsoft's when you send through their mailboxes, while the spam rate and RFC 5322 formatting stay your job. Teams that send from their own servers also take on the PTR record and TLS. Gmail requires the hostname in the sending IP's PTR record to resolve back to that same IP, and Yahoo closes an SMTP connection without an error once it has accepted a number of messages it does not publish.

SPF has a hard lookup limit. RFC 7208 allows 10 DNS-querying terms in one SPF evaluation (include, a, mx, ptr, exists and redirect, counted through nested includes), and a record that needs more returns permerror, as does a domain that publishes two SPF records. A permerror is not a pass, so DMARC then rests on DKIM alone. Every service that adds its own include spends part of those 10.

Google and Yahoo accept DKIM keys from 1,024 bits and recommend 2,048, as does RFC 8301, which also forbids rsa-sha1 signatures. In the Google Admin console, Google says to pick the 2048-bit option if your DNS host supports it. On Microsoft 365, ask for 2048 bits when you create the DKIM keys, since the PowerShell default is 1024.

DMARC also changed standard in May 2026. RFC 9989 replaced RFC 7489, which had only ever been informational, and moved reporting to RFC 9990 and RFC 9991. The new version drops the pct, rf and ri tags, adds np, psd and t, a test flag that takes over part of what pct did, and makes p recommended instead of required, reading a record without it as p=none. Gmail's error list still has code 4.7.31 for a DMARC record that doesn't specify a policy, so keep p=none written out.

How long should new mailboxes warm up before they send?

No mailbox provider publishes a warmup period, so the numbers come from the tools and from the providers' own ramps. Warmup sends a small daily volume from a new mailbox, rising each day, before the mailbox carries campaigns. Swarmhit's warmup for the mailboxes it sells, for example, starts each one at 10 emails a day on its standard setting and adds 3 a day up to 40, has its network reply to a share of them and pull others out of promotions and spam, and keeps those mailboxes out of campaigns for their first 14 days.

The providers add ramps of their own, the Workspace trial limits and Microsoft's new-tenant quota from the table above. Gmail also enforces its sender rules on an accelerated timetable for new domains, meaning ones that have not sent more than 5,000 emails a day to personal Gmail accounts since 1 January 2024. Microsoft's quota counts warmup and campaign mail together, which makes an aggressive schedule dangerous on a new tenant. Thirty mailboxes warmed up to 60 emails a day send 1,800 external emails, more than the first-month quota of the 30-licence tenant worked out above.

What does the sending engine have to handle?

Building a cold email tool mostly means writing this part. Per mailbox, the engine enforces a daily cap and a sending window, spaces sends at random, rotates leads across the pool, threads follow-ups, and stops a lead on a reply, a bounce, a complaint or an unsubscribe. Pin each lead to the mailbox that sent its first email, so every follow-up and the reply stay in one thread and one inbox. Keep each mailbox's cap well below Google's limit too, since that limit is shared by every client a user has, whether API, web or SMTP, so mail sent outside your engine counts against it as well.

A follow-up sent as a reply carries the first email's Message-ID in the two headers RFC 5322 defines for replies, In-Reply-To and References, and keeps the subject with Re:

From: Sam Lee <sam@example.com>
To: maya@example.org
Subject: Re: Quick question about your Q4 hiring
Message-ID: <c41e9b7a2f@mail.example.com>
In-Reply-To: <a83f0c19e2@mail.example.com>
References: <a83f0c19e2@mail.example.com>

Through the Gmail API those headers are not enough. Google says the message must also carry the threadId of the existing thread, and the Subject must match.

An engine that tracks opens and clicks needs rules for them too. Swarmhit's, for example, starts click tracking off, since its deliverability guide says some spam filters hold tracked links against the sender, and it ignores any open or click recorded in the first two minutes after a send.

A tool that customers connect their Gmail mailboxes to also has a project quota to budget. Google Cloud projects created since 1 May 2026 get 6,000 quota units per user per minute and a daily threshold of 80,000,000 units per project, which Google says cannot be raised on request and plans to bill beyond later in 2026. A send costs 100 units, and reading one message costs 20, or 60 in the full, raw or html format. A platform with 10,000 connected mailboxes that each send 30 emails and read 50 full messages a day uses 60,000,000 units, 75 percent of the threshold. Reading the metadata format to classify a reply, and the full message only when you need its body, cuts that reading cost by up to two thirds. Projects that used the API between November 2025 and April 2026 keep their old quotas for now.

How do you detect replies?

By keeping a listener on every mailbox, using one of three mechanisms, each with its own renewal clock:

A Gmail watch is one call per mailbox, made from the same Google Cloud project that owns the Pub/Sub topic, after the topic has granted publish rights to gmail-api-push@system.gserviceaccount.com. The request from Google's push notification guide:

POST https://www.googleapis.com/gmail/v1/users/me/watch
Content-Type: application/json

{
  "topicName": "projects/myproject/topics/mytopic",
  "labelIds": ["INBOX"],
  "labelFilterBehavior": "INCLUDE"
}

The notification that comes back carries only the address and a new historyId, so the app calls history.list to learn what changed, then fetches the message. Both watch and history.list need a restricted scope (gmail.readonly, gmail.modify, gmail.metadata or the full mail.google.com scope), while sending alone works with gmail.send, which is only sensitive. Restricted scopes put a public app through Google's restricted-scope verification, and an app that stores or transmits that data through its servers must also pass a security assessment by a Google-approved assessor every year, under the CASA framework. Mailbox APIs, one of the three kinds of email API, run these listeners for you, as EmailEngine does, though the verification stays with whoever owns the OAuth app.

On Microsoft 365, a Graph subscription is renewed by extending its expiry:

PATCH https://graph.microsoft.com/v1.0/subscriptions/{id}
Content-type: application/json

{
   "expirationDateTime":"2016-11-22T18:23:45.9356913Z"
}

Schedule renewals well inside the lifetime and read the response. A 404 means the subscription no longer exists, and Microsoft says to create a new one instead of retrying the update.

How should you handle bounces and unsubscribes?

Classify every bounce on two fields of its delivery status notification, Action and Status, read together. RFC 3464's own example is a final failure with a temporary code, Action failed with Status 4.0.0, sent after five days of retries, and RFC 3463 says the code for a full mailbox, X.2.2, should be used as a persistent transient failure, so a 5.2.2 from the recipient's server is no reason to drop the address. The delivery-status part of a bounce looks like this:

Reporting-MTA: dns; mx.example.org

Final-Recipient: rfc822;maya@example.org
Action: failed
Status: 5.1.1
Diagnostic-Code: smtp; 550 5.1.1 mailbox unavailable
Last-Attempt-Date: Tue, 20 Oct 2026 09:14:41 +0000

Gmail and Yahoo both ask bulk senders for a visible unsubscribe link in the body and a one-click header that the recipient's mail app turns into its own button. Gmail wants that header on marketing mail with one HTTPS address and doesn't count a mailto link, while Yahoo accepts mailto but recommends the POST method that RFC 8058 defines, with two headers:

List-Unsubscribe: <https://example.com/unsubscribe/opaquepart>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

When the recipient clicks the button, the mailbox provider sends this request, and the endpoint must act on it alone:

POST /unsubscribe/opaquepart HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 26

List-Unsubscribe=One-Click

RFC 8058 says that request must not carry cookies, HTTP authorization or any other context, so the endpoint cannot depend on them. It also forbids answering with an HTTPS redirect, asks for a hard-to-forge identifier in the URL, and says receivers should send the body as multipart/form-data and may send it urlencoded, as in its own example, so the endpoint has to accept both.

How do you monitor deliverability once campaigns are running?

Read the reports Gmail, Yahoo and Microsoft publish for senders, and run deliverability checks of your own on every mailbox. Gmail's Postmaster Tools reports a spam rate only for DKIM-authenticated mail, so messages that fail DKIM are missing from the rate instead of raising it, and Google recalculates the rate every day. Google also warns that data may be missing on low-volume days, without giving a threshold, and three mailboxes at 30 emails a day send only 90 a day from each domain. Postmaster Tools' compliance view checks every sender's SPF and DKIM, DNS records, formatting, encryption and spam rate, and a domain that crosses Gmail's bulk-sender threshold also gets checks for DMARC and one-click unsubscribe, among others. Google says a change can take up to 7 days to appear there. If a bulk sender's spam rate goes above 0.3 percent, it loses Google's delivery support and mitigations until the rate has stayed below 0.3 percent for 7 consecutive days.

Yahoo's complaint feedback loop reports per DKIM d= domain you enroll and no longer offers reports by IP. Outlook.com sends DMARC aggregate reports to the address in your rua tag and has no plans to send failure reports.

What breaks in production?

Each row is a failure of cold email infrastructure that the providers' documentation or the RFCs predict, with its cause and fix:

Is it cheaper to build cold email infrastructure or buy it?

Seats bought from Google or Microsoft and domains bought from a registrar cost the same whichever engine sends through them, and they grow in step with volume. At Workspace's annual price and $11.08 a year for a .com at Porkbun, the same at renewal, for the mailbox counts above:

Building the engine adds upkeep that never stops: watch and subscription renewals for every mailbox, token care and bounce parsing. Build the engine when sending on behalf of your users is the product and you need to control every header and retry. Buy it when cold email is one channel in a product that does something else, since the upkeep adds nothing your users will notice. Teams that also run LinkedIn steps face the same choice a second time, as building a LinkedIn outreach tool shows. Buying means picking among cold email software with an API, such as the Instantly API or the Smartlead API, or an API built to sit under your own product.

Swarmhit's cold email API is that second kind. A campaign spreads sends across a pool of mailboxes, keeps each lead on the mailbox that sent its first email, threads follow-ups as replies, spaces sends 3 to 7 minutes apart at random inside the schedule, and caps each mailbox at 30 emails a UTC day by default, up to 150. A bounce fails the lead if it is still on the step that sent the email, a spam complaint opts the lead out, and an unsubscribe opts the address out across the workspace. You connect your own Google, Microsoft or IMAP mailboxes, or buy domains in orders of 1 to 20, each with 1 to 5 Google Workspace or Microsoft 365 mailboxes, which Swarmhit registers, sets up in DNS and connects, usually within a few hours, and bills apart from the plan. It reads each mailbox's SPF, DKIM and DMARC records when the mailbox connects and once a day after that, and its deliverability test, which a mailbox can run 10 times a day, sends one email to a test inbox and reports inbox or spam placement, the authentication results and any Spamhaus listing. Pricing counts sends and ignores how many mailboxes you connect, from $59 a month for 50,000 emails to $319 for a million. Bounces reach your app as signed webhooks that carry the mail server's Action and Status when it gave them:

{
  "source": "campaign",
  "accountId": "mBx4Qw8RmZk2Yp5Ns",
  "campaignLeadId": "cLj2Xw8RmQz5Yp3Ns",
  "campaignId": "gT5Rw2XqLm8Zk3vNd",
  "leadId": "eLd7Qw2XmRk9Zp4Yt",
  "kind": "bounce",
  "email": { "messageId": "<b7f1e2c4d9a0@example.com>", "recipient": "maya@lindqvist.io" },
  "bounce": { "action": "failed", "status": "5.1.1", "message": "The email address does not exist." },
  "deadAddress": true,
  "leadFailed": true,
  "at": "2026-09-22T09:14:41.000Z"
}

FAQ

How long does Google take to verify an app that reads Gmail?

About six weeks for an app that reads its users' Gmail, Google's own estimate for restricted-scope verification, which it does not guarantee, and another Google help page warns that verification might take several months. An app that only sends with gmail.send faces Google's sensitive-scope review, listed at 10 business days, and brand verification is listed at two to three. Until then the app may show an unverified-app screen and can take only 100 new users over the project's whole lifetime, a cap Google says cannot be reset.

Can you run cold email over SMTP and IMAP alone?

On most mail servers, yes, but Gmail steers apps away from it. Through OAuth, Google says IMAP and SMTP need the restricted https://mail.google.com/ scope, which an IMAP app should request only to delete messages permanently, so it expects a tool that reads replies to use the Gmail API and one that only sends to use gmail.send. App passwords skip OAuth but need 2-Step Verification, and Google says they aren't recommended. One Gmail account can be added to at most 15 email clients at a time.

Should cold email go out from a subdomain?

A subdomain does not give cold email its own count at Gmail. Google counts every message from the same primary domain, subdomains included, toward its 5,000-a-day bulk-sender threshold, and its own example adds 2,500 messages from a domain to 2,500 from its promotions subdomain to make a bulk sender, a status Google says is permanent once reached. Under DMARC's relaxed alignment, a subdomain and its parent also count as the same organization. Only a separately registered domain gets a count of its own.

What DMARC policy should a cold email domain use?

A cold email domain should publish p=none and tighten it slowly, if at all. RFC 9989, the May 2026 DMARC standard, says domains used for general-purpose email should not deploy p=reject, and that a domain on p=reject must apply valid DKIM signatures and must not rely on SPF alone to pass DMARC. For domains whose users might post to mailing lists, it advises reading aggregate reports at p=none for at least a month, then at p=quarantine for as long, before any move to p=reject.

How fast do you have to process an unsubscribe?

Honor unsubscribes within 48 hours for Gmail and 2 days for Yahoo. Google lists unsubscribes not honored within 48 hours among the problems that leave a bulk sender without delivery support or mitigations, and its Postmaster Tools compliance view flags a domain that misses the window. Yahoo says an unsubscribe not honored in 2 days does not meet its requirement. Microsoft lists functional unsubscribe links for Outlook.com among its recommendations and sets no deadline.

Is a monthly or an annual mailbox plan cheaper for cold email?

Annual is cheaper for any mailbox that lives more than 10 months. Google Workspace Business Starter costs $84 a year per user on the annual plan, owed in full even if you cancel early, against $8.40 a month on the Flexible Plan, which you can cancel at any time, so the two cross at 10 months. Microsoft raised Business Basic from $6.00 to $7.00 on 1 July 2026, and its version without Teams costs $5.40 a month on a yearly subscription or $6.48 month to month.