4.7.0 SMTP bounce: security status

What 4.7.0 means

A temporary security check on the receiving side did not pass. The sender should retry later.

Message text

Other or undefined security status

Common causes of 4.7.0

• Temporary security or policy check on the receiving side

How to fix 4.7.0

1. Retry later.
2. If it repeats, check your sending IP with blocklist check and your authentication with SPF checker and DMARC checker.

Check your domain

Check the SPF record of your sending domainRuns in your browser; nothing is uploaded.

Have the full bounce message? Paste it into the bounce code lookup and it will match the code and the provider for you. Open the bounce code lookup.

How to read 4.7.0

The second part, 4.7.0, is an enhanced status code (RFC 3463 §2) written class.subject.detail. Class 4 is a Persistent transient failure (4xx): the command was not accepted, but the condition may clear, so the sender should try again later (RFC 5321 §4.2.1; RFC 3463 §2).. Subject 7 is security or policy: authentication, authorization or policy refused the message. The detail number refines the subject, and providers may define details of their own, which is why one code can read differently at Gmail, Microsoft and Yahoo.

Sending servers should retry a deferred message. RFC 5321 §4.5.4.1 advises waiting at least 30 minutes between attempts and trying for at least 4 to 5 days before giving up and returning a bounce. If the deferral keeps repeating, fix the cause rather than waiting.

Official source: www.rfc-editor.org. Last verified 2026-10-20.

Related guides

• How to create an SPF record (syntax and examples)
• How DKIM works and how to publish a DKIM record
• How to set up a DMARC record, from p=none to p=reject

Related codes

• 421 4.7.0 Gmail: no PTR record
• 451 4.7.23 Gmail: PTR record missing
• 421 4.7.28 Gmail: rate limited
• 421 SMTP: service not available
• 450 SMTP: mailbox unavailable
• 451 SMTP: local processing error

FAQ

All bounce codes