Spam and Inbox Placement Incidents

First 15 minutes

1. Check whether the affected mail passes SPF or DKIM; unauthenticated messages can be spam-classified or rejected with 5.7.26.
2. Read the Postmaster Tools user-reported spam rate and compare it with Google's recommended below-0.10% level and required below-0.30% level.

Now

• Reduce volume if Gmail bounces or deferrals are increasing.

Next 24 hours

• Restart at low volume with engaged recipients and monitor SMTP responses and reputation.

Next 7 days

• Increase volume gradually only while SMTP responses and reputation remain stable.

Technical checks

Verification criteria

• Confirm the Postmaster Tools user-reported spam rate remains below 0.30% and is moving toward the recommended below-0.10% level.
• Confirm bounces and deferrals do not rise as the controlled volume ramp proceeds.

Escalation criteria

• Escalate through Postmaster Tools only with a verified compliant domain and a sample that passes SPF and DKIM with a matching From domain.

Prevention

• Authenticate Gmail-bound mail with SPF or DKIM.
• Limit recipient spam reports by sending wanted mail and watching their effect on domain reputation.
• Use a gradual volume ramp to engaged recipients and reduce volume when bounces or deferrals begin.

Business impact

• Frequent Gmail spam reports can lower domain reputation and make future messages more likely to be classified as spam.

Provider notes

• Google requires the Postmaster Tools spam rate to stay below 0.30% and recommends keeping it below 0.10%.
• Postmaster Tools delivery-issue escalation has domain-verification, compliance, authentication, and alignment prerequisites.

Open questions

• Gmail does not disclose the complete spam-classifier model or the weight of each reputation and content signal.
• The incident's actual complaint rate, authentication alignment, traffic history, and recipient cohort must be measured from current evidence.

First 15 minutes

1. Capture live SMTP and ESP telemetry for the incident window because Postmaster Tools is delayed and can omit low-volume data.
2. Record Postmaster spam rate, IP and domain reputation, authentication, feedback-loop, encryption, and delivery-error changes.
3. Compare the collapse with bursts, sudden volume spikes, or recently changed traffic, and reduce volume while bounces or deferrals remain elevated.

Now

• Reduce affected Gmail volume while bounces or deferrals are elevated and remove bursts or sudden spikes.

Next 24 hours

• Restore consistent sending and keep the daily Gmail Postmaster spam rate below 0.1%, avoiding 0.3% or higher.

Next 7 days

• When multiple IPs are used, separate message types by sending IP and keep the same From address within each category.

Technical checks

Verification criteria

• Live SMTP and ESP telemetry improves first, then Postmaster Tools shows lower spam classification signals after its usual delay, recognizing that improvement can take time.
• Postmaster spam rate, reputation, authentication, feedback-loop, encryption, and delivery-error dimensions are reviewed together rather than using one signal as proof.

Escalation criteria

• Escalate to the ESP or a deliverability specialist for remediation rather than requesting a Gmail allowlist, because Google does not accept provider allowlist requests or guarantee spam-filter bypass.

Prevention

• Keep daily spam rate below 0.1% and avoid 0.3% or higher, use consistent gradual volume, and separate message types by IP when multiple IPs are used.

Business impact

• A high user-reported Gmail spam rate increases spam classification, and classification can take time to improve after complaint rates improve.

Open questions

• No incident-window Postmaster trends, SMTP responses, campaign and stream segmentation, authentication results, or recent infrastructure and content changes were supplied.
• Gmail does not publish complete spam-classifier logic or guarantee inbox placement, so no single dashboard signal proves causation.

First 15 minutes

1. Capture and authenticate the Microsoft postmaster NDR, including its diagnostic information for administrators.
2. Segment failures by consumer domain, sending IP age, authentication, list accuracy, and complaint signals.

Now

• Reduce frequency or volume if the pattern indicates too much Outlook.com mail is being sent at once.

Next 24 hours

• Correct the specific authentication, list-accuracy, complaint, domain, IP, or content issue identified by the self-service checks.

