SPF, DKIM, and DMARC for cold email: a provider-aware setup guide

SPF, DKIM, and DMARC are not three generic DNS records you copy onto every cold email domain. SPF must include the systems that actually send mail. DKIM comes from each provider that signs mail. DMARC passes only when SPF or DKIM aligns with the domain people see in the From address.

For Google Workspace, that usually means one SPF TXT record, one generated DKIM TXT record, and one DMARC TXT record. Microsoft 365 uses a different SPF include and two generated DKIM CNAME records. Do not mix the two setups.

This guide shows the correct order: inspect, publish, activate, test, and hand off.

The setup checklist

Run these steps for every sending domain:

1. List every system allowed to send from the domain.
2. Check the DNS records that already exist.
3. Build one SPF record from the active sender list.
4. Generate DKIM inside Google, Microsoft, or the actual signing service.
5. Publish the generated DKIM values and turn signing on.
6. Send a test message to an external mailbox and inspect its headers.
7. Publish DMARC in monitoring mode with aggregate reporting.
8. Fix legitimate senders that fail authentication or alignment.
9. Save the DNS results, message-header results, owner, and review date.

A provider dashboard saying “configured” is not enough. The final proof is an externally received message that shows the expected authentication and alignment results.

What SPF, DKIM, and DMARC do

DMARC needs one aligned path:

• SPF passes and its envelope domain aligns with the visible From domain; or
• DKIM passes and its d= domain aligns with the visible From domain.

You should configure both SPF and DKIM when the provider supports them. But one aligned pass is enough for DMARC.

Google Workspace vs Microsoft 365

The protocols are the same. The records and activation steps are not.

Those SPF examples only work when that provider is the domain's only sender. If a website form, support desk, billing tool, or another platform also sends from the domain, build the record from the complete sender list.

Step 1: inspect DNS before changing it

Check the root domain, the provider's DKIM selector, and _dmarc before adding records:

dig TXT example.com +short
dig TXT SELECTOR._domainkey.example.com +short
dig CNAME SELECTOR._domainkey.example.com +short
dig TXT _dmarc.example.com +short

Replace example.com and SELECTOR with the real domain and the selector generated by the provider.

You are looking for:

• an existing SPF record that must be updated instead of duplicated;
• an old DKIM selector that may still be in use;
• a DMARC record already applied to the domain;
• a hostname or record type that does not match the provider instructions.

Confirm the authoritative DNS answer before changing anything. A missing result from one resolver can also mean you queried the wrong hostname or record type.

Step 2: publish one SPF record

RFC 7208 allows one SPF policy at each owner name. If two TXT records both start with v=spf1, SPF can return a permanent error.

Use this process:

1. Read the current SPF record.
2. Compare it with the active sender list.
3. Remove services that no longer send mail.
4. Add only the mechanisms documented by current senders.
5. Publish one combined record.
6. Test every sending path again.

SPF also limits evaluation to ten lookup-causing terms. An include: can trigger more lookups inside the referenced policy, so counting visible includes is not enough.

Google Workspace SPF

When Google Workspace is the only sender, Google's SPF setup guide documents:

v=spf1 include:_spf.google.com ~all

Add other services to this record only from their current documentation. Do not publish another SPF record beside it.

Microsoft 365 SPF

When commercial Microsoft 365 is the only sender, Microsoft's SPF guide documents:

v=spf1 include:spf.protection.outlook.com -all

Government and regional Microsoft clouds can use different values. Use the documentation for the tenant you are configuring.

Step 3: generate DKIM in the sending provider

Never copy a DKIM value from another domain or a tutorial. The DNS record contains or points to a public key that must match the private signing key held by the provider.

Google Workspace DKIM

Google's DKIM guide uses this workflow:

1. Select the domain in Google Admin.
2. Generate the DKIM record.
3. Publish the exact TXT hostname and value Google provides.
4. Return to Google Admin and start authentication.
5. Send a message to an external recipient and inspect the result.

Save the selector Google generated. The common google selector is not a value you should assume.

Microsoft 365 DKIM

