Guides · Deliverability

Diagnosing an SMTP deferral (4.7.0)

A deferral is a temporary delivery failure — the receiver didn't reject your mail, it asked you to try again later. 4.7.0 is one of the most common, and it usually means a policy or reputation issue. Here's how to read it and what to do.

Temporary vs permanent

SMTP results come with a reply code and an enhanced status code (class.subject.detail, per RFC 3463). The first digit is what matters most:

  • 4.x.x (and 4yy reply codes) — a temporary failure. The message is valid but couldn't be delivered right now; retrying later may succeed. This is a deferral.
  • 5.x.x (and 5yy) — a permanent failure (a hard bounce). Retrying won't help.

BlacklistGuard automatically retries deferred messages over time, so a deferral isn't a lost message — it's a delay. But sustained deferrals mean something needs fixing.

What 4.7.0 means

In RFC 3463, the x.7.x subject is the security/policy class, and 4.7.0 is "other or undefined security status" — a deliberately vague code receivers use when something about your sending triggered a policy block but they don't want to spell out exactly why. In practice, a 4.7.0 deferral almost always points to reputation or rate. For example, Yahoo returns 421 4.7.0 [TS01] ... unusual traffic patterns from your server when it's rate-limiting an IP.

Common causes

  • A new or cold IP. Providers rate-limit IPs they don't recognize. Deferrals during IP warm-up are normal — keep the ramp gentle and they ease off.
  • Sending too fast. A burst to one provider trips rate limits. Add throttles to pace it.
  • Reputation slipping. Rising complaints or bounces lower your standing and invite deferrals. Check your complaint rate and list hygiene.
  • Authentication gaps. Missing or misaligned SPF/DKIM/DMARC can trigger policy deferrals.

How to diagnose it on BlacklistGuard

  1. Open Messages in the console (or the messages API) and find the affected messages — each row shows the status, the SMTP result code, and the full error_message the receiver returned.
  2. Read the receiver's text — it often includes a code like [TS01] or a link to the provider's postmaster page explaining the specific reason.
  3. Check whether it's one provider or many. One provider usually means a reputation/rate issue with that provider; many at once points to something on your side (authentication, a bad send, a cold IP).
  4. Look at the trend on the Deliverability report — are deferrals rising with volume or complaints?

What to do

  • If it's a cold IP or a burst: slow down — tighten throttles and let the IP warm. The deferrals are the provider asking you to pace yourself.
  • If complaints/bounces are up: clean your list, validate risky addresses, and suppress complainers.
  • If it names a reason: follow the link in the error to the provider's postmaster guidance — many include a form to request a review of your IP.

Reference