Relay access denied when using SMTP to external recipients POSTFIX FREEBSD

i am trying to send an email with my freebsd server using postfix and dbmail to an external adress.

I have noticed the following things:



MYSERVER -> EXTERNALSERVER = ERROR(454 4.7.1 Relay access denied)

Why do i get this error? i think it has something to do with my

queue_directory = /var/spool/postfix
command_directory = /usr/local/sbin
daemon_directory = /usr/local/libexec/postfix
data_directory = /var/db/postfix
mail_owner = postfix
default_privs = nobody
myhostname =
mydomain =
myorigin = $mydomain
inet_interfaces = all
virtual_transport = dbmail-lmtp:localhost:24
virtual_mailbox_domains =
unknown_local_recipient_reject_code = 550
mynetworks = [::1]/128
smtpd_helo_required = yes
strict_rfc821_envelopes = yes
debug_peer_level = 2
debugger_command =
     ddd $daemon_directory/$process_name $process_id & sleep 5
sendmail_path = /usr/local/sbin/sendmail
mailq_path = /usr/local/bin/mailq
setgid_group = maildrop
html_directory = /usr/local/share/doc/postfix
manpage_directory = /usr/local/man
sample_directory = /usr/local/etc/postfix
readme_directory = /usr/local/share/doc/postfix
inet_protocols = ipv4
smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks reject_unauth_destination
Asked By: Ruben Urresti


Isn’t that you haven’t authenticated properly (via your mail client) to send outbound email or otherwise haven’t setup mynetworks such that it will allow all systems within your network to send without authentication?

Answered By: dtbnguyen

mynetworks = [::1]/128

Cancel it. # Sheep per line
# mynetworks = [::1]/128

Answered By: Abdullah

I had a similar error message when I set up sendmail as in this thread. For me the problem was that I was authenticating over port 465, which is SMTP with TLS, but the protocol requires TLS to run after authentication, for example over port 25, which is SMTP without TLS.

The solution was to change the port in ~/.authinfo to

machine server.domain.tld login port 25 password XYZ

Update: I’m no SMTP expert. My answer is based on my experience and on this thread, where a comment mentioned this rebuttal about my use of port 25 for authentication:

That’s not the way SMTP AUTH works: you authenticate and send using the same port, in this case 587.

Answered By: miguelmorin

I had this problem too…
First of all, note that there are two error numbers:

  1. server side error (554)

554 4.7.1 Relay access denied

you must check your postfix (or any mail server) configs. check your /etc/postfix/ or /etc/postfix/

  1. client side error (454) (It was my problem that I solved. )

454 4.7.1 Relay access denied

The main problem I had was that I was not logged in using AUTH LOGIN.

important : If used SSL on server side (if SSL is Enabled in config), YOU MOST ENTER USERNAME AND PASSWORD AS BASE64… So, you can use any tool for convert your user & pass to base 64… I used perl in command line..

convert username to base64 example using perl:

perl -MMIME::Base64 -e 'print encode_base64("your_username");' // Without

out : eW91cl91c2VybmFtZQ++

and password base64 :

perl -MMIME::Base64 -e 'print encode_base64("your_password");'

out : eW91cl9wYXNzd29yZA==

and finally use converted base64 username and password for login… See my success output :

myUser@hostname:~$ telnet 25
Connected to
Escape character is '^]'.
220 ESMTP Postfix
334 DXFlvmthuWP0
eW91cl91c2VybmFtZQ++  -----------------> Enter username as Base64
334 UGFzc32voiG7
eW91cl9wYXNzd29yZA==  -----------------> Enter password as Base64
235 2.7.0 Authentication successful
250 2.1.0 Ok
250 2.1.5 Ok
354 End data with <CR><LF>.<CR><LF>
this mail sent by telnet               
250 2.0.0 Ok: queued as FFAD62D5D3
221 2.0.0 Bye
Connection closed by foreign host.

my converted username to Base64 was eW91cl91c2VybmFtZQ++ and my passwod to Base64 was eW91cl9wYXNzd29yZA==

