How to Set Up SPF, DKIM and DMARC for Cold Email Domains

If your cold emails are landing in spam, the first thing to check is not your copy. It is whether your domain proves it is allowed to send. Google and Microsoft both require authentication on bulk senders, and without it your messages are filtered before anyone reads them.

This guide walks through the three records that matter — SPF, DKIM and DMARC — with the exact values for Google Workspace and Microsoft 365, and the mistakes we see most often when auditing customer domains.

Why authentication matters for cold email

Mailbox providers score every incoming message on reputation. Authentication is the foundation of that score: it lets Gmail or Outlook verify that a message claiming to come from [email protected] was actually sent by a server your domain authorises.

Since 2024, Google and Yahoo have required SPF and DKIM for senders over 5,000 messages a day, plus a DMARC policy. Cold email accounts rarely hit that volume individually, but the same signals feed spam filtering at any volume. An unauthenticated domain starts every campaign with a handicap.

SPF: which servers may send for your domain

SPF (Sender Policy Framework) is a TXT record listing the mail servers allowed to send on behalf of your domain.

Google Workspace

Type: TXT   Host: @
Value: v=spf1 include:_spf.google.com ~all

Microsoft 365

Type: TXT   Host: @
Value: v=spf1 include:spf.protection.outlook.com ~all

Rules to follow:

• One SPF record per domain. Two v=spf1 records is a hard failure, not a merge. If you already have one, add the new include: inside it.
• Stay under 10 DNS lookups. Each include: counts. Cold email domains normally only need the one provider, so this is rarely a problem unless the domain also runs a website contact form or CRM through another service.
• Use ~all (softfail), not -all, while you are still adding services. Switch to -all once everything is verified.

DKIM: a signature that proves the message wasn’t altered

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each message. The public key lives in DNS; the private key stays with your mail provider.

Google Workspace

1. Admin console → Apps → Google Workspace → Gmail → Authenticate email.
2. Select the domain, click Generate new record. Choose a 2048-bit key.
3. Add the TXT record it shows (host is usually google._domainkey).
4. Wait for DNS to propagate, then click Start authentication.

Microsoft 365

1. Microsoft 365 Defender → Email & collaboration → Policies & rules → Threat policies → DKIM.
2. Select the domain and click Create DKIM keys.
3. Add the two CNAME records it gives you (selector1._domainkey and selector2._domainkey).
4. Return and toggle Sign messages for this domain on.

The most common failure here is copying the record before the provider has finished generating it, or adding it as TXT when the provider asked for CNAME. Always verify with a lookup tool after adding.

DMARC: what to do when SPF or DKIM fails

DMARC (Domain-based Message Authentication, Reporting and Conformance) tells receivers how to treat mail that fails SPF or DKIM alignment, and where to send reports.

Type: TXT   Host: _dmarc
Value: v=DMARC1; p=none; rua=mailto:[email protected]; pct=100

Start with p=none. That is a monitoring policy: nothing is blocked, but you receive aggregate reports showing which sources pass and fail. After a couple of weeks with clean reports, move to p=quarantine and eventually p=reject. Jumping straight to p=reject on a new domain is how legitimate mail gets dropped by a typo.

Alignment is the part people miss. DMARC passes only when the domain in the From: header matches the domain SPF or DKIM validated. With Google Workspace and Microsoft 365 that happens automatically. It breaks when you route mail through a third-party service that signs with its own domain — set up custom DKIM on that service so it signs as yours.

MX records: often forgotten, still required

Inbound mail needs to work too. A domain that can send but cannot receive looks suspicious, and replies (including unsubscribe requests) bounce. Set the provider’s MX records:

• Google Workspace: a single record, smtp.google.com, priority 1.
• Microsoft 365: yourdomain-com.mail.protection.outlook.com, priority 0 (the exact host is shown in the admin centre).

Verify before you send

After propagation (usually under an hour, up to 48), check every record. Send a test message to a Gmail address, open it, choose Show original, and confirm SPF, DKIM and DMARC all show PASS. Do the same from Outlook.

If any of them fails, fix it before warmup starts. Warming a misconfigured domain builds a bad reputation faster than a good one.

Common mistakes we fix every week

1. Two SPF records after a website builder added its own.
2. DKIM added but never activated in the admin console.
3. DMARC at p=reject on day one with no alignment, blocking the domain’s own mail.
4. Missing MX records on secondary sending domains.
5. Records added at the wrong host (_dmarc.yourdomain.com.yourdomain.com is a classic).

Or skip the DNS work

Every PureMail order includes SPF, DKIM, DMARC and MX configuration on each domain, verified before the inboxes are handed over. If you would rather spend the afternoon writing sequences than debugging TXT records, see pricing or book a free call.