Improve Yahoo, AOL, and Cox.net Email Deliverability

Anil Jalela · Published Nov 15, 2022 · 36 min read

Yahoo deliverability work begins after the compliance checklist passes. The difficult part is deciding whether a change belongs to an IP, DKIM identity, From domain, traffic stream, tenant, campaign, template, recipient cohort, or Yahoo delivery path, then making one correction without destroying the evidence.

This is an operator's field guide for Yahoo Mail, AOL, and migrated cox.net recipients. It separates SMTP acceptance from placement, provider evidence from sender inference, and a reputation incident from an ordinary queue or DNS fault. Basic requirements remain as a compact baseline; the main workflow is attribution, containment, controlled recovery, and escalation. Examples use reserved domains and addresses.

Understand the current mailbox scope

Yahoo states that its sender requirements apply to all consumer email brands and domains hosted by Yahoo Mail, including AOL. Cox support states that it transitioned cox.net email service and support to Yahoo Mail. For deliverability operations, treat these destinations as one Yahoo-hosted ecosystem while keeping recipient domains separate in reporting. A domain split lets you see whether a problem affects the whole Yahoo path or one audience segment.

Mailbox-provider controls and thresholds can change. Keep a named owner subscribed to Sender Hub updates and review the requirements page before a high-volume launch. Do not build policy from a copied threshold alone.

Start with an attribution model, not a reputation score

Yahoo does not publish the complete weighting, lifetime, or interaction of its filtering signals. A single public “sender score” therefore cannot explain a Yahoo event. Build a working attribution model from identities and behaviors that can be observed, then test the narrowest explanation against unaffected control cohorts.

None of these comparisons proves Yahoo's internal cause by itself. It establishes whether the observed boundary is consistent with an IP, identity, program, content, or audience explanation. Preserve at least one stable control path during an incident; changing every IP, domain, template, and cohort at once makes recovery faster to announce but harder to prove.

Know what each signal can and cannot establish

A sound incident conclusion names both the evidence and its boundary: “421 TS-series deferrals rose on IP A after the release while IP B, using the same aligned domain and campaign, stayed stable.” “Yahoo hates the domain” is not a diagnosis.

Meet the requirements before optimizing

Yahoo does not publish a fixed bulk-volume number. It evaluates senders using authenticated domains, the From domain, IPs, content, and other available evidence. Operate as a bulk sender when the program sends significant promotional or subscribed volume. Waiting for a secret threshold creates avoidable enforcement risk.

Audit every reputation and deliverability factor

Do not reduce a delivery problem to one score or a list of “spam words.” Yahoo does not publish the complete weighting of its filtering system. Treat the following as an evidence checklist: provider requirements and SMTP diagnostics confirm some items directly, while changes in campaign, audience and infrastructure help identify the cause of a specific incident.

Map every identity and traffic stream

Start with inventory, not DNS editing. A campaign can use a visible From domain, a return-path domain, one or more DKIM signing domains, a tracking domain, a link shortener, an image domain, a sending IP, an EHLO name, and an unsubscribe endpoint. Reputation and troubleshooting become unreliable when no one owns the map.

Separate promotional traffic from password resets, receipts, account alerts, and person-to-person or user-generated mail using distinct IPs or DKIM domains where the architecture permits it. Separation limits blast radius only when authentication, audience, rate controls, logging, and operators are also separated.

Verify SPF without creating hidden failures

dig +short TXT example.com
dig +short TXT mail.example.com
dig +short MX mail.example.com

# Inspect every include recursively and count DNS-triggering mechanisms.
# Replace with an organization-approved SPF inspection tool where available.
dig +short TXT _spf.example-provider.test

Publish one SPF record for each envelope domain. Include only authorized sources, stay within the SPF DNS-lookup limit, remove retired providers, and choose the final qualifier through a controlled rollout. SPF passing on the return path does not satisfy DMARC unless that domain aligns with the visible From domain.

