Hard bounce and soft bounce

Permanent and temporary delivery failures

A bounce tells the sender that an attempted delivery failed. Sending systems commonly use “hard bounce” for a permanent failure and “soft bounce” for a temporary one. RFC 5321 defines a 4xx reply as a temporary command failure. A 5xx reply means the same request, repeated unchanged, is not expected to succeed.

A busy server or greylisting can cause a temporary refusal. A missing mailbox can cause a permanent refusal, but so can a sender policy restriction. The reply class cannot establish the cause or show that delivery will remain impossible forever.

What happens when retries end

A sending system may queue a message and retry after a temporary problem. If it gives up before the problem clears, the delivery has failed. The cause can still be temporary: RFC 3464 permits a final failed delivery notification with a 4.x.x status. Exhausting retries does not turn the error into a 5.x.x error.

Reading a verification result

Emvero sends no verification email and stops before the message-content stage. It reports evidence from a check, without attempting message delivery. A later email may encounter different sender, content or policy conditions.

Under the current policy, a negative SMTP reply does not necessarily produce undeliverable. An observation classified as SMTP_MAILBOX_NOT_FOUND becomes unknown with SMTP_RECIPIENT_REJECTED_AMBIGUOUS. Disabled-mailbox and other mailbox-status observations can produce risky. Deterministic syntax or domain failures can establish undeliverability; temporary SMTP failures leave the answer unresolved.

Read the recommended action and reasons in the verification result before applying your sending rule. Consider address attributes separately. A role account, for example, does not predict a bounce merely because it uses a function name.