Next 7 days

• Keep frequency or volume reduced while the evidence continues to indicate Outlook.com volume pressure.

Technical checks

Verification criteria

• New authenticated postmaster responses no longer contain the prior administrator diagnostic for representative test messages.
• The specific Outlook.com consumer failure remains resolved after the corrected traffic is sent from the intended IP.

Escalation criteria

• Submit Outlook.com Sender Support only after policy and FAQ checks are complete and the problem remains unresolved for msn.com, outlook.com, hotmail.com, or live.com recipients.

Prevention

• Track IP age, domain and authentication state, list accuracy, complaint rate, and content changes before increasing Outlook.com volume.

Business impact

• Filtering driven by IP, domain, authentication, list accuracy, complaints, or content can delay or block legitimate Outlook.com consumer mail.

Provider notes

• The Outlook.com Sender Support form is limited to four named Microsoft consumer domains and a submission does not guarantee delivery.

Open questions

• The exact NDR, SMTP response, timestamps, affected recipient domains, sending IPs, and whether the failure is temporary or permanent are not supplied.
• Microsoft does not publish numeric weights for SmartScreen reputation factors or a guaranteed support-response or mitigation timeline on the cited page.
• Microsoft 365 tenant delivery issues use different admin and support paths than Outlook.com consumer-domain Sender Support.

First 15 minutes

1. Capture the original and forwarded Authentication-Results and identify the forwarding source, intermediary, and Gmail destination.
2. Compare Gmail's post-forward authentication result with the result recorded before the forwarding hop.
3. Confirm that Gmail performed its own authentication evaluation after the forwarding hop.

Now

• Filter spam before forwarding so the controlled route does not relay unwanted traffic into Gmail.
• Where the forwarding administrator controls it, use the forwarding domain as the envelope sender and authorize every forwarding service in that domain's SPF record.

Next 24 hours

• Consider isolating forwarded traffic on a unique forwarding domain or IP when recipient reports are harming the shared forwarding reputation.

Next 7 days

• Document and enforce the forwarding configuration that owns the envelope sender, SPF authorization, and pre-forward spam filtering.

Technical checks

Verification criteria

• A forwarded test shows the expected post-hop SPF result and Gmail's own Authentication-Results rather than relying on a pre-forward pass.
• DKIM remains valid when the forwarder leaves signed content and headers unchanged.

Escalation criteria

• Escalate to the forwarding administrator when the envelope sender or SPF authorization cannot be corrected.
• Escalate to deliverability when spam reports continue after pre-forward filtering and reputation isolation.

Prevention

• Avoid changing DKIM-protected content and headers in the forwarding path.
• Filter spam before forwarding and isolate the forwarding reputation where the service design permits it.

Business impact

• Forwarded messages can lose authentication and land in spam, delaying or preventing recipients from seeing the intended mail.
• Changes to DKIM-protected content or headers can invalidate the signature and reduce the forwarded message's chance of reaching the inbox.

Provider notes

• Gmail evaluates indirect mail after the forwarding hop and does not automatically trust authentication recorded earlier in the path.
• Gmail's direct-mail DMARC alignment requirement does not apply to forwarded or mailing-list messages, although authentication and spam filtering still occur.

Open questions

• The phrase forwarded through Gmail is ambiguous: the forwarding source, destination, intermediary, and whether the destination is a personal Gmail account were not supplied.
• No original and post-forward Authentication-Results, DKIM signatures, Received path, or forwarding configuration was provided, so the failing mechanism is unresolved.
• Gmail treats indirect mail differently from direct mail, and other receivers can apply different forwarding policies.

First 15 minutes

1. Collect the complete Yahoo SMTP replies and separate deferrals, rejections, and spam placement by domain and stream.
2. Check SPF, DKIM, DMARC alignment, and forward and reverse DNS against the applicable sender class.
3. Test the List-Unsubscribe header, visible body link, and unsubscribe processing for marketing and subscribed mail.
4. Identify hard bounces, soft bounces, invalid recipients, and inactive recipients in the Yahoo cohort.