Unsafe: changing directly from a broad record to -all without a complete source inventory can reject legitimate mail. Capture all SaaS platforms, applications, support systems, scanners, forwarders, and failover senders; test; monitor DMARC data; then tighten deliberately.

Sign stable mail with DKIM

dig +short TXT s2026._domainkey.mail.example.com

# Verify a selector with OpenDKIM when it is part of your toolchain.
opendkim-testkey -d mail.example.com -s s2026 -vvv

# Inspect a received message rather than assuming the signer ran.
grep -iE '^(DKIM-Signature|Authentication-Results):' delivered-message.eml

Yahoo requires DKIM for bulk senders and ties CFL enrollment to the DKIM d= domain. Use a domain your organization or accountable ESP controls, rotate selectors without a signing gap, protect private keys, and sign after content transformations that would otherwise invalidate the body hash. Yahoo recommends at least a 1024-bit key; use 2048-bit RSA where DNS and software support it, or another provider-supported algorithm after interoperability testing.

A platform-level DKIM signature can let an ESP manage CFL coverage across customer mail, while a customer signature provides brand alignment. Document which signer enrolls in Sender Hub, who receives complaints, and how the event maps back to the correct tenant and recipient.

Publish DMARC and prove alignment

_dmarc.example.com. 300 IN TXT \
  "v=DMARC1; p=none; rua=mailto:[email protected]; fo=1"

dig +short TXT _dmarc.example.com

# Check the organizational domain and every visible From domain actually used.
grep -i '^From:' delivered-message.eml
grep -i '^Authentication-Results:' delivered-message.eml

Bulk senders need a valid DMARC policy of at least p=none, and DMARC must pass through an aligned SPF or DKIM identity. Relaxed alignment is acceptable under Yahoo's requirements. Aggregate reports help discover unknown sources and intermittent failures, but publishing rua does not fix them. Assign an owner, parse reports, classify every source, and move toward enforcement when legitimate mail is aligned.

Unsafe: moving to p=reject before identifying legitimate senders can block invoices, support mail, application alerts, and delegated platforms. Enforcement is valuable against spoofing, but it requires inventory, staged policy, monitored reports, vendor coordination, and rollback criteria.

Verify forward and reverse DNS

sending_ip="192.0.2.25"
sending_host="mta1.mail.example.com"

dig +short -x "$sending_ip"
dig +short A "$sending_host"
dig +short AAAA "$sending_host"

# Confirm the MTA introduces itself with the intended resolvable name.
openssl s_client -starttls smtp -connect 192.0.2.25:25 -crlf

The PTR should be meaningful and non-generic, and its hostname should resolve forward to the sending IP. Keep EHLO, certificates where used, monitoring, and ownership consistent. A reverse record is controlled by the address provider, so include it in provisioning and decommissioning procedures rather than treating it as an afterthought.

Implement RFC 8058 one-click unsubscribe

List-Unsubscribe: 
List-Unsubscribe-Post: List-Unsubscribe=One-Click

POST /u/opaque-token HTTP/1.1
Host: unsubscribe.example.com
Content-Type: application/x-www-form-urlencoded

List-Unsubscribe=One-Click

For marketing and subscribed mail, Yahoo requires a functioning list-unsubscribe header, a clearly visible unsubscribe link in the body, and processing within two days. The endpoint must accept the POST without login, confirmation page, preference questions, or a second click. Return a successful response only after the suppression is durably recorded or queued through a reliable transactional path.

Use an opaque, scoped, unguessable token. Do not expose a plain email address in the URL, log full tokens indefinitely, or let a token unsubscribe an unrelated tenant or list. Test retries and idempotency because mailbox providers may repeat a request.

Enroll every accountable DKIM domain in Sender Hub

1. Create an organization-controlled Sender Hub profile, preferably with a monitored team alias.
2. Add the DKIM d= domain and publish the requested DNS verification record.
3. Confirm the domain shows as verified.
4. Enroll it in the Complaint Feedback Loop and verify the reporting address.
5. Send a signed seed message, inspect the exact d=, and confirm that it matches the enrolled domain.
6. Record the domain owner, reporting mailbox, parser, suppression SLA, renewal/review date, and backup operator.

