Mailbox Provider-specific Incidents

First 15 minutes

1. For 550 5.7.515, inspect current message headers for SPF, DKIM, DMARC, and alignment.
2. Check whether Outlook.com is reporting low IP reputation and review the sender factors Microsoft identifies.

Now

• Correct SPF, DKIM, DMARC, or alignment when the 550 5.7.515 diagnostic identifies insufficient authentication.

Next 24 hours

• Address the documented Outlook.com reputation factors, including IP and domain reputation, authentication, list accuracy, complaint rate, and content.

Next 7 days

• Maintain the corrected authentication and sender-quality controls before expanding Microsoft consumer traffic.

Technical checks

Verification criteria

• Confirm current message headers show SPF and DKIM passing, a published DMARC record, and at least one aligned passing identifier for an Outlook.com high-volume sender.
• Confirm the corrected test no longer returns 550 5.7.515.

Escalation criteria

• Contact Microsoft sender support only after complying with Outlook.com policies and guidelines, recognizing that submission does not guarantee delivery.

Prevention

• Keep SPF, DKIM, DMARC, and From-domain alignment valid for Microsoft high-volume consumer traffic.
• Continuously manage the IP, domain, authentication, list-accuracy, complaint-rate, and content factors Microsoft says influence filtering.

Business impact

• A permanent 550 rejection means the requested delivery did not occur, so affected recipients do not receive the message.
• An unresolved 550 5.7.515 authentication failure can continue blocking the high-volume sender's Microsoft consumer traffic.

Provider notes

• Microsoft defines a high-volume sender as one sending 5,000 or more messages to its consumer services with the same RFC 5322 From domain.
• NDR 550 5.7.515 identifies insufficient authentication for a high-volume sending domain.

Open questions

• The exact rejection cause must be selected from the full NDR code, diagnostic text, generating host and a current message's authentication results.
• Microsoft does not disclose the complete weighting of Outlook.com reputation and filtering signals.
• Consumer Outlook.com enforcement differs from tenant-specific Exchange Online recipient rules, so the destination service must be confirmed.

First 15 minutes

1. Capture the complete Yahoo diagnostic and classify it as an invalid-recipient, DMARC or DKIM, content, suspicious-behavior, or Spamhaus cause.
2. When the diagnostic indicates a content-policy block, inspect outbound queues for objectionable or malicious content and sender abuse.

Now

• Stop retries for the affected Yahoo 5xx message and remove an address only when the response is a recipient-level permanent failure under the list policy.

Next 24 hours

• Correct bulk-sender SPF, DKIM, DMARC, and From-domain alignment when the diagnostic identifies an authentication policy failure.

Next 7 days

• Remove malicious or objectionable traffic and prevent spammers from abusing the sending server when the diagnostic identifies a content-policy block.

Technical checks

Verification criteria

• Confirm corrected test messages no longer receive Yahoo 553 or 554 permanent errors.
• For bulk traffic, confirm SPF, DKIM, DMARC, and From-domain alignment meet Yahoo's requirements.
• Confirm the Yahoo-calculated inbox spam complaint rate is below 0.3%.

Escalation criteria

• Escalate to deliverability or the ESP when the complete Yahoo diagnostic identifies a sender-wide policy class that remains after its documented cause is corrected.
• Escalate to security when the content-policy diagnostic and outbound queue review indicate malicious use of the sending server.

Prevention

• Maintain Yahoo bulk-sender SPF, DKIM, DMARC, and From-domain alignment.
• Keep the Yahoo-calculated inbox spam complaint rate below 0.3%.
• Monitor outbound queues and prevent spammers from abusing the sending server.

Business impact

• A Yahoo 553 or 554 permanent error means the affected message was not delivered.

Provider notes

• Yahoo documents 553 and 554 as permanent errors and lists distinct diagnostic strings for recipient, policy, content, behavior, and Spamhaus causes.
• Yahoo accepts relaxed DMARC alignment for its bulk-sender requirement.

Open questions

• The exact permanent-failure class cannot be selected without the complete SMTP diagnostic text and affected recipient or connection scope.
• Yahoo Sender Hub is the direct source used here; whether a particular AOL endpoint applies identical handling must be verified from its returned host and diagnostic.
• A recipient-level invalid-address failure must not be generalized into a domain-wide sender block.

First 15 minutes

1. Separate Gmail responses matching 421 4.7.28 from those matching 550 5.7.26.
2. For 550 5.7.26, verify why both SPF and DKIM authentication failed.
3. Check Postmaster Tools delivery-error, authentication, spam-rate, and reputation dashboards for personal Gmail traffic.

Now

• Reduce the affected Gmail volume while messages are bouncing or deferring, preserving essential traffic.

Next 24 hours