Now

• Correct missing Yahoo authentication, DMARC alignment, or DNS requirements for the applicable sender class.
• Restore the required one-click-capable header, visible body link, and unsubscribe processing for bulk marketing or subscribed mail.

Next 24 hours

• Separate bulk marketing from transactional, alert, and user mail by IP or DKIM domain where the sending design permits it.
• Remove invalid recipients promptly and review inactive Yahoo recipients.

Next 7 days

• Establish ongoing hard-bounce, soft-bounce, inactive-recipient, and reconfirmation review without inventing a universal inactivity period.

Technical checks

Verification criteria

• Yahoo-bound tests pass the applicable authentication, alignment, and forward and reverse DNS checks, with Yahoo's own complaint rate below 0.3%.
• Bulk marketing or subscribed tests expose the required unsubscribe controls and processing completes within two days.
• Eligible DKIM domains have active Complaint Feedback Loop coverage and complaint copies are being processed.

Escalation criteria

• Escalate to the ESP or Yahoo support path when full SMTP replies persist after all applicable all-sender requirements pass.
• Escalate bulk-only failures when SPF, DKIM, DMARC pass and alignment all validate but delivery remains impaired.

Prevention

• Separate marketing reputation from transactional, alert, and user traffic by IP or DKIM domain where appropriate.
• Monitor bounces and inactive recipients, remove invalid recipients promptly, and consider reconfirmation for inactive subscribers.
• Maintain Complaint Feedback Loop coverage for eligible Yahoo DKIM domains and process complaints promptly.

Business impact

• When marketing and transactional streams share an IP or DKIM-domain reputation, problems in one stream can reduce delivery of the other.

Provider notes

• Yahoo's 0.3% complaint-rate threshold is Yahoo-specific and is not a universal deliverability benchmark.
• Yahoo does not publish a numeric bulk-sender threshold on the cited guidance.

Open questions

• Exact Yahoo SMTP replies, affected Yahoo domains, delivery versus spam placement, sending volume, stream type, and change timeline were not provided.
• Whether Yahoo classifies this sender as bulk is unresolved; Yahoo does not publish a numeric bulk threshold on the cited page.
• Yahoo requirements and metrics are provider-specific and may change; current Sender Hub guidance must be rechecked during the incident.

First 15 minutes

1. Confirm that affected messages are in Promotions rather than Spam or a rejected or deferred state.
2. Check whether the Gmail-bound stream meets the applicable SPF, DKIM, and DMARC requirements.
3. Review Postmaster Tools for authentication, spam-report, delivery-error, and reputation signals where data is available.

Now

• Keep the stream stable while confirming that it is wanted, promotional, and separate from transactional mail.

Next 24 hours

• Use consistent From identities for each message category and separate promotions from receipts and account notifications.

Next 7 days

• Maintain category-specific From identities and review recipient-specific category evidence without promising universal Primary placement.

Technical checks

Verification criteria

• Recorded test messages are categorized as expected for each recipient without assuming that all recipients will learn the same preference.
• Authentication checks pass for the applicable Gmail sender scope and Postmaster Tools shows no associated delivery-error or spam signal requiring incident handling.

Escalation criteria

• Escalate to deliverability or the ESP when Postmaster Tools shows authentication, spam, delivery-error, or reputation problems rather than Promotions placement alone.

Prevention

• Keep receipts, promotions, and account notifications on consistent, distinct sender identities.
• Continuously maintain the Gmail-required authentication for the sender's applicable volume scope.

Business impact

• Promotional messages may receive less immediate attention because Gmail normally limits new-mail notifications to Primary-category messages.

Provider notes

• Gmail's Default inbox classifies deals and offers as Promotions; recipient moves can teach that recipient's preferences but cannot guarantee Primary placement for everyone.

Open questions

