Bounces, Rejections and Throttling

First 15 minutes

1. Preserve the complete NDR and split Outlook.com consumer recipients from Exchange Online or Microsoft 365 recipients.
2. Group failures by recipient service, enhanced status code, complete diagnostic, sending IP, domain, and time window.

Now

• Stop unchanged retries for permanent failures and select remediation from the complete diagnostic.

Next 24 hours

• If Exchange Online reports Delivery not authorized, correct the recipient restriction or transport rule identified by the NDR.
• If RESOLVER.RST.AuthRequired targets a mail-enabled public folder, correct the external-sender configuration for that recipient.

Next 7 days

• For Outlook.com consumer failures, remediate the specific returned diagnostic using current IP, domain, authentication, list, complaint, and content evidence.

Technical checks

Verification criteria

• After changing the diagnosed condition, a controlled message to the same recipient-service cohort no longer returns the same permanent NDR; do not count an unchanged resend as verification.

Escalation criteria

• Escalate RESOLVER.RST.AuthRequired to the Exchange administrator for the affected public folder, or escalate an Outlook.com case with its complete diagnostic and current sender evidence.

Prevention

• Retain complete Microsoft diagnostics and monitor failures separately for Outlook.com consumer service and Exchange Online tenant policy.

Business impact

• Affected messages remain permanently failed unless the message or destination condition changes; resending them unchanged is unlikely to work.

Provider notes

• Exchange Online 5.7.1 Delivery not authorized can indicate recipient restrictions or transport-rule rejection, while RESOLVER.RST.AuthRequired can identify a public folder rejecting external senders.

Open questions

• The complete NDR text, enhanced subcode, rejecting hostname, affected recipient service, sending IP and domain, and time distribution are not supplied.
• Outlook.com consumer filtering and Exchange Online tenant policy are different Microsoft scopes and cannot be diagnosed as one provider behavior.

First 15 minutes

1. Preserve complete Gmail SMTP replies and group them by rate-limit, authentication, DNS, policy, and message-format diagnostics.
2. Identify whether 421 4.7.28 is scoped to an IP, SPF domain, or DKIM domain from the exact diagnostic.
3. Compare raw ESP logs with the delayed Postmaster Tools Delivery Errors dashboard without treating missing low-volume data as current proof.

Now

• Reduce affected Gmail volume while SMTP errors are elevated and stop unchanged retries for permanent 5xx failures.

Next 24 hours

• Correct the SPF, DKIM, or DMARC condition identified by a 550 5.7.26 diagnostic, or the PTR and forward-DNS condition identified by 550 5.7.25.

Next 7 days

• Increase Gmail volume slowly only after the SMTP error rate falls, inspecting individual messages if errors continue at low volume.

Technical checks

Verification criteria

• Raw Gmail SMTP error rates fall before volume is increased, and any continued errors at low volume are inspected message by message.
• The delayed Postmaster Tools Delivery Errors view later corroborates rejected and temporarily failed authenticated traffic when volume is sufficient for data.

Escalation criteria

• Escalate to the ESP or deliverability owner when complete Gmail diagnostics remain unclassified or conflict with authenticated-traffic delivery-error data.

Prevention

• Maintain valid PTR and matching forward DNS for every Gmail sending IP.
• Use controlled volume changes and reduce traffic promptly when Gmail bounces or deferrals rise.

Business impact

• Affected Gmail traffic can be temporarily rate-limited for unusual unsolicited volume or permanently rejected for authentication, DMARC, policy, reputation, or message-format conditions.

Open questions

• No raw SMTP replies, code distribution, affected IP or domain split, send-volume change, authentication result, or recipient cohort was supplied.
• Postmaster Tools may lag or omit low-volume data, so its dashboard alone cannot establish the current bounce cause.
• The current frozen Gmail FAQ source documents temporary 4.7.32, not the claimed permanent 5.7.32 alignment code, so the combined claim is not fully supported.

First 15 minutes

1. Preserve the rejecting hostname, complete enhanced reply, affected recipients, sending IP and domain, message identifiers, and timestamp.
2. Confirm that the enhanced code is 5.7.1 and use the provider's complete diagnostic to narrow the policy or authorization cause.