Yahoo's CFL is domain-based and requires DKIM. Yahoo no longer offers IP or CIDR-based CFL reporting. The program can return ARF reports for Yahoo-hosted brands, including AOL. Enrollment status belongs in an operational inventory, not one employee's account.

Authenticate, parse, and suppress CFL complaints

Expected Yahoo CFL indicators to validate as a set:

SMTP MAIL FROM: [email protected]
DKIM signing domain: arf.mail.yahoo.com
Content type: multipart/report; report-type=feedback-report
Report format: Abuse Reporting Format (ARF)

START TRANSACTION;

INSERT INTO complaint_events
    (provider, event_fingerprint, recipient_id, campaign_id, received_at)
VALUES
    ('yahoo', :fingerprint, :recipient_id, :campaign_id, UTC_TIMESTAMP())
ON DUPLICATE KEY UPDATE event_fingerprint = event_fingerprint;

INSERT INTO suppressions
    (recipient_id, scope, reason, created_at)
VALUES
    (:recipient_id, :scope, 'spam_complaint', UTC_TIMESTAMP())
ON DUPLICATE KEY UPDATE reason = 'spam_complaint';

COMMIT;

Authenticate the transport and message, parse MIME with a bounded library, quarantine malformed input, deduplicate reports, map the message to a recipient and tenant without trusting an arbitrary header, and suppress before the next send. Keep raw reports under restricted retention because headers can contain personal data.

Unsafe: suppressing an address from any message that merely looks like ARF allows forged reports to alter customer data. Validate the sending path, DKIM, expected envelope, MIME structure, internal message identifiers, tenant ownership, and duplicate key before changing suppression state.

Interpret complaint rate correctly

Yahoo's enforcement threshold is below 0.3%, but Sender Hub Insights calculates the provider complaint rate from messages delivered to the inbox. An internal calculation using all accepted mail, including messages placed in spam, can show a smaller rate and create false comfort.

SELECT
    recipient_domain,
    stream,
    campaign_id,
    SUM(provider_complaints) AS complaints,
    SUM(provider_inbox_deliveries) AS inbox_deliveries,
    CASE WHEN SUM(provider_inbox_deliveries) = 0 THEN NULL
         ELSE 100.0 * SUM(provider_complaints)
              / SUM(provider_inbox_deliveries)
    END AS provider_complaint_percent
FROM yahoo_delivery_daily
WHERE metric_date >= UTC_DATE() - INTERVAL 14 DAY
GROUP BY recipient_domain, stream, campaign_id;

Use Yahoo's rate for Yahoo enforcement decisions and internal rates for cohort diagnosis. Track counts as well as percentages; a tiny denominator can create a volatile rate. Set internal warning levels below the provider ceiling so the team has time to stop a bad cohort.

Use Sender Hub Insights as provider evidence

Sender Hub Insights provides aggregated delivery statistics for verified DKIM domains and reports data in UTC. It is independent of CFL enrollment and currently has no public API. Establish a review schedule and store screenshots or exports allowed by the interface with date, domain, filter, operator, and incident ID.

Insights rolls all sending domains using the selected DKIM domain into that domain's view. This is convenient for a platform-wide signal and weak for tenant attribution. A dual-signature design can provide brand alignment plus a platform identity for provider programs, but it still needs an internal message key that joins the platform signer to tenant, From domain, IP, stream, campaign, and recipient cohort.

Use Yahoo performance feeds when the program qualifies

Yahoo documents a separate Email Deliverability and Performance Feeds program. It is not the ordinary Sender Hub dashboard and access is not automatic. The Placement Feed can report aggregated inbox, spam, folder, error, and complaint counts with dimensions including DKIM domain, From domain, connecting IP, and an approved campaign header. The Campaign Performance Feed adds provider-observed engagement and campaign dimensions. Yahoo asks interested organizations to contact it about access requirements.

