// how to fix
"554 5.7.1 Relay access denied" when sending
Your mail server refuses to pass your email on because you are not logged in. Usually a missing SMTP login or the wrong port in your app or printer.
What it means
When you send an email, you get an error like:
554 5.7.1 <someone@example.com>: Relay access denied
"Relay" means passing an email on to another domain. A mail server only does this for people it trusts, usually users who have logged in with a username and password. If the server does not know who you are, it refuses, so it does not become an "open relay" that spammers could abuse.
In short: the server you are sending through does not recognise you as one of its users.
Why it matters
- Your email is not sent at all.
- It often appears after setting up a new mail app, a website plugin, a printer or scanner, or after changing password or provider.
- The error is a good sign about the server: it is protecting itself. Do not "fix" it by opening the server to everyone.
How to check
- Look at your outgoing (SMTP) settings in the app, plugin or device that shows the error.
- Test another recipient: if emails to your own domain work but emails to other domains fail, it is a relay problem, not a problem with the recipient.
- Once sending works, send a test email to the address on the Delivmail home page
/to check SPF, DKIM and DMARC.
How to fix it
- Turn on SMTP authentication. In the outgoing server settings, enable "My outgoing server requires authentication" and enter the full email address and password.
- Use the right port and encryption. Usually port
587with STARTTLS, or465with SSL/TLS. Port25is meant for server-to-server traffic and often does not accept logins. - Use the right server name, as given by your provider: for example
smtp.gmail.comfor Google Workspace orsmtp.office365.comfor Microsoft 365. - Check the password. If the account uses two-step verification, some providers require an app password instead of the normal one.
- Check the From address. Many servers refuse to send for a domain that is not yours. Send from an address on the account you log in with.
If you run the mail server
Allow relaying only for authenticated users and for trusted internal IP addresses. In Postfix this is done with smtpd_relay_restrictions, for example:
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
Never add the whole internet to mynetworks.
Check that it is fixed
Send an email to an outside address, such as a Gmail address you own: it should leave without error. Then send a test email to the address on the home page and open the report to confirm the email is authenticated and not blacklisted.
Check that it is fixed
DNS changes can take from a few minutes to a few hours. Then send a new test email or scan your domain again.
Related guides
- Move DMARC from p=none to quarantine or reject safelyp=none only watches. To really stop fake emails using your domain, move step by step to quarantine and reject, without blocking your own emails.
- Your sending IP address is on a blacklistA blacklist is a public list of IP addresses known for sending spam. Find out if the IP is yours, fix the cause, then ask for removal.
- Your domain is on a blacklist (Spamhaus DBL, SURBL, URIBL)Domain blacklists list domain names seen in spam. They follow your domain wherever you send from. Find the cause, clean up, then request removal.
- Gmail bounce "550 5.7.26": unauthenticated emailGmail refused your email because it could not confirm it comes from your domain. SPF, DKIM or DMARC is missing or failing. Here is how to fix it.
- Bounce "550 5.7.1": message rejected or blocked by policyA 5.7.1 bounce means the receiving server refused your email on purpose. Learn to read bounce messages, find the real reason and fix it.