Gmail, Yahoo, and Microsoft receiver requirements for cold email

The sending platform says the domain is connected. The DNS screen is green. Then the first test message reaches Gmail, Yahoo, or Outlook and the team still cannot explain which sender requirements were actually met.

The problem is that receiver requirements are not one DNS lookup. They combine domain authentication, message headers, unsubscribe handling, SMTP identity, message format, volume, and recipient feedback.

Use the receiver requirements checker for the public DNS layer. Paste headers from a real test message when you have them. Keep the rest as an explicit review item in the launch report.

Start with the shared authentication baseline

Every launch should begin with the records that identify the sender.

Check	What to confirm	Evidence
SPF	Exactly one SPF record exists and the active sender is included	DNS TXT lookup and recursive lookup count
DKIM	The selector used by the sender resolves to a public key	DKIM selector lookup and pasted DKIM results
DMARC	A valid _dmarc record exists with an intentional policy	DNS TXT lookup and pasted DMARC result
Alignment	The visible From domain aligns with SPF or DKIM	Authentication-Results header or sender evidence
MX	Replies and bounces route to the intended mailbox provider	MX lookup and provider detection

Run the SPF checker, DKIM checker, DMARC checker, or the combined SPF DKIM DMARC checker when you need a focused first pass.

Gmail requirements

Gmail’s sender guidelines distinguish between all senders and senders delivering 5,000 or more messages per day to personal Gmail accounts.

For the shared launch baseline, confirm:

• SPF or DKIM is configured for the sending domain.
• The sending domain or IP has valid forward and reverse DNS when the sender path owns the IP.
• The SMTP path uses TLS.
• Messages follow the Internet Message Format.
• The visible From address does not impersonate a Gmail address.

For high-volume Gmail traffic, confirm both SPF and DKIM, publish DMARC with at least p=none, and verify that the From domain aligns with SPF or DKIM. Marketing and promotional messages also need one-click unsubscribe and a visible unsubscribe path in the message body.

The browser checker can inspect the public records and pasted authentication headers. It cannot measure the Gmail spam rate, verify the message body, or predict whether Gmail will place a message in the inbox.

Yahoo requirements

Yahoo’s sender best practices also emphasize authentication and one-click unsubscribe for relevant mail.

Before launch, confirm:

• SPF and DKIM are configured for the active sender.
• DMARC is published and its policy matches the operating plan.
• The visible From domain aligns with an authenticated identity.
• Promotional messages include a functioning one-click unsubscribe path.
• The team can honor unsubscribe requests promptly.

Treat Yahoo readiness as evidence to collect, not a delivery promise. Complaint rates, sending history, list quality, and message content remain outside a DNS and header check.

Microsoft requirements for high-volume Outlook.com traffic

Microsoft’s high-volume sender guidance applies to senders delivering 5,000 or more messages to Microsoft consumer services with the same domain in the 5322.From address.

The documented authentication baseline is:

• SPF passes for the sending domain.
• DKIM passes for the sending domain.
• DMARC is published, with p=none accepted as an example policy.
• SPF or DKIM aligns with the domain in the 5322.From address.

The receiver requirements checker shows this as a high-volume row. It does not classify a smaller campaign as exempt from good authentication practice. It only avoids presenting a high-volume threshold as a universal rule.

Check one-click unsubscribe from real headers

One-click unsubscribe is a message-header requirement. It cannot be inferred from the domain’s DNS.

RFC 8058 defines the core evidence:

1. List-Unsubscribe contains an HTTPS URI.
2. List-Unsubscribe-Post contains List-Unsubscribe=One-Click.
3. The headers are covered by a valid DKIM signature.
4. The unsubscribe endpoint handles the POST without depending on a redirect.

The checker validates the first three signals when they appear in pasted headers. It does not send the POST, inspect the endpoint’s application behavior, or prove that the message body contains a visible unsubscribe link.

Select Marketing or promotional message when checking a cold email campaign. Select Transactional message when unsubscribe headers are not part of the message type being reviewed. The authentication rows still apply in both modes.

Review the SMTP path separately

DNS and message headers cannot prove every SMTP requirement. Keep these rows in the launch report:

Review item	Why it matters	Browser evidence
PTR and forward-confirmed rDNS	The sending IP should have a reverse hostname that resolves back to the same IP	Use the PTR and rDNS checker for custom SMTP or dedicated IPs
TLS	The sender should transmit over TLS	Provider or SMTP-path evidence, not a domain TXT lookup
Message format	Headers and body should follow the expected message format	Inspect a real test message
Complaint rate	Receiver treatment changes with recipient reports	Provider reporting or receiver tools
Visible unsubscribe	Recipients need a clear body-level opt-out path	Inspect the rendered message

For the tracking layer, run the tracking domain checker before links go live. A sender can pass authentication while its tracking CNAME or HTTPS path still fails.

What the free checker can and cannot decide

The free checker is useful for one domain and one test message. It can show:

• Whether the public SPF, DKIM, DMARC, and MX records are present.
• Whether pasted authentication results report pass or fail.
• Whether the visible From domain has DMARC pass evidence.
• Whether the pasted message contains the three core one-click unsubscribe signals.
• Which provider-specific rows still need evidence.

It cannot show:

• Inbox placement.
• Private receiver reputation.
• Complaint rate or spam rate.
• Sending volume history.
• Message body quality or visible unsubscribe rendering.
• Live SMTP banner, TLS negotiation, or receiver acceptance.

That boundary is the point. A free check gives an operator a concrete next action without pretending that public DNS can predict the receiver’s final decision.

Turn evidence into client signoff

For an agency launch, record the following in the client report:

1. Sending domain and message type.
2. SPF, DKIM, DMARC, and MX evidence.
3. Header capture date and sender path.
4. Alignment result.
5. One-click unsubscribe result for promotional mail.
6. PTR, TLS, format, complaint, and body-level review owners.
7. The exact blocker or warning to fix before volume starts.

Use the client-ready deliverability report template for the handoff structure, then review the cold email pre-launch checklist before the client approves launch.

The sample launch QA report shows how these checks become a Ready, Needs Fix, or Do Not Launch decision across a complete workspace. One domain can look clean while another inbox, tracking host, or SMTP path still blocks the campaign.