Provider feeds do not remove the need for MTA telemetry. Their reporting SLA means the queue can deteriorate before provider data arrives. SMTP and queue controls must react in minutes; provider placement and engagement evidence validates or revises the diagnosis later.

-- A cohort fact table should preserve every boundary used during diagnosis.
SELECT
    DATE_FORMAT(attempted_at_utc, '%Y-%m-%d %H:00:00') AS utc_hour,
    recipient_domain,
    connecting_ip,
    dkim_domain,
    header_from_domain,
    tenant_id,
    stream_id,
    campaign_id,
    template_version,
    acquisition_source,
    SUM(attempts) AS attempts,
    SUM(accepted) AS accepted,
    SUM(temp_failed) AS temp_failed,
    SUM(perm_failed) AS perm_failed,
    SUM(retry_attempts) AS retry_attempts
FROM delivery_cohort_hourly
WHERE recipient_provider = 'yahoo_managed'
  AND attempted_at_utc >= UTC_TIMESTAMP() - INTERVAL 72 HOUR
GROUP BY 1,2,3,4,5,6,7,8,9,10;

Treat the complaint denominator as an analytical constraint

The published 0.3% threshold is not interchangeable with complaints divided by accepted mail. Yahoo says the Insights rate uses messages delivered to the inbox. If placement deteriorates, the provider denominator may contract while the sender's accepted denominator stays large. That can make the internal rate appear stable precisely when the provider rate worsens.

Example, not a Yahoo measurement:

100,000 messages accepted by the MX
 60,000 delivered to inbox
    150 provider complaints

Internal accepted denominator: 150 / 100,000 = 0.15%
Provider inbox denominator:     150 /  60,000 = 0.25%

Counts matter with small cohorts. One complaint over a small inferred inbox denominator can move a daily percentage sharply. Do not create a universal shutdown decision from a one-day percentage without the count, denominator, volume qualification, previous period, and campaign mix. Conversely, do not average a bad acquisition source into the whole brand and call it healthy.

Design CFL attribution for the gaps, not the happy path

A CFL report is a suppression trigger and an attribution input, not a full complaint census. Platform and customer DKIM signatures, redacted message parts, forwarded mail, missing campaign headers, or a retired mapping table can leave an authenticated report that cannot be assigned safely. The pipeline must distinguish “valid provider report” from “valid report mapped to the correct recipient and tenant.”

Keep the event fingerprint, provider receipt time, authentication result, signing domain, original message key, recipient token, tenant, campaign, suppression scope, and mutation outcome. Without the mutation outcome, an ARF count can look healthy while the next campaign still mails the complainant.

Build consent evidence and recipient hygiene

For every subscribed recipient, retain source, form or product context, timestamp, IP where lawful and useful, disclosed expectation, confirmation event, list or purpose, and material policy version. Confirmed opt-in reduces address mistakes and abuse; it does not grant permanent permission to send unrelated content forever.

Email validation can catch syntax errors, disposable domains, and some known risks. It cannot create consent or prove that the current mailbox owner wants the message. Do not use a “valid” result to justify a purchased list.

Warm traffic by evidence, not a copied schedule

There is no universal Yahoo warming table. Capacity depends on domain and IP history, list quality, engagement, content, infrastructure, stream, and recipient mix. Start with recent engaged recipients who clearly expect the mail, keep volume predictable, and increase only after acceptance, deferrals, complaints, invalids, queue latency, and Sender Hub data remain healthy.

Unsafe: doubling volume on a calendar schedule despite rising deferrals or complaints converts a small warning into a reputation event. A warm-up gate is an operational decision, not permission to ignore evidence.

Control outbound volume and retries

