How to fix 554 5.7.1 relay access denied starts with which server said it. A server was asked to pass your message to a domain it does not handle, did not know who was asking, and refused. Usually it is your own outgoing server, because your mail app or device did not sign in; less often the recipient's MX record points at a server that does not accept their domain.
How to read the result
Paste the error your mail app showed, or the whole bounce. The decoder reads the words: "Relay access denied" is the standard reply, "Unable to relay" is Microsoft 365's, and "Email relay denied" is Google Workspace's.
Then note where it appeared. An error the moment you send means your own server refused, and the fix is yours. A bounce email that names a remote server means the recipient's side refused, and the fix is their admin's. If Microsoft's 5.7.367 sits before an arrow, read the 550 5.7.367 page instead.
How to fix it, side by side
Your mail app. Turn on sign-in for the outgoing server (SMTP AUTH) with your mailbox's username and password.
A website form, printer, or app. Give the device its own sign-in, or have your admin trust its network. On Google Workspace, the admin adds the device's IP address in the SMTP relay settings.
Your own Postfix server. The refusal comes from reject_unauth_destination. Postfix's default smtpd_relay_restrictions let signed-in users and trusted networks through, so look for the reject rule someone added.
Outside senders writing to your domain. Make the server your MX record points at accept your domain, or point the MX at the server that does.
A Microsoft 365 "Unable to relay". The admin checks the MX record and the accepted domains.
What to do next
Send one test to an outside address from the same app or device. If it goes through, resend what bounced: the recipients were never refused, only the path.
Sequences sent from Oneprofile skip this setup. A mailbox connects through Google's own sign-in and sends through Gmail, with no outgoing server or SMTP password to set.