Answered By: ultra.deep

Historically, SMTP connections to port 25/TCP were used by both email clients (MUAs) to send outgoing mail to their local mail server, or by mail servers (MTAs) to pass email from one mail server to another. No authentication was included as standard. This turned out to be a very bad idea.

To fix the problems caused by this, modern mail servers are usually set up to accept incoming email from clients using port 587. When using this port, authentication is usually mandatory, and TLS encryption (using STARTTLS) is highly recommended.

The port 25 is increasingly dedicated to traffic between “valid” mail servers only, and the validity of a particular mail server is mostly decided by various DNS records.

“Relay access denied” means that you’re not currently authorized to send email through the external server to any other mail server, i.e. mail relaying like


will be blocked. If the destination address of the email you’re sending matches one of the domains EXTERNALSERVER is directly responsible for, it should still be accepted, unless you’re failing other anti-spam checks.

There is a number of various anti-spam tests that other mail servers may apply to an incoming SMTP connection:

  • On connection, the connecting host needs to state the hostname it claims to be. The receiving host will perform a reverse DNS lookup for the source IP address: does the name reported by DNS match the name claimed by the connecting host? A regular forward DNS lookup is also performed: does the IP address reported by DNS for that name match the source IP address the connection is actually coming from? This is one of the oldest anti-spam tests. If you fail this test and don’t authenticate, you’ll be allowed to only send email to the email addresses the destination host is directly responsible for, not to any third parties.

  • There are also DNS SPF records which can (optionally) specify which hosts in a particular DNS domain are supposed to send email to the internet. If your domain has a SPF record (try dig TXT to see) and that record indicates your host is not supposed to be a mail server, and you’re not authenticating, the external server may reject your connection attempt completely.

  • DNS MX records are another important part of email delivery: they specify the actual hostname of the mail server(s) serving a particular domain. In order to determine where email addressed to Joe.User@domain.example should be delivered to, email servers will first look up a MX record for domain.example. You can do it yourself with a command like dig domain.example MX.
    If there are no MX records for a particular DNS domain, there is a fall-back rule: if there is a plain old DNS A record for domain.example and the host in the IP address identified by that A record listens on port 25/TCP, then any emails addressed to that domain will be sent to that IP address.
    For anti-spam checks, the MX record of the sending host may be checked: the idea is “if you don’t look like you’re prepared to receive email, you probably should not be sending it either.” Because of a large variety of mail server set-ups, this cannot be a hard and fast rule, but it is occasionally used as a small positive/negative factor in the “spam or not?” decisions.

If you are a home user or even a small business, without a static public IP address, an internet service provider may choose to treat you as a simple email client, and only allow you to send outgoing SMTP connections to the provider’s email servers only. They may require authentication at that point, or they may allow unauthenticated connection based on the physical structure of their network. In this situation, you can still have your own private mail server; it just needs to send all outgoing email through the provider’s mail servers just like a regular email client would. This is sometimes called a “smarthost” configuration, according to the name of the configuration option for it in the classic Sendmail. In modern times, using port 587 and authentication instead of classic unauthenticated port 25 is usually required.

Receiving incoming email in your own server also depends on what is allowed by your internet provider. If your connection is NATted (as home and small-business internet connections increasingly are), receiving incoming connections without opening a fixed tunnel for port 25 through the NAT will be impossible. If your IP address occasionally changes, keeping the email-relevant DNS records always up to date will be critical for the reliability of your email delivery.

Once you have a public static IP address and a DNS domain of your own, you are generally considered “big enough” to have a “real” mail server in the eyes of the internet at large. When setting up a mail server, you should pay very close attention to various types of DNS records relevant for email delivery, and make sure that your server introduces itself (the HELO/EHLO message in the SNMP connections) using the exact name registered for it in the DNS. Also make sure that the reverse DNS record (PTR record, for the IP address -> domain name mapping) is correct.

Answered By: telcoM
Categories: Answers Tags: , , ,
Answers are sorted by their score. The answer accepted by the question owner as the best is marked with
at the top-right corner.