Yahoo historically documented a maximum of 20 messages per SMTP connection. The current Sender Hub no longer publishes that number. It says Yahoo accepts a limited number of messages per connection and may terminate the connection, without an SMTP error, after the limit is reached. It also does not publish a fixed concurrent-connection limit. Keep 20 as historical operating context or a conservative initial cap if it suits the MTA, not as a current Yahoo guarantee.

Conservative starting geometry, not a Yahoo entitlement:

per_ip_concurrency        = observed safe starting value
messages_per_connection   = 20 historical-reference cap
new_connections_per_sec   = bounded and jittered
retry_connections         = counted separately from first attempts

Advance only when session closes, 2xx acceptance, TS deferrals,
queue age and retry amplification remain explainable.

Example policy inputs per Yahoo-hosted destination cohort:

concurrent connections       bounded by observed acceptance and queue health
messages per connection      limited and monitored
new connection rate          gradual, with jitter rather than bursts
4xx retry                    exponential backoff with queue expiry
5xx response                 classify; do not retry a permanent recipient failure
campaign release             cohort-sized batches with stop conditions
emergency control            pause stream, tenant, campaign, domain, or IP precisely

Yahoo can temporarily defer mail because of unusual traffic, complaints, spam-like characteristics, server load, DNS issues, or authentication lookup problems. Slow down, preserve the exact enhanced status and text, and investigate. Opening more connections to force delivery usually makes a reputation or capacity problem worse.

Measure retry amplification before it becomes the traffic pattern

A deferral incident changes offered load even when campaign volume is flat. Fresh mail continues to arrive, deferred recipients return from the queue, and simultaneous workers may retry the same destination cohort. Yahoo then observes a traffic pattern shaped by the sender's retry policy rather than the original campaign plan.

offered attempts = first attempts + retry attempts
retry amplification = all attempts / unique recipients attempted

Example:
400,000 first attempts + 520,000 retries = 920,000 SMTP attempts
920,000 / 400,000 = 2.30x attempt amplification

Do not interpret a falling 4xx percentage while the queue is paused as reputation recovery. The denominator changed. Recovery evidence comes from a controlled new cohort with known first attempts, separately counted retries, stable connection behavior, and enough time for delayed provider signals.

Classify SMTP responses before acting

# Extract Yahoo-related SMTP outcomes from an approved MTA log copy.
grep -iE 'yahoo|aol|cox\.net' /var/log/mail.log \
  | grep -E 'status=(sent|deferred|bounced)|said:' \
  | tail -n 200

# Count exact normalized diagnostic categories in your log pipeline,
# not only generic "deferred" totals.

Never retry a permanent invalid recipient. For a policy-related 5xx, determine whether the message failed because of a persistent identity or content defect. Blindly replaying the same queue can repeat the violation.

Translate Yahoo error families into queue decisions

The three-digit SMTP reply controls the immediate queue action; Yahoo's diagnostic text explains where to investigate. Never classify from a fragment such as 554 alone. Retain the SMTP stage, basic code, enhanced status code when present, Yahoo diagnostic family, complete text, recipient domain, connecting IP, responding MX, queue ID, attempt number, and UTC timestamp.

Bad normalization:
provider=yahoo outcome=bounced reason=policy

Useful normalization:
provider=yahoo
smtp_stage=DATA
smtp_code=421
enhanced_status=4.x.x
diagnostic_family=TS
diagnostic_text=<complete Yahoo reply>
connecting_ip=192.0.2.25
responding_mx=<hostname>
recipient_domain=aol.com
queue_id=<internal ID>
attempt_number=3
first_seen_utc=<timestamp>

For permanent failures, distinguish the unit being rejected. “Recipient does not exist” justifies address suppression. A message-format or PH policy rejection justifies holding the artifact or stream, not automatically deleting a valid subscriber. An authentication rejection calls for identity repair. A complaint or unsolicited-mail diagnostic calls for audience and program containment. The SMTP class is the queue instruction; the full diagnostic supplies the remediation boundary.

Read Yahoo diagnostics as a boundary, not a label