• Increase Gmail volume slowly only after live SMTP error rates fall.

Next 7 days

• Continue controlled volume increases rather than immediately restoring the previous sending rate.

Technical checks

Verification criteria

• Live Gmail SMTP logs no longer show the incident's 421 4.7.28 response during controlled essential sends.
• Postmaster Tools later corroborates recovery in authentication or delivery-error trends when sufficient personal-Gmail volume is reported.

Escalation criteria

• Use Postmaster Tools to report incorrect rejection or temporary failure only when sender eligibility and Gmail requirements are met.

Prevention

• Monitor Gmail authentication and delivery errors while changing volume gradually after a failure.

Business impact

• Temporary Gmail rate limiting or authentication rejection can prevent timely recipient-server handoff of ticket-sale confirmations.

Provider notes

• Postmaster Tools typically updates within 24 hours, may omit low-volume days, and covers personal Gmail rather than every Google Workspace recipient.

Open questions

• The exact Gmail SMTP response, affected recipient type, authentication results, sending IP/domain, and traffic change are not supplied.
• Postmaster Tools covers personal Gmail traffic and may not expose low-volume or real-time evidence.
• The word 'blocked' could mean temporary deferral, permanent SMTP rejection, spam placement, or a recipient-side Google Workspace rule.

First 15 minutes

1. Record the provider's incident resolution time and separate messages received before it from new samples.
2. Send privacy-safe controlled samples across the affected Gmail traffic segment and preserve each full original and authentication results.
3. Check Gmail-specific spam rate, reputation, authentication, feedback-loop, and delivery-error views together, while accounting for dashboard latency and low-volume omissions.

Now

• Run newly sent controlled samples across the affected Gmail traffic segment and preserve their full originals and authentication results.

Next 24 hours

• Compare new placement, delay, rejection, and Postmaster trends with the pre-incident baseline, keeping historical messages separate.

Next 7 days

• Continue baseline comparison until the affected stream's new-message observations remain stable rather than relying on a single mailbox sample.

Technical checks

Verification criteria

• Verify that newly sent post-resolution samples across the affected Gmail segment return to the pre-incident placement, delay, and rejection baseline.
• Confirm that Postmaster spam rate, reputation, authentication, feedback-loop, and delivery-error signals are consistent with recovery, allowing for non-real-time data and low-volume omissions.

Escalation criteria

• If incorrect classification continues, report it through Postmaster Tools only for a verified owned domain that meets Gmail sender requirements and submit a sample that passes SPF and DKIM with an aligned From domain.

Prevention

• Maintain a verified Postmaster Tools domain and monitor Gmail spam, reputation, authentication, feedback-loop, and delivery-error views together.
• Keep a controlled sample process that preserves full originals and authentication results for future comparisons.

Business impact

• During the named incident, promotional and social labels could be missing, spam-warning banners could appear, and delivery could be delayed generally up to ten minutes, although Google reported no lost or erroneously delivered messages in the documented window.

Provider notes

• For the January 24, 2026 incident, Google marked resolution at 09:55 US/Pacific and warned that pre-resolution messages could retain misclassification warnings.
• Postmaster Tools is not real time and can omit low-volume days; its Compliance status uses a rolling multi-day average.

Open questions

• No post-resolution sample headers, placement observations, delivery-error trend, affected stream, or baseline is provided, so sender-specific recovery remains unverified.
• Postmaster data latency, low-volume omissions, and incident-specific residual warnings prevent one universal recovery observation window.

First 15 minutes

1. Capture the exact Yahoo 421 or 451 response and diagnostic code and use it to narrow traffic, content, complaint, server, DNS, or authentication causes.
2. Inspect the outbound queue and reduce only the sustained affected Yahoo stream while normal retries continue.
3. Preserve repeated identical diagnostics for a possible Yahoo Sender Support Request.

Now

• Let the normal deferred queue retry later and reduce the sustained affected Yahoo stream while inspecting the exact error.

Next 24 hours

• Correct applicable authentication, DNS, complaint, and unsubscribe-control gaps before restoring volume.

Next 7 days

• Enroll and process Yahoo Complaint Feedback Loop reports for the outbound DKIM signing domain where applicable so complaining recipients can be suppressed.

Technical checks

Verification criteria

• Verify that new Yahoo deferrals and end-to-end delay return to the sender's baseline before restoring normal volume.
• Confirm that repeated diagnostics stop and that enrolled complaint reports are processed into recipient suppression where applicable.

Escalation criteria

• After local review, submit a Yahoo Sender Support Request with the exact error and diagnostic codes when the same temporary error persists over an extended period.

Prevention

