1

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!

Richard
  • 363

1 Answers1

2

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).

anx
  • 9,748
  • Thanks so much @anx! You are right. When I entered a FQDN as the value, I started receiving emails. I assumed that because I had an A record for the subdomain, the MX would end up pointing to the same IP address if I only entered the subdomain, but apparently that isn't how it works. – Richard Oct 28 '20 at 18:21