SMTP 450 4.7.0: temporarily denied by receiving-server policy

450 4.7.0 is a temporary failure in the policy family of enhanced status codes. RFC 3463's 4.7.x range covers security and policy status - unlike 4.1.x (address) or 4.2.x (mailbox) or 4.3.x (mail system resources), a 4.7.0 specifically signals that the receiving server's own anti-abuse or reputation policy is the reason for the deferral, even though it is choosing not to block outright (a 5xx) yet.

Who is at fault

This sits with the sender's reputation or sending pattern, even though it is a deferral rather than a block. Common triggers: a sending IP or domain with thin history (classic cold-sending), a recent spike in volume to that domain, a recent authentication misconfiguration, or a temporary appearance on a reputation list the receiving server consults. It is also worth checking whether the deferral coincides with a change to your own sending

infrastructure - a new IP address, a newly added sending domain, or a recently rotated DKIM key.

Receiving systems that apply policy-based deferrals often weight recent changes to a sender's

infrastructure more heavily than established history, on the theory that a sudden configuration

change is exactly the kind of event that precedes both legitimate scaling and genuine abuse, and

they cannot yet tell which one they are looking at from your side alone.

The exchange

220 mx.example.com ESMTP
EHLO mail.yourdomain.com
250-mx.example.com
250 SIZE 26214400
MAIL FROM:<sender@yourdomain.com>
250 2.1.0 OK
RCPT TO:<recipient@example.com>
450 4.7.0 Temporary access denied by recipient's policy

How Gmail, Microsoft 365 and Yahoo word the same condition

All three word this as explicitly reputation-driven, which confirms the general character of 4.7.0: a policy decision based on sender history, not a one-off technical fault.

Diagnostic commands

Check your sending IP and domain's standing, and whether volume to this domain spiked recently:

$ dig +short TXT yourdomain.com | grep spf
"v=spf1 include:_spf.google.com -all"

$ swaks --to recipient@example.com --from sender@yourdomain.com --server mx.example.com
<~  450 4.7.0 Temporary access denied by recipient's policy

$ mxtoolbox.com blacklist lookup (web) -- confirm your sending IP is not freshly listed

A clean SPF/DKIM/DMARC alignment combined with a recent, unusually large send to this domain points squarely at a volume-triggered policy deferral rather than an authentication gap.

The ordered fix

1. Confirm SPF, DKIM and DMARC are correctly aligned for the sending domain - a policy deferral is more aggressive against unauthenticated or marginally authenticated mail.
2. Reduce sending volume and rate to the affected domain for the next 24-48 hours rather than retrying at the same pace.
3. Check whether your IP or domain appears on any reputation list the receiving provider might consult.
4. Let the queue retry on a normal backoff - most 4.7.x deferrals clear within a day once volume and authentication look normal again.
5. If sending from a new domain or IP, ramp volume gradually over subsequent days rather than resuming at full rate immediately after the deferral clears.

What not to do

• Do not retry at the same or higher volume immediately. That is the opposite of what a 4.7.0 is asking for and risks escalating to an outright 5xx block.
• Do not ignore authentication gaps because "it's just a deferral." 4.7.x codes specifically respond to sender trust signals, and fixing SPF/DKIM/DMARC now prevents escalation later.
• Do not switch sending infrastructure (new IP, new domain) as a quick fix. New infrastructure starts with zero reputation, which is often worse than a temporarily deferred established one.
• Do not treat this the same as a resource-based 452. The fix for 4.7.0 is about your sending behaviour and authentication, not about the receiving server's disk space.

Reading the deferral as a leading indicator, not just an obstacle

A policy-based 450 4.7.0 that clears after you reduce volume and confirm authentication is itself

useful information: it confirms the receiving server is actively evaluating your sending pattern

in something close to real time, rather than relying on a static reputation score that only updates

occasionally. That means the same signals you just corrected - rate, authentication alignment - are

likely to keep mattering for that domain going forward, and keeping them steady is more valuable

than treating this one deferral as a closed, one-off incident.

MailPilot's warm-up process exists specifically for this condition: it builds sending history and reputation gradually on new mailboxes and domains, which is the direct countermeasure to policy-based deferrals like 450 4.7.0 that are triggered by thin or erratic sending history.