• Maintain Yahoo-required authentication, valid forward and reverse DNS, applicable DMARC, RFC-compliant mail, and the provider's unsubscribe controls.
• Use Yahoo's DKIM-domain Complaint Feedback Loop to suppress recipients who report enrolled mail as spam.

Business impact

• Yahoo 421 or 451 temporary blocks can delay delivery to affected Yahoo-hosted recipients until the receiving condition clears and the sender retries successfully.

Provider notes

• Yahoo permits 4XX mail to be retried later, while unchanged 5XX permanent failures should not be retried.
• Yahoo's current requirements apply to its hosted consumer mailbox brands, not Yahoo Japan, and Yahoo does not publish a fixed bulk-sender volume threshold.

Open questions

• The exact Yahoo 4XX response and diagnostic code, affected domains, sending IP, queue age, complaint trend, content stream, and authentication results are not provided.
• Yahoo-hosted consumer brands, Yahoo Japan, and ESP retry schedulers differ; Yahoo's current Sender Hub claims must stay scoped to its hosted domains and the sender's own MTA behavior.

First 15 minutes

1. Capture the complete iCloud SMTP code, text, linked URL, affected sending IP, domain, stream, and start time from mail logs.
2. Check reverse DNS, SPF, DKIM, DMARC, sending-IP consistency, and marketing-versus-transactional separation.
3. Check explicit subscription, unsubscribe, bounce handling, inactivity removal, and suppression controls for bulk mail.

Now

• Correct the reverse-DNS, SPF, DKIM, DMARC, consistency, or stream-separation gap identified by the iCloud response.
• Remove any unsubscribed or suppressed address from the affected iCloud bulk audience.

Next 24 hours

• Validate explicit subscription, immediate unsubscribe, bounce handling, and inactive-subscriber removal across the iCloud bulk stream.

Next 7 days

• Maintain stable sending identities and keep marketing separate from transactional traffic for iCloud bulk mail.

Technical checks

Verification criteria

• Controlled iCloud tests return no SMTP refusal for the previously failing condition, and logs retain the full response for comparison.
• The affected bulk stream passes reverse DNS, SPF, DKIM, DMARC, identity-consistency, and stream-separation checks.
• The tested audience excludes unsubscribed and suppressed addresses and exposes working unsubscribe and bounce handling.

Escalation criteria

• After current best-practice checks and log review, escalate unresolved delivery to Apple's postmaster with company, domain, sending IPs, exact SMTP errors, and start time.

Prevention

• Maintain reverse DNS, SPF, DKIM, DMARC, stable identities, and separation between marketing and transactional iCloud streams.
• Mail only explicit subscribers, provide immediate unsubscribe, handle bounces, remove inactive subscribers, and never reactivate unsubscribed or suppressed addresses.
• Monitor IP and domain reputation, content, and user feedback without relying on a nonexistent iCloud allowlist or feedback loop.

Business impact

• An iCloud SMTP refusal prevents the affected message from reaching its intended recipient.
• IP and domain reputation, content, and user feedback can affect iCloud filtering without an allowlist or feedback loop to bypass the issue.

Provider notes

• iCloud provides neither a bulk-sender allowlist nor a feedback loop.
• Apple's postmaster escalation expects the company, domain, affected sending IPs, exact SMTP errors, and a description including start time.

Open questions

• The exact iCloud SMTP code and text, affected sending IP and domain, traffic type, timeline, and scope were not provided.
• The rejection cause remains unresolved until the iCloud SMTP response and corresponding sending configuration are inspected.
• iCloud has no allowlist or FBL, while other mailbox providers expose different reputation and support mechanisms.

First 15 minutes

1. Open Delivery Errors for the affected authenticated domain and time window, then compare rejection and temporary-failure reasons with sender logs.
2. Collect inbox-versus-spam samples and do not interpret a low Spam Rate value as proof of inbox placement.

Now

• For Gmail temporary failures, stop briefly, resume more slowly, and apply exponential backoff while honoring the exact response.

Next 24 hours

• Correct the requirement or traffic condition associated with each observed outcome instead of applying one remedy to deferrals, rejections, and spam placement.

Next 7 days

• Maintain separate operational cohorts for accepted placement, temporary failure, and permanent rejection so mixed Gmail symptoms remain visible.

Technical checks

Verification criteria

• Delivery Errors shows the incident's temporary-failure or rejection reason declining relative to its incident baseline for the affected authenticated traffic.
• Mailbox samples show the expected placement while the matching IP and domain reputation context is stable or improving; Spam Rate is not used as sole proof.

Escalation criteria

• Escalate to the ESP or a deliverability specialist when permanent Gmail responses persist, Delivery Errors confirms continuing failures, or poor reputation remains associated with spam placement or rejection.

Prevention

• Keep response-aware backoff and separate telemetry for temporary failures, permanent rejections, and mailbox placement.

