Postfix subdomain can send, but not receive external email
I'm setting up an AWS EC2 instance, and I need the server to be able to receive emails. Let's say that I am setting up email on the subdomain mail.myserver.com.
I have Postfix installed, and I can send/receive emails locally. I can send emails from the server to my external gmail account. I can also telnet into port 25 from my laptop with telnet mail.myserver.com 25 and successfully send an email to the server.
But if I try to send an email from gmail or outlook to the server, there is nothing... crickets. The email doesn't bounce back. There is no error message. I check the postfix log at /var/log/email.log and there is no sign of any incoming connection from gmail/outlook. I check for errors at /var/log/email.err and there is nothing.
I am wondering if this could be a DNS issue because I have previously setup email for the server at myserver.com with IP address 111.111.111.111. But I am currently trying to configure a separate server at the subdomain mail.myserver.com with IP address 22.22.22.22.
Here are the DNS records for both the main domain myserver.com which has working email, and the new subdomain mail.myserver.com which currently won't receive external mail:
A @ 111.111.111.111
A mail 22.22.22.22
MX @ @ (Priority: 0)
MX mail mail (Priority: 0)
TXT @ v=spf1 mx -all
TXT mail v=spf1 mx -all
Here is the postfix config /etc/postfix/main.cf:
# See /usr/share/postfix/main.cf.dist for a commented, more complete version
# Debian specific: Specifying a file name will cause the first
# line of that file to be used as the name. The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no
# appending .domain is the MUA's job.
append_dot_mydomain = no
# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h
readme_directory = no
# See http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on
# fresh installs.
compatibility_level = 2
# TLS parameters
smtpd_tls_cert_file=/etc/letsencrypt/live/mail.myserver.com/fullchain.pem
smtpd_tls_key_file=/etc/letsencrypt/live/mail.myserver.com/privkey.pem
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_tls_security_level = may
smtpd_tls_protocols = !SSLv2, !SSLv3 !TLSv1
smtpd_tls_loglevel = 1
smtp_tls_note_starttls_offer = yes
smtpd_tls_received_header = yes
# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = mail.myserver.com
home_mailbox = Maildir/
virtual_alias_maps = hash:/etc/postfix/virtual
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = mail.myserver.com, localhost, ip-x-x-x-x.us-east-2.compute.internal, localhost.us-east-2.compute.internal, localhost.$mydomain
relayhost =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all
home_mailbox = Maildir/
As a side note, I have also checked the mailboxes and logs of the main domain myserver.com just to make sure emails were not ending up there for some reason. They are not. Nothing in the logs.
I have been stuck on this for 24 hours, and I'm not sure how to continue troubleshooting this when I'm not getting any error messages or bounced mail. All suggestions are welcome!
Solution 1:
If you define MX records without specifying how to handle unqualified names, rather type out the fully-qualified name of your mail servers A+AAAA. The entire name, ending with a dot, like this:
@ IN MX 10 mx1.mydomain.example.
subdomain IN MX 10 mx1.mydomain.example.
mx1 IN A 192.0.2.1
mx1 IN AAAA 2001:db8::1
I think this is your problem because the dns information you provided MX mail mail (Priority: 0) lacks a fully-qualified name in the MX record. If the software did not complete the unqualified name with your domain, mails might be delivered elsewhere (or in this case, probably not at all because the domain does not currently resolve).