Cold outreach starts with a separate sender identity, not a separate inbox

Context: I was preparing B2B cold outreach for a Shopify brand and needed a sender identity separated from the main site domain. Cost: no additional cost when an existing Google Workspace subscription and Cloudflare DNS are already in place. Setup time: about one hour.

Why cold outreach should not use the main domain

Cold outreach means contacting people who do not already know you. Replies are scarce and unsubscribes are more common, so those signals can affect the sending domain’s reputation.

If I used sender@brand.example for a large cold-email campaign and it was marked as spam, the main site’s transactional email, such as order confirmations and support replies, could be affected too.

The practical answer is a separate domain for cold outreach. It keeps that sending risk away from the main brand domain. In my setup, outreach.example was already registered in Cloudflare, so I used it.

Build the sender setup in three steps

Step 1: Add the three DNS records

A sending domain relies on three DNS records. Each has a different job.

SPF (Sender Policy Framework) states which servers may send mail on behalf of a domain. Google Workspace normally guides you through this during domain verification, so it may already exist.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every message. The receiving side can verify that the message came from your domain and was not changed in transit.

In the Google Workspace admin console, go to Apps, Gmail, Authenticate email, then generate a DKIM key. Choose 2048-bit. Google gives you a TXT record like this:

Name:    google._domainkey
Content: v=DKIM1; k=rsa; p=MIIBIjAN... (a long public key)

Add it to Cloudflare DNS. The proxy setting must be DNS only, shown as the gray cloud. Do not enable the orange-cloud proxy.

DMARC tells the receiving side what to do when both SPF and DKIM fail. It can also send you reports about those failures.

For a new sending domain, start in monitoring mode rather than rejecting messages:

Name:    _dmarc
Content: v=DMARC1; p=none; rua=mailto:sender@example

Once all three are configured, the Cloudflare DMARC Management page should show SPF, DKIM, and DMARC as passing.

Step 2: Send from the new domain without a new account

The obvious route is to create a new Google Workspace account such as sender@outreach.example. That adds another subscription.

I used a cheaper route: add the new-domain address as an alias on an existing account.

In the Google Workspace admin console, open Users, select your account, open User information, then Aliases. Add sender@outreach.example.

After the alias is active, mail sent to sender@outreach.example arrives in the main account’s inbox. The incoming mail path stays shared.

Then open Gmail settings, Accounts and Import, and add sender@outreach.example under Send mail as. After verification, the From field in a new message lets you choose the sender identity.

Recipients see Sender <sender@outreach.example>. They do not see which main account receives the replies.

Step 3: Warm the domain up gradually

A new domain should not begin with a large batch. Email providers can treat a new domain that suddenly sends at volume as a spam source.

Use this warm-up schedule as a reference:

What the setup is actually separating

The reusable idea here is to use system design before adding another platform account.

When people need a separate sending domain, the first instinct is often to buy a new account or add another tool. The requirement becomes clearer when I split it in two:

• I need a separate sender identity that recipients see.
• I do not need a separate receiving account because the replies can arrive in the existing inbox.

Google Workspace aliases cover that requirement without an additional account subscription.

The same reasoning applies before any subscription or purchasing decision. Ask which function is actually required. An existing tool may already cover it.

Reusable checklist

Set up the foundation for a new B2B cold-email domain:

• Generate a 2048-bit DKIM key in Google Workspace.
• Add the DKIM TXT record in Cloudflare DNS with Proxy set to DNS only.
• Confirm that an SPF record exists: v=spf1 include:_spf.google.com ~all.
• Add a DMARC TXT record starting with p=none.
• Add the new-domain address as an alias for the main Google Workspace account.
• Add the sender identity in Gmail settings and complete verification.
• Send a test message and confirm that the displayed sender is correct.
• Follow the warm-up schedule, with no more than five messages per day in week one.

Cold-email content rules:

• Clean the list and remove generic addresses such as info@, contact@, and noreply@.
• Verify addresses with a tool such as Hunter.io.
• Put the recipient’s name or company name in the subject line.
• Keep the body to three or four sentences and end with one question that invites a reply.
• Do not include links or attachments during the first two weeks.

What happens next

Domain reputation needs two to four weeks of warm-up before it becomes stable. During that period, the priority is not sending more messages. It is finding the people who are actually worth contacting and using the limited sending capacity on the highest-reply targets.

Scraped lists commonly open at 5-15%, and reply rates of 1-3% are within a normal range. The useful question is whether you follow up properly with the people in that 1-3%.