Business impact

• Permanent Gmail 5xx outcomes prevent the affected deliveries, while poor reputation can contribute to spam placement or rejection and reduce customer reach.

Provider notes

• Gmail Spam Rate excludes messages that Gmail automatically placed in spam, so it cannot establish inbox placement on its own.

Open questions

• No Gmail SMTP response sample, delivery-event cohort, or inbox-versus-spam placement evidence was provided.
• The current symptom is unresolved until Gmail outcomes are separated into accepted placement, temporary deferral, and permanent rejection.
• The affected domains, sending streams, time window, message volume, and business impact are not available.

First 15 minutes

1. Collect the complete NDR or SMTP response for every sender reported as unable to deliver.
2. If the message was accepted into Junk, mark it Not junk, remove an accidental block, and add the legitimate sender to Safe senders.
3. Check the recipient's Blocked senders list and Inbox rules for sender-specific handling.

Now

• For mail already in Junk, use Not junk, remove accidental blocks, and add the verified sender to Safe senders.

Next 24 hours

• Correct recipient Blocked senders entries or Inbox rules that move accepted messages away from the inbox.

Next 7 days

• Document the sender-specific Not junk, Safe senders, Blocked senders, and Inbox-rule corrections applied to accepted messages.

Technical checks

Verification criteria

• A previously rejected sender completes a new delivery after the NDR-specific cause is corrected, without the same failure response.
• For an accepted message, the recipient can move it from Junk and subsequent verified sender messages follow the corrected Safe senders or rule configuration.

Escalation criteria

• Escalate unresolved consumer-domain delivery trouble to Outlook.com sender support only after collecting complete failure evidence and checking Microsoft policy guidance.

Prevention

• Track sender-specific Outlook.com outcomes so different filtering results are not mistaken for one recipient-wide cause.
• Keep recipient block lists and Inbox rules reviewed when one trusted sender repeatedly goes missing.

Business impact

• Messages from affected senders may fail before delivery, leaving time-sensitive customer or support communication unavailable to the Hotmail recipient.

Provider notes

• Outlook.com filtering can produce different results by sender because it considers IP, domain, authentication, list accuracy, complaints, content, and other signals.
• Microsoft's sender-support route covers Hotmail, Outlook.com, Live, and MSN consumer traffic but does not guarantee delivery.

Open questions

• The affected senders, complete NDR or SMTP responses, observed recipient folders, message samples, timestamps, and Outlook.com account controls are not provided, so rejection and misplacement cannot yet be distinguished.
• Recipient-side blocks and rules, Outlook.com filtering, sender reputation, authentication, and third-party gateway behavior can differ per sender and account.

First 15 minutes

1. Capture the Workspace dashboard state and verification time so the status observation remains explicitly time-bounded.
2. Collect the exact SMTP or ESP errors and compare them with Postmaster Delivery Errors for eligible personal-Gmail traffic.
3. Check the Gmail status entry and recent dashboard incident history before asserting a broad outage.

Now

• Separate the absence of a posted broad incident from the sender-specific failure and investigate the affected path.

Next 24 hours

• Continue support-led diagnosis and correlate sender-specific delivery errors while no broad incident is posted.

Next 7 days

• If the unlisted issue persists, open a Google Support case with tenant, region, timestamps, message identifiers, responses, and recipient scope when available.

Technical checks

Verification criteria

• If an incident is posted, Google publishes the event's final resolved update before it is treated as closed.
• Sender logs and eligible Postmaster Delivery Errors show recovery in the affected rejection or temporary-failure cohort.
• Any no-incident conclusion is labeled with the dashboard's captured verification time rather than treated as permanent.

Escalation criteria

• Contact Google Support when the issue remains reproducible but is not listed on the public dashboard, including tenant, region, timestamps, message identifiers, responses, and recipient scope when available.

Prevention

• Monitor the Workspace Status Dashboard through RSS or JSON History so broad incident changes are detected without depending on Gmail-delivered alerts.

Business impact

• A localized or sender-specific Gmail issue can still interrupt the affected customer mail path even when the public dashboard shows no broad incident.

Provider notes

• The 2026-07-17 no-incident result is a point-in-time public-dashboard observation, not proof that every Gmail delivery path was healthy.
• Postmaster Delivery Errors is delayed and aggregated and covers eligible authenticated traffic to personal Gmail accounts, not every Workspace recipient.

Open questions

• The full Gmail failure evidence, affected recipient type, tenant, region, timeframe, SMTP response, message samples, and sender-side delivery-error trend are not provided, so the incident-specific cause remains unknown.
• The status result is a time-bounded snapshot of posted broad Workspace incidents; unposted, localized, account-specific, or sender-specific failures remain possible and need separate evidence.