Microsoft's DKIM guide provides two CNAME targets for each custom domain. Publish both because Microsoft uses the two selectors for key rotation.

The target format changed for new custom domains in 2025, and older domains can still use the earlier format. Copy the exact targets from Microsoft Defender or the documented Exchange Online PowerShell output. Do not construct them from a blog example.

After both CNAMEs resolve, enable DKIM signing and send an external test message.

Step 4: add DMARC in monitoring mode

DMARC belongs at _dmarc.example.com. Start with aggregate reporting while you confirm every legitimate sender. A basic same-domain example is:

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

Use a mailbox or reporting service that can process aggregate XML reports. If reports go to another domain, follow the external-report authorization requirements in the current standard and your reporting provider's documentation.

p=none means monitor. It does not mean finished. Use the reports to find:

• legitimate senders missing from the inventory;
• SPF passes that do not align with the visible From domain;
• DKIM signatures using an unexpected provider domain;
• retired systems that still send mail;
• unauthorized use of the domain.

Do not jump to p=reject because a setup screen recommends it. Move to quarantine or reject only after the legitimate mail flow is known and tested.

Important 2026 change: RFC 9989 replaced the older DMARC standard and removed the pct tag. Current Google and Microsoft guides still show pct, but it is no longer a reliable cross-receiver rollout control. Use source inventory, aggregate reports, and staged domains instead.

RFC 9990 defines DMARC aggregate reporting. A receiver is not required to send every requested report, so an empty report inbox is not proof that authentication passes.

Step 5: verify an external message

Send one plain message through each authorized sending path to a mailbox outside the sending workspace or Microsoft tenant. Then open the original message or raw headers and find Authentication-Results.

A passing result looks roughly like this:

spf=pass smtp.mailfrom=mail.example.com
dkim=pass header.d=example.com header.s=provider-selector
dmarc=pass header.from=example.com

Record four values:

1. the SPF result and smtp.mailfrom domain;
2. the DKIM result, d= domain, and s= selector;
3. the DMARC result and header.from domain;
4. the sending path used for the test.

Repeat the check for every authorized system. A passing Google Workspace message does not validate a separate application sender.

Fix the failed layer

Do not change all three records when one layer fails. Start with the failed result and the domain named in the header.

Save a handoff record

Campaign operations needs more than “DNS is done.” Save this for every sending domain:

Client and sending domain:
Mailbox provider and workspace/tenant:
DNS host and DNS owner:

Authorized sending paths:
- Provider:
- Envelope / Return-Path domain:
- Expected DKIM d= domain and selector:

SPF:
- Current DNS result:
- External header result:

DKIM:
- Record type and selector(s):
- Current DNS result:
- External header result:

DMARC:
- Current policy and report destination:
- External alignment result:
- Known exceptions:

Verified by and date:
Evidence location:
Launch status: ready / blocked
Next review trigger:

Do not place passwords, private keys, API keys, or customer-sensitive data in this record.

Review the domain after adding or removing a sender, changing providers, rotating DKIM keys, moving DNS, or changing DMARC policy.

Cheap Inboxes provides DNS, DKIM, DMARC, and forwarding management workflows. The developer overview shows the current public product and API surface. Regardless of who manages the DNS, keep the external header result in the handoff.

The launch rule

A sending domain is ready when every authorized path has current DNS evidence, an external message-header result, a named owner, and a review trigger.

The records existing is not the finish line. The right records must authenticate the right mail for the right From domain—and the next operator must be able to prove it.

Sources

Official and primary sources reviewed on 2026-07-21:

• RFC 7208: Sender Policy Framework
• RFC 6376: DomainKeys Identified Mail
• RFC 8301: DKIM cryptographic algorithm and key usage update
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance
• RFC 9990: DMARC aggregate reporting
• Google Workspace: Set up SPF
• Google Workspace: Set up DKIM
• Google Workspace: Set up DMARC
• Microsoft 365: Set up SPF
• Microsoft 365: Set up DKIM
• Microsoft 365: Set up DMARC
• Cheap Inboxes developer overview
• Cheap Inboxes public API documentation