Now

• Stop unchanged retries because a permanent class-5 failure requires a change to the message or destination condition.

Next 24 hours

• For Gmail, correct the specific recipient-policy, unsolicited-mail, reputation, or malformed-header condition named in the full diagnostic; for Exchange Online, correct the recipient authorization or transport rule identified in the NDR.

Next 7 days

• Maintain separate Gmail and Exchange Online remediation branches because the same 5.7.1 code represents different provider conditions.

Technical checks

Verification criteria

• After correcting the specific condition, a non-abusive controlled message produces a new SMTP result before normal volume resumes, and the unchanged rejected traffic is not repeatedly retried.

Escalation criteria

• Escalate an Exchange Online case to the recipient tenant administrator when the NDR identifies authorization or a transport rule; send other provider support the preserved hostname, full reply, recipients, sending identity, message IDs, and timestamp.

Prevention

• Retain complete provider diagnostics, block automatic unchanged retries for permanent failures, and require a controlled successful SMTP result before restoring normal volume.

Business impact

• Affected messages remain undelivered until the message or destination condition changes; resending them unchanged is unlikely to succeed.

Provider notes

• Gmail and Exchange Online both use 5.7.1 for multiple distinct conditions, so their complete diagnostic text and NDR context determine remediation.

Open questions

• The rejecting provider, complete SMTP diagnostic, affected recipients, sending IP and domain, message sample, and time window are unavailable.
• The same 550 5.7.1 code maps to different provider and tenant policy conditions; remediation cannot be universal.

First 15 minutes

1. Preserve the complete NDR, enhanced subcode, remote response, recipient type, and generating server.
2. Stop repeating the exact rejected SMTP request unchanged.
3. If sender-side addressing and authentication do not explain the NDR, provide the minimum necessary evidence to the recipient's Exchange administrator through an approved channel.

Now

• After sender-side addressing and authentication checks, escalate unexplained cases to the recipient's Exchange administrator with the complete NDR.

Next 24 hours

• If a recipient-side mail flow rule is confirmed, have that organization review or modify the rule when the sender should be allowed.

Next 7 days

• For a confirmed AuthRequired public-folder case, have the recipient organization correct the delivery-management setting if external mail should be accepted.

Technical checks

Verification criteria

• After the documented cause is corrected, verify that a new command sequence is accepted instead of returning the same complete 5.7.1 NDR.
• For a rule or public-folder cause, confirm the recipient-side configuration now permits the intended sender and recipient type.

Escalation criteria

• Escalate unexplained cases to the recipient's Exchange administrator with the complete NDR because external senders cannot inspect the tenant's rules, permissions, connectors, and recipient restrictions.

Prevention

• Retain complete NDR fields so later 5.7.1 incidents can be routed by their exact cause rather than the bare code.
• Review mail flow rules that reject intended senders and keep their allowed-sender conditions current.

Business impact

• Affected messages were not accepted, which can block the business process that depended on those recipients receiving the mail.

Provider notes

• Microsoft documents several causes across the Exchange Online 5.7.x family; on-premises Exchange and third-party gateways can use different text for the same numeric code.
• A mail-enabled public folder can return 550 5.7.1 AuthRequired when it is configured to require authenticated senders.

Open questions

• The full NDR, enhanced subcode, remote-server response, generating server, recipient type, and Exchange topology are not provided, so the exact 5.7.1 cause is unknown.
• Exchange Online, on-premises Exchange, hybrid connectors, and third-party gateways can attach different meanings and fixes to a bare 550 5.7.1 response.

First 15 minutes

1. Capture the Deferred Event reason, including the receiving server's SMTP response code and explanation.
2. Calculate end-to-end delivery time from processed and delivered timestamps for completed messages and keep undelivered delay open-ended.
3. For 421 or 450 rate or connection limits, temporarily reduce volume to the affected recipient domain.

Now

• Let SendGrid's normal deferred queue retry the temporary inbox-provider failure while preserving the event history.

Next 24 hours

• If the exact reason is a 421 or 450 rate or connection limit, temporarily reduce volume to that recipient domain.

Next 7 days

