1

Topic: Can't send mail to our parent company

==== REQUIRED BASIC INFO OF YOUR IREDMAIL SERVER ====
- iRedMail version: 1.5.2 MariaDB edition
- Deployed with iRedMail installer script from Github
- Ubuntu 20.04 LTS
- Store mail accounts in MySQL (MariaDB)
- Web server: NGINX
- Manage mail accounts with iRedAdmin-Pro? No
- [IMPORTANT] Related original log or error message is required if you're experiencing an issue.
====

Hi There! I'm new to iRedMail but am really liking the platform. Setup with the GitHub installer script went smooth and easy. However...

Setup Info: Fresh install of Ubuntu 20.04 VM on ESXi 7 with iRedMail 1.5.2. 8 cores and 16GB RAM Allocated. VM is behind a FortiGate Firewall with a virtual IP (Public IP NAT'd to Internal). SSL cert installed with LetEncrypt via certbot. Public DNS records: A record for mail pointing to IP, MX records for mail.company.info pointing to mail. Server is mail.company.info parent company is company.com

Symptoms:
1) Receiving mail from everywhere is OK
2) Sending mail to external domains is OK
3) sending mail from mail.company.info (iRedMail) to company.com (365 via Barracuda) NOT OK!

Email looks like it's sent, but never even reaches the Barracuda for company.com. No bounce back no error... just off into the wild ether yonder it seems.

Thought it may be a DNS issue so I installed resolv.conf and pointed DNS to google (8.8.8.8,8.8.4.4). dig -tmx company.com results in finding the mx records and shows google as the server... but...

If anyone could point me to a post or has had experienced and fixed something like this, I'd send a ton of good Karma your way!

----

Spider Email Archiver: On-Premises, lightweight email archiving software developed by iRedMail team.

2

Re: Can't send mail to our parent company

Fixed! - It was a DNS issue. I had tried the workaround for email not sending to a local domain that edits the postfix main.cf to add the transport file and explicit domain rule. after removing the workaround, the resolv.conf install worked with the updated DNS... server was looking internally (127.0.0.53) which resolved internally but not externally to the ... okay, you all probably knew that anyway... but just in case someone else needs it.