Authentication answers one question for the receiver: is this domain really the sender? It does not answer whether the mail is wanted. Since February 2024, Gmail and Yahoo have required SPF or DKIM from every sender, and SPF and DKIM plus an aligned DMARC record from bulk senders (Google, Yahoo). Microsoft added the same trio for Outlook.com high-volume senders from May 5, 2025.
For a cold-email platform the conclusion is blunt. Every sending domain should pass SPF, DKIM and DMARC with alignment, whatever its volume, because the cost is zero and the downside of failing is temporary or permanent rejection at Gmail. This is automated by every infra vendor (Mailforge, Zapmail, Scaledmail) and is not a place to differentiate. It is a place to make no mistakes.
The stack in one table
| Standard | What it proves | Required by | Cold-email reality |
|---|---|---|---|
| SPF | The sending IP is authorised for the envelope (Return-Path) domain | Gmail/Yahoo: all senders need SPF or DKIM; bulk needs both | Automatic on Google/Microsoft mailboxes; watch the 10-DNS-lookup limit when stacking tools |
| DKIM | The message was signed by a domain's key and not altered | Gmail/Yahoo bulk; Outlook.com >5k/day | The d= domain is where domain reputation accrues |
| DMARC | SPF or DKIM passed and aligned with the visible From: domain; publishes a policy | Gmail/Yahoo bulk (p=none allowed); Outlook.com >5k/day | p=none is enough for compliance; alignment is the part people get wrong |
| BIMI | Logo display for DMARC-enforced domains | Nobody | Irrelevant for cold domains (see below) |
| ARC | Preserves authentication results through forwarders and lists | Nobody | Marginal; matters when prospects auto-forward |
| List-Unsubscribe + RFC 8058 | One-click unsubscribe via HTTPS POST | Gmail/Yahoo bulk, for marketing/subscribed mail | Ambiguous for cold email; cheap to support |
Alignment is the real requirement
Google's wording: "the domain in the sender's From: header must be aligned with either the SPF domain or the DKIM domain". For DMARC to pass, "the authenticating domain must be the same domain that appears in the message From: header". Google also recommends that SPF and DKIM be "aligned with each other at the organizational level".
Where it breaks in cold email:
- Custom SMTP or relay setups that sign DKIM with the relay's domain rather than the customer's sending domain.
- Bounce/Return-Path domains owned by a sending service, so SPF passes but does not align. That is fine only if DKIM aligns.
- Mixed tool stacks (sequencer + warmup + verification + CRM sending from the same domain) that blow past SPF's DNS-lookup limit, so SPF silently fails.
A platform that validates alignment on every connected mailbox, by sending a test and reading the Authentication-Results header back, catches all three. That is a weekend of engineering.
DMARC policy: p=none is enough, and that is deliberate
Both Google and Yahoo accept p=none for bulk senders. For a cold domain, p=none plus aggregate reports (rua) is the practical choice. Moving to quarantine/reject protects a brand from spoofing, which is a real concern for a company's primary domain but not for a disposable sending domain. Gmail has said it will apply a DMARC quarantine policy to gmail.com itself, so anyone "sending as" @gmail.com through a third-party tool gets junked. Sequencers must refuse that configuration.
BIMI: skip it for cold domains
Gmail shows BIMI logos only when the domain has DMARC at p=quarantine or p=reject with pct=100, plus a Verified Mark Certificate or Common Mark Certificate. A VMC requires a registered trademark, and Google notes "the trademark process can take 6 to 12 months". The checkmark appears only with a VMC. None of that fits dozens of secondary domains, and a logo on the domain getacme-mail.com would advertise that it is a sending domain. BIMI belongs on a company's primary marketing domain, which should not be sending cold email anyway.
ARC: low priority
ARC (RFC 8617, an experimental standard) lets intermediaries such as mailing lists and forwarders vouch for the authentication results they saw before modifying a message. It matters to cold senders only when a prospect auto-forwards mail to another provider. Google's forwarding guidance stresses that DKIM is "especially important" for forwarded messages, because SPF breaks on forwarding. The actionable point is "always sign DKIM", which is already table stakes.
One-click unsubscribe (RFC 8058): does it apply to cold email?
The mechanism: a List-Unsubscribe header with an HTTPS URI and a List-Unsubscribe-Post: List-Unsubscribe=One-Click header. The RFC requires that the message carry a valid DKIM signature covering both headers. Gmail sends a POST to the URI when the user clicks its native unsubscribe button.
Who must use it: Gmail requires it for bulk senders' "marketing messages and subscribed messages" and says "transactional messages are excluded". Yahoo uses the same language and requires unsubscribes to be honoured within 2 days.
The case that cold email is exempt:
- The requirement attaches to bulk senders. A cold domain sending 60 a day is nowhere near 5,000/day to personal Gmail accounts.
- Google's guidelines don't apply to Workspace recipients at all.
- Cold email is neither "subscribed" nor obviously "marketing" in the newsletter sense.
The case that it applies anyway:
- Google says "Message recipients, not Google, determine the nature of the messages they receive". An unsolicited pitch is promotional to the person receiving it.
- Google warns that unwanted mail without one-click unsubscribe "is more likely to be reported as spam". Complaints are the signal that kills cold domains.
- Since July 2025, Gmail's Manage subscriptions view sends unsubscribe requests "on your behalf" for Workspace and personal users alike. Giving recipients a clean exit that isn't the spam button is worth more to a cold sender than to a newsletter.
Legally and contractually, RFC 8058 is not clearly required for low-volume one-to-one cold email. Practically, a header-based exit that diverts would-be spam reports into suppressions is cheap insurance. The counter-argument practitioners make is that List-Unsubscribe headers mark a message as bulk and so cost placement. No provider statement supports or refutes that. Make it a per-campaign toggle with the default on, and measure.
The claim that adding List-Unsubscribe headers pushes one-to-one-style mail into Promotions or spam circulates among practitioners. No Google or Microsoft documentation found for this pass addresses it. Treat it as unverified either way.
Separately from mailbox-provider rules, opt-out handling is a legal requirement in most regimes: United States: CAN-SPAM and state email laws requires a working opt-out, and in the EU see GDPR and ePrivacy and Germany. RFC 8058 is one way to implement it, not the legal standard itself.
What this means for an entrant
- Automate and verify, don't just configure. Generate SPF/DKIM/DMARC records, then verify alignment from real
Authentication-Resultsheaders on every mailbox, continuously. Most "DNS check" features only look up records. - Guard the SPF lookup budget. Customers stack sequencer, CRM, warmup and helpdesk on one domain. A linter that flattens or warns before SPF hits permerror is a small, visible quality signal.
- Ship RFC 8058 with a correct, fast suppression loop. DKIM-covered headers, an HTTPS POST endpoint, global suppression across all of a workspace's domains, and honoured within 48 hours (Gmail and Yahoo's 2-day bar). Make it toggleable and report its effect on complaints and replies.
- Refuse unsafe configurations. Block sending "as" gmail.com/outlook.com addresses through your SMTP, and warn when the primary brand domain is connected for cold sending.
- Don't sell BIMI to cold senders. It signals deliverability sophistication but does nothing on throwaway domains.