SMTP error 450 4.7.1: recipient-side temporary policy throttle

SMTP error 450 4.7.1, with text like "Recipient address rejected: Access denied," is a

temporary policy throttle applied by the recipient's own mail system. This is the mirror

image of 451 4.7.1: that code (already covered as a dedicated diagnose page) is almost always

your own outbound host rate-limiting you before the message even leaves your infrastructure.

450 4.7.1 is the receiving side independently deciding to temporarily restrict delivery from

your sending IP or domain, based on its own policy evaluation.

Fault: split, but mostly about your standing with this specific receiver - not a technical

misconfiguration, but a reputation or volume signal this one receiving system is reacting to.

Why it happens

• A new or recently warmed sending IP is still inside a receiver's probationary window.

Several large and mid-sized receivers apply temporary, graduated restrictions to unfamiliar

sending sources regardless of authentication correctness, lifting them as a sending history

accumulates.

• **A volume spike from your sending IP exceeds what this specific receiver's policy currently

tolerates for your standing**, even if your authentication (SPF/DKIM/DMARC) is entirely correct.

• A prior pattern of complaints or low engagement from recipients at this specific domain

caused the receiver to apply a targeted, temporary throttle to your IP or domain, separate from

any public blocklist.

• Shared IP reputation - if you send from infrastructure shared with other senders, their

behaviour toward this specific receiver can produce a throttle that applies to you as well.

Each of these causes is evaluated independently per receiving domain, which is why the same

sending IP can be throttled by one provider while sending cleanly to every other one at the same

time. A single receiver's cautious policy is not evidence of a broader reputation problem on your

part; it is that one receiver's own risk tolerance for your current standing with them

specifically.

The transcript

$ swaks --to test@mailpilots.in --server mx.example.net --from sender@yourdomain.com
-> MAIL FROM:<sender@yourdomain.com>
<- 250 2.1.0 OK
-> RCPT TO:<test@mailpilots.in>
<- 450 4.7.1 Recipient address rejected: Access denied, see
    https://example.net/postmaster/throttle

How the big three word it

Diagnose it

As the sender, confirm the pattern is specific to this one receiving domain, not systemic:

$ grep "RCPT TO.*mailpilots.in\|4.7.1" /var/log/mail.log | tail -10

If 4.7.1 only appears for this one destination domain while other destinations accept your

mail normally, the throttle is specific to your standing with that receiver, not a general

reputation collapse.

The fix, in order

1. Reduce the sending rate specifically to this receiving domain, even if your overall volume

is comfortable elsewhere - treat each receiver's tolerance independently.

1. Confirm SPF, DKIM, and DMARC are all correctly aligned for this sending source, since a

clean authentication record is often what shortens a probationary throttle window.

1. Warm the sending IP or domain gradually against this specific receiver rather than

resuming full volume immediately once the throttle appears to lift.

1. Check for a postmaster or support contact specific to the receiving domain if the throttle

persists well beyond what a normal warm-up period would suggest.

1. Monitor whether the throttle correlates with a specific sending pattern (a particular

campaign, a particular list segment) you can adjust, rather than assuming it is purely about

volume.

What not to do

• Do not confuse this with `451 4.7.1`. That one is your own outbound infrastructure

rate-limiting you before the message leaves; this one is the recipient's system throttling you

after it arrives. The fix for one does nothing for the other.

• Do not increase sending volume to "push through" the throttle. That is the opposite of what

this condition is asking for and will likely extend the restriction.

• Do not rotate to a different sending IP to bypass it. A fresh IP starts with no history at

all against this receiver, which is frequently a worse position than a known IP currently

inside a probationary window.

• Do not suppress affected recipients. The restriction is about your sending source, not

about whether their addresses are valid.

MailPilot's gradual warm-up schedules and per-provider inbox placement tracking are built exactly

for this condition: ramping volume against a specific receiver slowly enough that a probationary

throttle like this one is far less likely to trigger in the first place.