• Keep domain-level sending rates aligned with the receiving provider's observed capacity before returning to normal volume.

Technical checks

Verification criteria

• Verify that deferred events progress to delivered and that end-to-end delivery time returns to the sender's baseline.
• Confirm that messages do not remain deferred through the full 72-hour retry period and change to blocked.

Escalation criteria

• Escalate to SendGrid when messages approach the end of the 72-hour retry lifecycle or the exact response behaves contrary to its documented temporary or permanent class.

Prevention

• Retain Deferred Event reasons and processed and delivered timestamps so each incident can be scoped by response and end-to-end delay.
• For domains that return rate or connection limits, reduce the affected stream rather than continuing at the same rate.

Business impact

• Sustained deferrals delay time-sensitive mail, and a message still deferred throughout SendGrid's 72-hour retry period changes to blocked.

Provider notes

• SendGrid retries inbox-provider deferrals with exponential backoff for up to 72 hours.
• A message still deferred throughout that period changes to blocked.

Open questions

• The exact SMTP response, recipient domain, affected message count, processed and delivered timestamps, SendGrid IP, and current retry age are not provided.
• Receiving-provider throttling causes and retry expectations vary; SendGrid's 72-hour lifecycle must not be generalized to another ESP.

First 15 minutes

1. Capture the three-digit reply, enhanced status code, response text, SMTP stage, recipient, and attempt history.
2. Route 421 and 451 temporary responses to the retry queue and classify documented 550 responses as rejected.

Now

• Queue Gmail 4xx responses for bounded retry and hold identical 5xx retries until the documented cause is corrected.

Next 24 hours

• Review retry routing so the leading reply class controls whether a message is retried or held for correction.

Next 7 days

• Encode the full provider text and enhanced status code in operational queues so corrective action and retry timing remain cause-specific.

Technical checks

Verification criteria

• Representative 421 and 451 responses are retained as temporary failures and routed to retry.
• Representative documented 550 responses are recorded as rejected rather than deferred.

Escalation criteria

• Escalate to the ESP or deliverability owner when documented temporary Gmail replies persist across bounded retries or a 550 cause cannot be identified from the full response.

Prevention

• Preserve the complete SMTP response and enforce class-based retry routing for every Gmail delivery attempt.

Business impact

• Temporary 421 or 451 replies delay delivery, while documented 550 recipient or policy responses reject the message and can prevent it from reaching the recipient.

Provider notes

• Gmail documents 421 4.3.0 and 451 4.3.0 as temporary, while 550 5.1.1 and listed 550 5.7.1 cases are rejections.

Open questions

• The exact three-digit reply, enhanced status code, response text, SMTP stage, recipient count, and attempt history are not supplied.
• Retry timing for a 4xx response depends on the specific Gmail text, Retry-After or queue policy, and repeated-attempt history; no universal delay is established here.
• A 5xx response can become deliverable after a corrective change, but repeating the identical request without fixing its cause is not supported by the SMTP standard.

First 15 minutes

1. Capture before-and-after normalized bounce classes, raw SMTP responses, mailbox domains, sending IPs, authentication results, and traffic volume.
2. Reconcile the new platform with the prior provider suppression state, including provider- and region-scoped behavior.

Now

• Reduce affected Gmail-bound volume and inspect individual failures if the problem persists at low volume.

Next 24 hours

• Correct missing SPF authorization and import required bounce, complaint, and invalid-address suppression state into the deployed provider.

Next 7 days

• Ramp the modified traffic segment separately rather than moving full volume after the infrastructure change.

Technical checks

Verification criteria

• The Gmail SMTP error rate falls at reduced volume before traffic is increased slowly.
• New messages pass the corrected sender authorization and keep invalid-recipient suppressions active in the deployed provider.

Escalation criteria

• Escalate to the ESP or mailbox-provider deliverability channel when failures persist at low volume after raw codes, authentication, IP reputation, and suppression state are reconciled.

Prevention

• Stage future infrastructure changes as separate traffic segments instead of immediate full-volume migrations.
• Include authentication and suppression-state migration in the platform cutover checklist.

Business impact

