DEV Community

Sireesharaju Kamparaju
Sireesharaju Kamparaju

Posted on

Setting Up Email Notifications in AWX via SMTP and Postfix — My DevOps Journey By Sireesha

After writing about Ansible Vault, I wanted to close the loop on something I'd been putting off — actually knowing when my patching workflow fails instead of finding out the next morning. So in my homelab I set up a Postfix mail server to act as my SMTP relay and connected it to AWX for email notifications.
In this blog I'll walk through exactly how I did it — setting up Postfix, configuring the AWX notification template, and getting the firewall side sorted with help from our network team since that's not something I manage directly.
In this blog I'll cover:

Setting up Postfix as my SMTP relay
Creating the email notification template in AWX
Getting the firewall opened for SMTP traffic
Attaching the notification to my patching workflow
Testing it end to end

Let's get into it.

Why I Choose with Postfix
I wanted something self-hosted rather than relying on Gmail or an external SMTP provider for my homelab. Postfix is the standard mail transfer agent on Linux and it's lightweight enough to run on a small VM just for relaying AWX notifications. It also gave me a proper feel for how a real internal SMTP relay works — which is exactly what most companies use in production.

Step 1 — Installing Postfix
I set up a small Ubuntu VM dedicated to acting as my mail relay and installed Postfix on it:

sudo apt update
sudo apt install -y postfix
Enter fullscreen mode Exit fullscreen mode

During installation it asks you to choose a configuration type. I selected:

Internet Site
Enter fullscreen mode Exit fullscreen mode

And set the System mail name to something like:

mail.homelab.local
Enter fullscreen mode Exit fullscreen mode

Step 2 — Configuring Postfix as a Relay
I edited the main Postfix config file to allow my AWX server to relay through it:

sudo vi /etc/postfix/main.cf
Enter fullscreen mode Exit fullscreen mode

The key settings I made sure were set:

myhostname = mail.homelab.local
mydestination = $myhostname, localhost.localdomain, localhost
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 <ansible-IP>/24
inet_interfaces = all
Enter fullscreen mode Exit fullscreen mode

The important line is mynetworks — I added my homelab subnet /24 so Postfix trusts and relays mail coming from any of my homelab servers, including AWX, without needing authentication.
Restart Postfix to apply the changes:

sudo systemctl restart postfix
sudo systemctl enable postfix
Enter fullscreen mode Exit fullscreen mode

Step 3 — Testing Postfix Locally First
Before even touching AWX, I wanted to confirm Postfix itself was working. I installed mailutils to send a quick test email from the command line:

sudo apt install -y mailutils
echo "Test email body" | mail -s "Postfix Test" your@email.com
Enter fullscreen mode Exit fullscreen mode

Check the mail log to see what happened:

sudo tail -f /var/log/mail.log
Enter fullscreen mode Exit fullscreen mode

If you see status=sent in the log, Postfix is relaying correctly and you're ready to connect AWX to it.

Step 4 — Getting the Firewall Opened
This is the part I couldn't do myself — our network team manages the firewall between network segments in our homelab/internal setup. I raised a request with them to allow:

AWX server subnet → Postfix server (10.215.77.X) → Port 25 TCP
Enter fullscreen mode Exit fullscreen mode

They confirmed it was opened on their side. If you're managing your own firewall on the Postfix VM itself, the equivalent UFW rule would be:

sudo ufw allow from 10.215.77.0/24 to any port 25 proto tcp
Enter fullscreen mode Exit fullscreen mode

And on the AWX side, if there's an outbound rule needed on the Kubernetes worker nodes:

sudo ufw allow out to 10.215.77.X port 25 proto tcp
Enter fullscreen mode Exit fullscreen mode

Tip: Always test raw port connectivity before testing inside AWX. Saves you from chasing the wrong problem.

nc -zv 10.215.77.X 25
Enter fullscreen mode Exit fullscreen mode

If that connects, you're clear to move on to the AWX side.

Step 5 — Creating the Notification Template in AWX

AWX UI → Administration → Notifications
Click Add

Click Save

Step 6 — Attaching the Notification to My Patching Workflow

AWX UI → Templates → open Patching Workflow → Notifications tab
Under Failure, toggle on Patching Workflow Email Alerts
Click Save

I only enabled it for Failure — I don't need an email every time the workflow succeeds, only when something goes wrong.

Step 7 — Testing the Notification
AWX has a built-in test button so I didn't need to wait for an actual failure to check it worked:

  • Go back to Administration → Notifications
  • Open Patching Workflow Email Alerts
  • Click Test

I checked my inbox and the test email came through within a few seconds. I also double checked the Postfix mail log on the relay server at the same time:

sudo tail -f /var/log/mail.log
Enter fullscreen mode Exit fullscreen mode

Seeing the AWX server's IP show up in the log with status=sent confirmed the whole chain was working end to end — AWX → Postfix → my inbox.

Errors I Hit Along the Way

Error 1 — Connection Timed Out from AWX

SMTPConnectError: Connection to <ansoble-IP>timed out
This was the firewall not being opened yet. Once the network team confirmed the rule was in place between the AWX subnet and the Postfix server, this cleared immediately.

Error 2 — Relay Access Denied

SMTPRecipientsRefused: 554 5.7.1 Relay access denied

This happened because I forgot to add my homelab subnet to mynetworks in Postfix's main.cf. Postfix was rejecting the AWX server because it didn't recognise it as a trusted network. Fix:

sudo vi /etc/postfix/main.cf
# add your subnet to mynetworks
sudo systemctl restart postfix
Enter fullscreen mode Exit fullscreen mode

Error 3 — Mail Stuck in the Queue

I noticed test emails weren't arriving and checked the Postfix queue:

mailq
Enter fullscreen mode Exit fullscreen mode

There were a few stuck messages. This was because my Postfix VM didn't have a working DNS resolver set up properly, so it couldn't resolve where to deliver outbound mail. Since this was all internal traffic destined for a local mailbox, I made sure the destination mail server was reachable and resolvable, then flushed the queue:

sudo postqueue -f
Enter fullscreen mode Exit fullscreen mode

Error 4 — Postfix Service Not Starting After Config Change

postfix/postfix-script: fatal: the Postfix mail system is not running
A typo in main.cf caused this. Always check the config syntax before restarting:

sudo postfix check
Enter fullscreen mode Exit fullscreen mode

This pointed me straight to the line with the typo.

What I Learned from This

Test each layer separately. Postfix locally first, then raw firewall connectivity, then AWX notification test, then the actual workflow trigger. Trying to debug all of it at once just leads to confusion about where the actual problem is.

mynetworks is the equivalent of an allow-list for SMTP relaying. If your AWX server's subnet isn't in there, Postfix will reject it outright with a relay denied error — no amount of AWX configuration will fix that.

Firewall changes between teams take coordination. Since I don't manage the network firewall myself, I had to raise the request and wait for confirmation. Good reminder that in real environments, automation setups often depend on more than just your own server configs.

The Postfix mail log is your best friend. Whenever something didn't work as expected, tail -f /var/log/mail.log told me exactly what was happening — accepted, deferred, bounced or sent.

What's Next
Now that I have working email alerts on failure, the next thing I want to try is adding a Slack notification alongside email — so I get alerted in both places when the patching workflow fails at 2AM on a Sunday.

Drop your questions in the comments — happy to help if you're setting up something similar in your own homelab!
— Sireesha

Top comments (0)