Yahoo documents TS-series responses as temporary deferrals and PH-series responses as content-based policy blocks. The family narrows the investigation; it does not identify the exact tenant, campaign, link, or reputation input. Store the full reply rather than normalizing everything to “Yahoo deferred.” Diagnostic text, enhanced status, responding MX, SMTP stage, and first-seen time can separate connection treatment from recipient, RFC, authentication, and content failures.

Keep the MTA and network accountable

• Patch the MTA and operating system, restrict submission, require authentication, and prevent open relay or proxy behavior.
• Rate-limit compromised users and tenants independently, and alert on new sources, credential abuse, and queue anomalies.
• Publish routes for owned address space, maintain route authorization where applicable, and watch for unauthorized origin changes.
• Use stable EHLO, PTR, forward DNS, time synchronization, TLS, and consistent envelope identities.
• Do not mix unreviewed user-generated content into a trusted bulk stream.
• Retire unused IPs, DNS records, keys, and platform credentials through a documented decommission process.

A blocklist listing may be useful evidence, but it is not a complete reputation diagnosis. Yahoo's error guidance specifically mentions Spamhaus for some permanent failures. Check the exact IP and diagnostic, correct the abuse or list-quality cause, follow the list operator's process, and verify Yahoo behavior after remediation.

Build content from recipient expectation

Spam filters do not operate from a short list of forbidden words. A “free” or “discount” token in a wanted, authenticated message is not automatically spam, and removing the token cannot repair a scraped list. Focus on recognizable identity, accurate subject and preview text, consistent purpose, accessible design, working HTTPS links, safe landing pages, visible unsubscribe, restrained frequency, and content promised at signup.

Test the raw MIME, plain-text alternative, encoding, duplicate headers, Message-ID, Date, From, Reply-To, links, redirects, image domains, and mobile rendering. Do not use unrelated compromised domains, open redirectors, deceptive display URLs, or URL shorteners that hide ownership.

Separate shared-IP and dedicated-IP decisions

Moving to a new IP without correcting consent, complaints, authentication, content, or sending behavior transfers the problem. Do not rotate infrastructure to evade enforcement.

Use differential diagnosis before choosing a remedy

Separate structural failures from transient noise

A structural failure repeats across comparable attempts and maps to a stable boundary: one IP, one DKIM domain, one audience source, one template release, or one DNS dependency. Transient noise is brief, does not persist across a controlled retry window, and may coincide with provider resource conditions. Time alone is not the test. Use recurrence, cohort consistency, control-path behavior, and provider diagnostic text.

-- Locate the first hour where an affected cohort diverged from its control.
SELECT
    utc_hour,
    cohort_name,
    100.0 * SUM(temp_failed) / NULLIF(SUM(attempts), 0) AS temp_fail_pct,
    100.0 * SUM(perm_failed) / NULLIF(SUM(attempts), 0) AS perm_fail_pct,
    SUM(retry_attempts) / NULLIF(SUM(unique_recipients), 0) AS retries_per_recipient,
    MAX(oldest_queue_seconds) AS oldest_queue_seconds
FROM yahoo_incident_cohorts
WHERE incident_id = :incident_id
GROUP BY utc_hour, cohort_name
ORDER BY utc_hour, cohort_name;

Annotate deploys, DNS changes, audience imports, credential events, template releases, pool moves, and rate changes on the same UTC timeline. The useful question is not “what was different this week?” It is “what changed at or before the first divergence and shares the same blast radius?”

Contain a Yahoo deliverability incident

1. Define impact by recipient domain, DKIM domain, IP, stream, tenant, campaign, template, link domain, geography, and start time.
2. Pause the narrowest affected traffic. Stop broad volume increases and preserve transactional service where it is healthy and separated.
3. Capture exact SMTP responses, queue state, authentication results, Sender Hub evidence, CFL complaints, DNS, release and audience changes.
4. Check for compromised credentials, open relay behavior, unauthorized tenants, injected content, new sources and routing anomalies.
5. Suppress complaints, unsubscribes and permanent invalid recipients before any restart.
6. Correct the causal audience, frequency, identity, infrastructure, content or retry defect.
7. Resume with a small engaged cohort and explicit gates. Watch provider and internal evidence through the full retry and reporting window.