• Cold-IP filtering, widespread deferrals, or invalid-recipient traffic can prevent legitimate mail from reaching recipients after migration.

Provider notes

• Amazon SES account-level suppression state is scoped to one AWS account in the current Region.
• SendGrid keeps bounce and invalid-address suppressions enabled to protect sender reputation.

Open questions

• No before/after bounce taxonomy, raw SMTP responses, sending IPs, authentication results, traffic ramp, recipient cohort, or suppression import record is supplied.
• A platform switch can expose several independent causes at once—cold IPs, authentication changes, volume changes, or provider-scoped suppression state—so no single cause should be asserted without segmented evidence.
• Bounce names and suppression behavior vary by ESP; compare normalized class, raw provider code, and mailbox domain rather than top-line rate alone.

First 15 minutes

1. Export recipient-level bounce type, subtype, enhanced status, diagnostic text, reporting MTA, and remote MTA IP.
2. Group those events by campaign, receiver domain, provider, and time to locate the change.
3. Reduce Gmail volume immediately if the cohort is bouncing or being deferred.

Now

• Suppress a recipient immediately only after the event is reliably classified as a permanent hard bounce.
• Throttle the affected Gmail traffic until its SMTP errors decrease.

Next 24 hours

• Suppress reliably classified permanent hard bounces while keeping affected Gmail volume reduced until SMTP errors decrease.

Next 7 days

• Increase Gmail volume slowly only after its SMTP error rate has decreased.

Technical checks

Verification criteria

• Recipient-level evidence identifies the affected bounce class and cohort instead of leaving only an aggregate percentage.
• The Gmail SMTP error rate decreases at reduced volume and remains controlled as volume is increased slowly.

Escalation criteria

• Escalate to the ESP or deliverability owner when recipient-level diagnostic fields cannot be obtained or grouped reliably.
• Escalate persistent Gmail failures for message-level review when they continue even at low volume.

Prevention

• Automatically suppress recipients after a reliably classified permanent hard bounce.
• Use explicit opt-in, confirm addresses, review continued interest, and consider removing unengaged Gmail subscribers.

Business impact

• Affected recipients may miss transactional, operational, or marketing messages; measure impact by failed recipient attempts and message purpose rather than an assumed revenue number.

Provider notes

• Gmail recommends reducing volume until SMTP errors decrease and then increasing slowly; other receivers can require different controls.

Open questions

• The rate denominator, event definition, affected message streams, receiver domains, and comparison baseline were not provided; nearly 25% cannot be interpreted reliably without them.
• The root cause is unresolved until recipient-level bounce types, enhanced status codes, diagnostic text, and provider cohorts are examined.
• Bounce labels, retry behavior, and rate calculations vary by ESP and mailbox provider.

First 15 minutes

1. Capture the complete Gmail SMTP transcript, enhanced status code, text, timestamp, and the response after the DATA terminator.
2. Use the complete Gmail 550 response to classify a permanent refusal, and distinguish a remote post-DATA 2yz acceptance from a local queued status.

Now

• Keep exact 4yz messages on controlled retry and quarantine exact 5yz messages from unchanged replay.

Next 24 hours

• Correct the policy, reputation, or header condition named in the complete Gmail 550 5.7.1 response before resubmission.

Next 7 days

• Make transient-versus-permanent SMTP classification and the complete response text part of persistent delivery-event records.

Technical checks

Verification criteria

• A controlled corrected message receives a remote 2yz completion after DATA rather than the incident's Gmail 550 5.7.1 refusal.
• Controlled samples no longer return the incident's full Gmail 550 5.7.1 response.

Escalation criteria

• Escalate to the ESP or a deliverability specialist when the full Gmail 550 5.7.1 response persists after its named condition is corrected or its cause remains ambiguous.

Prevention

• Persist the remote post-DATA response and route 4yz outcomes to controlled retry while routing 5yz outcomes to intervention.

Business impact

• A permanent Gmail refusal means the affected delivery attempt did not complete, which can prevent time-sensitive messages from reaching recipients until the cause is corrected.

Provider notes

• Gmail's documented 450 4.2.1 response is a temporary recipient-rate condition for which resend later is appropriate.
• Gmail 550 5.7.1 is not a single diagnosis; its complete response text is required to distinguish the documented refusal causes.

