“Gmail blocked us” is a starting observation. You need the actual response before deciding what to fix.

Collect the full SMTP reply, timestamp, sending IP, authentication domain and affected message type. An ESP's short label such as blocked or bounced can hide the detail that identifies the cause.

Distinguish temporary and permanent failures

A temporary failure generally leaves the sending system an opportunity to retry. A permanent failure means that delivery attempt was rejected. Neither category identifies the cause on its own.

An invalid recipient, a failing DKIM signature and a restriction on sending volume should not receive the same response.

Use the code together with its text

4.7.23 points to missing or inconsistent PTR and forward DNS. Ask the sending infrastructure owner to check both directions.

4.7.27 points to SPF failure. Inspect the envelope domain and authorised sender configuration.

4.7.29 points to the lack of TLS. Ask the sending provider to check the SMTP connection.

4.7.30 points to DKIM failure. Inspect signing and the published key for the actual selector.

4.7.32 points to alignment of the From domain with SPF or DKIM.

4.7.28 has multiple variants. Read whether Gmail names an unusual sending rate, an IP, a DKIM domain, an SPF domain, a URL domain or another specific issue. Do not reduce every variant to a complaint spike.

Compare with the dashboard

Postmaster Tools reports failures within its authenticated traffic dataset. Your sending logs and Google's aggregate data can differ, including because of forwarding or replay activity. Preserve that uncertainty when the totals do not match.

Use the logs to identify the affected route and the dashboard to examine the wider pattern. A technical failure needs a technical fix. A sending-rate restriction needs appropriate pacing and retry handling as well as investigation of the trigger.

Send a useful escalation

Provide a few representative responses and messages rather than a vague report that everything is broken. Include the first affected date, the scale of the issue, recent changes and what you have already verified.

Ask a concrete question: which identity is being restricted, which requirement failed, or which route needs correction? That gives the provider something it can investigate.

Sources