Unsafe: clearing queues, deleting logs, changing several IPs and domains, or resending the whole failed campaign destroys evidence and can expand the incident. Preserve the failed state, make one attributable correction, and use a bounded recovery cohort.

Escalate to Yahoo with diagnostic evidence

Use Sender Hub support after internal diagnosis, especially when consistent provider-specific failures persist. A ticket should contain the sending IPs, EHLO/PTR, envelope and From domains, DKIM d= and selector, UTC timestamps, recipient-domain samples, complete SMTP code and text, queue IDs, message IDs, volume profile, affected percentage, authentication evidence, complaint and invalid-recipient trend, changes made, and tests after correction.

Support case summary

Impact start/end in UTC:
Yahoo-hosted recipient domains affected:
Sending IP and EHLO/PTR:
Header From and envelope domains:
DKIM d= and selector:
Exact SMTP response with diagnostic code:
Sample queue IDs and Message-IDs:
Expected versus observed accepted volume:
Complaint, invalid, and deferral trend:
Recent audience/template/infrastructure changes:
Containment and corrective actions completed:
Small-cohort retest result:

Do not include recipient passwords, full mailing lists, private keys, or unnecessary personal content. Redact samples without removing the headers and identifiers needed to investigate.

Use the current Yahoo support and diagnostic resources

Keep these destinations in the deliverability runbook so an operator can move from a provider response to the correct action without searching during an incident. For migrated cox.net recipients, use the Yahoo sender path for delivery and SMTP-policy problems because the mailbox service is hosted through Yahoo Mail. Cox account access, billing, or consumer-support issues still belong with Cox.

Do not open a support ticket as a substitute for correcting a broken identity, an unsolicited list, repeated permanent failures, or uncontrolled sending. Provider support is most useful when the evidence is specific and the sender has already contained the causal behavior.

Monitor the complete operating loop

Test realistic failure scenarios

Completion checklist

• Yahoo, AOL, migrated cox.net, and other Yahoo-hosted recipient domains are grouped operationally but remain separate reporting cohorts.
• Every source, stream, IP, EHLO/PTR, envelope domain, From domain, DKIM domain, selector, link domain and unsubscribe endpoint has an owner.
• SPF, DKIM and DMARC pass with alignment on real delivered messages; DNS and key rotation are monitored.
• Marketing/subscribed messages contain functional RFC 8058 one-click and visible body unsubscribe, processed within two days.
• Sender Hub domains are organization-controlled, Insights is reviewed in UTC, CFL enrollment matches the real DKIM d=, and complaints suppress immediately.
• Complaint rate uses Yahoo's provider denominator for enforcement review and internal cohort rates for diagnosis.
• Consent, invalid-recipient, inactivity, complaint, unsubscribe and reimport controls are enforced before sending.
• Traffic separation, warming gates, connection limits, 4xx backoff, 5xx handling and queue expiry have been tested.
• Content, MIME, links, DNS, TLS, MTA security, routing and shared-pool ownership are reviewed.
• Incident containment and Yahoo support procedures preserve exact evidence and recover through a small engaged cohort.

Primary references

• Yahoo Sender Requirements and Recommendations
• Yahoo Sender Hub FAQs and Insights guidance
• Yahoo domain-based Complaint Feedback Loop
• Yahoo SMTP Error Codes
• Yahoo and AOL Sender Support
• Yahoo Subscription Hub and one-click unsubscribe
• Yahoo Email Deliverability and Performance Feeds
• Cox email support and Yahoo Mail transition
• RFC 8058 one-click unsubscribe
• RFC 7489 DMARC
• RFC 6376 DKIM
• RFC 7208 SPF
• RFC 5965 Abuse Reporting Format