Open questions

• The actual SMTP transcript, enhanced status code, DSN, and timestamp for the affected delivery were not provided.
• Whether the message remains queued locally or has already received a permanent Gmail rejection is unresolved.
• The number and importance of affected messages and recipients are not available.

First 15 minutes

1. Capture the complete 550 or 553 text, the rejecting server, and the SMTP stage rather than relying on the bare code.
2. Verify that the configured outgoing SMTP server recognizes the sender's connection and authentication.
3. Compare the configured submission server and authentication with the provider-authorized values.

Now

• Use the SMTP server authorized for the current connection or configure its supported SMTP authentication.

Next 24 hours

• If the full response confirms a return-address restriction, change to a domain permitted by that provider.

Next 7 days

• Document the approved submission and return-address configuration so future senders do not recreate the relay failure.

Technical checks

Verification criteria

• A new test request is accepted after the authorized SMTP or authentication configuration is corrected.
• Transport evidence confirms delivery progress rather than relying on the message's presence in Sent Items.

Escalation criteria

• Contact the ISP or mail administrator when the authorized SMTP server or supported authentication cannot be configured from the available account options.

Prevention

• Provision clients with the provider-authorized submission server and supported SMTP authentication.
• Enforce the provider's permitted return-address domain where that restriction is configured.

Business impact

• A message can appear in Outlook Sent Items even though the provider rejected it and the recipient never received it.
• The unchanged request will not complete while the permanent 5yz condition remains uncorrected.

Provider notes

• Microsoft's documented relay scenario concerns an outgoing server that does not recognize the sender as authorized; bare 550 or 553 codes can represent other policies.

Open questions

• The complete error text, enhanced status code, rejecting server, failure stage, current SMTP configuration, authentication result, connection context, and mail topology are not provided, so the exact cause is unknown.
• Bare 550 or 553 codes can represent different policies across consumer Outlook, Microsoft 365, on-premises Exchange, ISPs, and third-party gateways; the full response controls the diagnosis.

First 15 minutes

1. Preserve the complete SMTP response, including the enhanced subcode and diagnostic text, for representative rejected messages.
2. Check whether the diagnostic ends in gsmtp and whether gcdp identifies a recipient-domain administrator policy.
3. Map any specific enhanced code to the matching PTR, authentication, SPF, volume, TLS, DKIM, or DMARC control.

Now

• Correct only the control identified by the complete Gmail enhanced code and diagnostic.

Next 24 hours

• Validate the applicable SPF, DKIM, DMARC, and direct-mail alignment baseline for the sender's Gmail volume class.

Next 7 days

• Audit authentication and alignment for the current sending identities so the Gmail baseline remains continuously satisfied.

Technical checks

Verification criteria

• The applicable SPF, DKIM, DMARC, and direct-mail alignment checks pass for the affected sending identity.
• Post-change test results are correlated with Postmaster Tools authentication, spam, domain-reputation, and IP-reputation signals where available.

Escalation criteria

• Escalate a gcdp rejection to the Google Workspace administrator for the recipient domain because it identifies a custom domain policy.
• If the complete Gmail diagnostic still cannot be mapped, escalate with the full response and representative affected identities rather than the bare 550 5.7.1 code.

Prevention

• Maintain Gmail's applicable authentication and From-domain alignment baseline for every sending identity.
• Monitor Postmaster Tools authentication, spam, and reputation signals alongside exact SMTP diagnostics.

Business impact

• The rejected SMTP command was not accepted and the requested delivery action did not occur.
• The same visible 5.7.1 code can represent materially different policy, authentication, reputation, header, relay, or direct-IP conditions.

Provider notes

• The gcdp marker identifies a Google Workspace administrator's custom rule; gsmtp appears on Gmail SMTP errors generally.
• Gmail publishes distinct enhanced codes for PTR, authentication, SPF, unusual volume, TLS, DKIM, and DMARC conditions.

Open questions

• The exact Gmail policy condition is unknown without the complete SMTP response, including its enhanced status subcode, diagnostic text, and gsmtp or gcdp identifier.