• The actual message content, stream purpose, From identity, authentication results, recipient settings, and placement distribution are not provided, so the sender-specific categorization cause remains unknown.
• Gmail category tabs and learned preferences are recipient-specific; neither a sender nor this pack can guarantee Primary placement across Gmail users.

First 15 minutes

1. After confirming the message and sender are legitimate, select the message, mark it Not junk, and add the sender to Safe senders.
2. Remove any accidental sender block and inspect Inbox rules that match the sender or message keywords.

Now

• Mark the verified message Not junk and add the sender to Safe senders.

Next 24 hours

• Remove accidental blocks and correct sender- or keyword-based Inbox rules.

Next 7 days

• Confirm the documented Safe senders configuration and account for managed policies that may override a recipient's local list.

Technical checks

Verification criteria

• The verified message is restored from Junk and the recipient's Not junk action is recorded.
• A subsequent legitimate message from the configured Safe sender is not treated as Junk under the recipient's applicable Outlook.com controls.

Escalation criteria

• Escalate through Outlook.com sender support when policy-compliant mail continues to be misplaced across recipients and sample headers or NDR evidence is available.

Prevention

• Keep trusted senders on the recipient's Safe senders list where the documented Outlook.com control applies.
• Review recipient blocks and rules for accidental sender or keyword matches.
• Monitor sender-wide Outlook.com filtering signals separately from one recipient's correction.

Business impact

• A legitimate message left in Outlook.com Junk can be automatically deleted before the recipient recovers a time-sensitive login, purchase, or support message.

Provider notes

• Outlook.com Junk messages are automatically deleted between 10 and 30 days after arrival; managed work or school retention can differ.

Open questions

• The Outlook product and account type, sample headers, authentication results, recipient rules and lists, message age, affected-recipient count, and sender-wide evidence are not provided.
• Consumer Outlook.com controls, desktop Outlook, work or school policies, Safe Senders behavior, and upstream gateway filtering can differ; administrator-enforced controls may override recipient choices.

First 15 minutes

1. Capture the complete iCloud SMTP error and any linked diagnostic URL from the mail logs.
2. Verify SPF, DKIM, the sending-domain DMARC policy, and reverse DNS for each affected sending IP.
3. Check explicit subscription, immediate unsubscribe, bounce handling, inactive-recipient removal, and suppression state for the audience.

Now

• Correct the authentication or reverse-DNS condition identified by the iCloud SMTP error.

Next 24 hours

• Correct any explicit-subscription, unsubscribe, bounce, inactive-recipient, or suppression hygiene gap found in the affected stream.

Next 7 days

• Review recurring iCloud rejection diagnostics by sending IP and domain so requirement failures are detected before the next bulk send.

Technical checks

Verification criteria

• Controlled messages no longer receive the same iCloud SMTP rejection in the mail logs.
• SPF, DKIM, DMARC publication, and reverse DNS meet Apple's bulk-mail requirements for the affected identity.
• The affected bulk stream is accepted only after all listed iCloud sender requirements are met.

Escalation criteria

• After applying Apple's practices and reviewing the logs without resolution, have a system administrator contact icloudadmin@apple.com with the company, domain, affected IPs, exact SMTP errors, and issue start time.

Prevention

• Continuously validate the iCloud bulk-mail authentication and reverse-DNS baseline.
• Maintain explicit subscription, immediate unsubscribe, bounce handling, inactive-recipient removal, and suppression controls.
• Maintain internal rejection and recipient-feedback monitoring because iCloud offers no allowlist or feedback loop.

Business impact

• Bulk email that misses an iCloud sender requirement can be rejected before intended recipients receive it.
• The absence of an iCloud allowlist and feedback loop limits direct sender-side visibility into filtering and complaints.

Provider notes

• iCloud Mail offers neither a bulk-sender allowlist nor a feedback loop.

Open questions

• Account-level iCloud IP or domain reputation and the filtering decision are not available from a public sender dashboard because Apple offers neither an allowlist nor a feedback loop.