A 550 permanent failure means the receiving server will not accept this specific message as sent, and resending it unchanged will not help. RFC 3463 defines a permanent failure as one "not likely to be resolved by resending the message in the current form." It says nothing about whether the underlying problem can be fixed.
That distinction gets lost constantly. "Permanent" reads like "unfixable," and senders stop investigating exactly where the real diagnosis starts.
550 is the base SMTP reply code, defined in RFC 5321 as "Requested action not taken: mailbox unavailable... or command rejected for policy reasons." That single code covers a genuinely dead address, a policy rejection tied to your authentication or reputation, and other distinct permanent refusals. The enhanced status code that follows it (5.1.1, 5.7.1, and others) is what actually names which one you have.
A permanent failure closes off one path, resending the identical message, without closing off every path. Fixing the address, correcting an authentication record, or resolving a reputation issue all change what happens on the next attempt, even though the original bounce itself never becomes deliverable. 550 5.7.1 is the enhanced code I see cause this confusion most, since it reads as final and is usually the most fixable of the three.
Not by resending the identical message. RFC 3463 defines a permanent failure as one not likely to be resolved by resending in the current form, so the message itself needs to change, or the underlying cause needs to be fixed first.
No. 550 is the base SMTP code for several distinct enhanced status codes, covering a bad address, a policy rejection, and other permanent refusals. The enhanced code after the 550 is what actually names the cause.
The specific bounce will not, since it is tied to the message you already sent. But the underlying cause, a reputation state or a policy decision, can change, which is why the same address or domain can accept a later message once the real cause is fixed.