How to install Fail2ban with email notification

How to installFail2ban email notification

How do I enable Fail2ban email notifications on Ubuntu?

Install Fail2ban and an MTA that provides a sendmail binary (Postfix or lightweight msmtp-mta). Create /etc/fail2ban/jail.local with destemail, sender, mta = sendmail, and action = %(action_mwl)s, enable the sshd jail, then restart Fail2ban. Test delivery with mail -s "Fail2ban Test" you@example.com. Note: some clouds block SMTP/25—use an SMTP relay if needed.

Bash
[DEFAULT]
destemail = you@example.com
sender    = fail2ban@example.com
mta       = sendmail
action    = %(action_mwl)s

[sshd]
enabled = true

Most guides show how to install Fail2ban. Fewer show how Fail2ban email notification works. That’s usually where things break: Fail2ban runs, bans work, but no alert ever lands in your inbox.

In this tutorial, I focus on the missing piece: email notifications on Ubuntu. I’ll walk you through a quick Fail2ban setup, then show you the simplest ways to send mail from the server (using Postfix or a lightweight SMTP helper). We’ll conclude with a brief test to confirm that emails are actually delivered.

Why bother with alerts? They’re not just “nice to have.” Email saved me once when my Proxmox box got banned by mistake — I caught it immediately and fixed it by adding an ignoreip. Without that alert, the issue would have lingered.

This guide is written for Ubuntu (22.04/24.04), but the same principles apply elsewhere. Let’s get your bans into your inbox.


Amazon Prime Days


What is Fail2ban?

ail2ban monitors log files for suspicious activity, such as repeated failed logins. When it detects an attack, it automatically blocks the offending IP address using firewall rules. Besides blocking, Fail2ban can also send you email alerts about the activity.


Install Fail2ban with send email support (Ubuntu Server)

I’m using Ubuntu for this example. The installation is quick — just make sure your server is up to date first:

Bash
sudo apt update && sudo apt upgrade -y

Now install Fail2ban:

Bash
sudo apt install fail2ban -y

For email alerts, you also need a mail transfer agent (MTA). The simplest option is Postfix, which works out of the box with Fail2ban:

Bash
sudo apt install postfix -y

Finally, confirm that your server clock is correct (important for logs and email headers):

Bash
timedatectl

If the time is wrong, adjust it with timedatectl set-timezone before continuing.


Configure Fail2ban

Fail2ban’s main configuration lives in /etc/fail2ban/jail.conf.
Never edit this file directly — it may be overwritten by updates.

Instead, create /etc/fail2ban/jail.local. Settings in jail.local override jail.conf and stay safe during package upgrades.

In jail.local, you define:

  • Global defaults (e.g., ban time, email settings).
  • Service-specific jails (e.g., sshd, nginx, Postfix).

Here’s an example configuration for SSH with email notifications:

Bash
[DEFAULT]
ignoreip = 127.0.0.1
bantime  = 86400
findtime = 120
maxretry = 3
destemail = yourname@example.com
sender = fail2ban@example.com
sendername = Fail2ban
mta = sendmail
action = %(action_mwl)s

[sshd]
enabled = true
port    = 12522
filter  = sshd
logpath = /var/log/auth.log

Explanation:

  • ignoreip → trusted IPs (never banned).
  • bantime → how long (in seconds) an IP is banned (86400 = 24h).
  • findtime + maxretry → how many failed attempts within a time window trigger a ban.
  • destemail / sender → email details.
  • mta → mail program (use sendmail or postfix).
  • action = %(action_mwl)s → ban + send email + include logs.

Restart the Fail2Ban service after making changes to the configurations for them to take effect.

Tip: Don’t leave SSH on port 22. Update your firewall rules and reflect that port in your jail configuration.


Test Fail2ban & Email Alerts

After editing jail.local, reload Fail2ban and check the SSH jail:

Bash
sudo systemctl restart fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd

You should see the sshd jail enabled, with a list of log paths and zero banned IPs.

Send a quick test email (MTA sanity check)

Make sure the server can send mail before you test bans:

Bash
echo "Fail2ban email test" | mail -s "Fail2ban Test" yourname@example.com

If nothing arrives, check your mail logs:

Bash
sudo tail -n 50 /var/log/mail.log

On some systems using systemd only: journalctl -u postfix -n 50

Trigger a ban on purpose (safe test)

To test email notifications in Fail2Ban, deliberately fail an authentication attempt (e.g., by entering a wrong password multiple times) and check email for alerts.

From another machine, try a few failed SSH logins to your server (use your custom port):

Bash
ssh -p 12522 wronguser@your.server.ip
# enter a wrong password 3+ times (based on your maxretry)

Now confirm the ban:

Bash
sudo fail2ban-client status sshd

You should see 1 banned IP. An email with subject similar to [Fail2Ban] sshd should land in your inbox (with logs, because we used %(action_mwl)s).

Unban yourself (if needed)

If you locked out a legit IP during testing:

Bash
sudo fail2ban-client set sshd unbanip <YOUR_IP>

Common gotchas (quick fixes)

  • No email received → Check /var/log/mail.log, spam folder, and make sure destemail is correct for the mail server.
  • No bans → Confirm logpath matches your distro (/var/log/auth.log on Ubuntu).
  • Wrong time in emails → Fix server clock: timedatectl set-timezone Europe/Zurich.
  • MTA not found → Reinstall: sudo apt install postfix -y (choose Internet Site)


Postfix vs msmtp vs Sendmail — which should I use?

Postfix: full MTA, reliable defaults, provides /usr/sbin/sendmail.
msmtp-mta: lightweight relay to external SMTP (simple, minimal).
Sendmail: classic but complex—only if you specifically want it.
Tip: For most, Postfix or msmtp-mta is best. Both work with mta = sendmail.

How do I Whitelist permanently

edit /etc/fail2ban/jail.local

[DEFAULT]
ignoreip = 127.0.0.1 ::1 192.0.2.10 203.0.113.0/24

Only for SSH (put inside the jail):
[sshd]
ignoreip = 127.0.0.1 ::1 192.0.2.10 203.0.113.0/24


Real-World Example: How Email Notifications Revealed My Proxmox Server Banned by Fail2ban

Proxmox comes with sendmail already installed for email alerts. Many don’t know that sendmail looks for Postfix servers on your network and tries to connect to them.

I have a Postfix server at home that uses Fail2ban with email notifications. One day, I got an unexpected email alert. Surprise! My own Fail2ban setup was banning my Proxmox server.

Without these email alerts, I might never have noticed this problem. My servers would have been fighting each other silently for weeks.

The alerts showed me exactly what was happening: Proxmox’s sendmail was trying to connect to my Postfix server, and Fail2ban saw these attempts as suspicious.

The fix was simple: I added the Proxmox server’s IP to the safe list.

Bash
ignoreip = 127.0.0.1 <Proxmox-IP>

This experience reinforced why I always enable email alerts. They don’t just warn you about hackers — they also reveal when your own devices misbehave.



Final Thoughts

Setting up Fail2ban with email notifications takes only a few extra steps, but the benefits are huge. You’ll know right away when suspicious activity occurs — and, as I experienced, sometimes the alerts even uncover problems inside your own network.

One note if you’re running this on a VPS or cloud provider: many data centers block or limit outgoing SMTP (port 25). If emails don’t arrive, check with your host. A workaround is to configure Postfix (or msmtp) to relay mail through a trusted SMTP service like Gmail, your ISP, or a transactional email provider.

With that in place, Fail2ban isn’t just silently protecting your server — it’s actively keeping you informed.


Before you go …

If you found the Fail2Ban email notification setup helpful, there’s more you can do to strengthen your server’s security. A great next step is implementing two-factor authentication for SSH access. It’s especially valuable for platforms like Proxmox or any Linux-based system where SSH is a key entry point.

For a clear walkthrough on adding this extra layer of protection, check out securing SSH with 2FA on Linux and Proxmox. It’s a practical way to stay one step ahead of unauthorized access.

Full Disclosure

Any purchases made from clicks on links to products on this page may result in an affiliate commission for me. 

Please keep in mind that the quantity or price of items can change at any time.

As an Amazon  Associate, I earn from qualifying purchases.

Als Amazon-Partner verdiene ich an qualifizierten Verkäufen

Tech Expert & Blogger