DEV Community: Khadirullah Mohammad

Setting Up Custom Domain Email with SPF, DKIM, and DMARC

Khadirullah Mohammad — Tue, 19 May 2026 13:30:00 +0000

A complete guide to setting up professional email on your custom domain — with SPF, DKIM, and DMARC explained from the ground up.

When I bought my domain, one of the first things I wanted was a professional email address — contact@yourdomain.com instead of a generic Gmail address. But I also wanted to make sure nobody could spoof my domain to send fake emails pretending to be me.

This post covers everything I did: setting up Zoho Mail, configuring DNS records in Cloudflare, and implementing SPF, DKIM, and DMARC — the three protocols that prove your emails are legitimate.

Why Custom Domain Email?

Option	What It Looks Like	Impression
Gmail	@gmail.com	"Just another person"
Custom domain	contact@yourdomain.com	"Professional, owns their infrastructure"

For a DevOps engineer's website, having a custom domain email shows you understand DNS, mail infrastructure, and security — which is literally part of the job.

Why Zoho Mail?

Provider	Free Tier	Why I Chose/Skipped
Google Workspace	No free tier anymore	Costs $6/month per user
Microsoft 365	No free tier	Costs $6/month per user
ProtonMail	Custom domain on paid plan only	Costs $4/month
Zoho Mail	✅ Free for 5 users, 5GB	Free, custom domain. Note: Web/App only (no IMAP)
Cloudflare Email Routing	Free	Forwarding only — can't send FROM your domain

Zoho Mail gives you a real mailbox on your custom domain for free for up to 5 users. You can send and receive emails as anything@yourdomain.com, though the free plan requires using the Zoho Mail website or mobile app (IMAP/POP for third-party apps like Outlook or Apple Mail is not included). You can upgrade to a paid plan to add IMAP/POP and other features.

Step 1: Add Your Domain to Zoho

Go to Zoho Mail → Sign up for the free plan
Add your domain — Zoho will ask you to verify ownership
Zoho gives you a TXT record to add to your DNS — this proves you own the domain

In Cloudflare DNS:

Type	Name	Content
TXT	`@`	`zoho-verification=zb12345678.zmverify.zoho.com`

After adding this record, click "Verify" in Zoho. Once verified, Zoho gives you the remaining DNS records.

Step 2: MX Records (Mail Exchange)

MX records tell the internet where to deliver emails for your domain. When someone sends an email to contact@yourdomain.com, the sending mail server looks up the MX records for yourdomain.com to find out which mail server should receive it.

Zoho provides these MX records:

Type	Name	Mail Server	Priority
MX	`@`	`mx.zoho.com`	10
MX	`@`	`mx2.zoho.com`	20
MX	`@`	`mx3.zoho.com`	50

Priority determines the order — the sending server tries priority 10 first (mx.zoho.com). If that's down, it tries priority 20, then 50. This gives you redundancy.

Add all three in Cloudflare DNS.

ℹ️ Note: These are the MX records for Zoho's US/global data center (zoho.com). If you signed up at zoho.eu or zoho.in, your MX servers will be different (e.g., mx.zoho.eu). Always use the exact values Zoho provides during setup.

⚠️ Important: Make sure the proxy status for MX records is set to DNS only (gray cloud), not Proxied (orange cloud). Email traffic cannot go through Cloudflare's proxy.

Step 3: SPF (Sender Policy Framework)

What Is SPF?

SPF answers the question: "Which mail servers are allowed to send email on behalf of my domain?"

Without SPF, anyone in the world could send an email that says From: contact@yourdomain.com — and the receiving server would have no way to verify if it's real. SPF fixes this by publishing a list of authorized mail servers in your DNS.

How It Works

1. You send an email from contact@yourdomain.com via Zoho
2. Zoho sends it with a Return-Path (envelope sender) on your domain
3. The receiving mail server looks up the SPF record for that envelope domain
4. SPF record says: "Only Zoho's servers are allowed to send for this domain"
5. Mail server checks: Did this email actually come from Zoho's IP addresses?
   → Yes → SPF passes
   → No  → SPF fails (mark as suspicious or reject)

ℹ️ Technical detail: SPF validates the envelope sender (Return-Path), not the From: header you see in your email client. For simple setups like Zoho, these match your domain — but the distinction matters when you add third-party senders and is the reason DMARC alignment exists as a separate check (explained below).

The Record

Zoho provides this SPF record:

Type	Name	Content
TXT	`@`	`v=spf1 include:zoho.com ~all`

ℹ️ Regional note: Just like MX records, the SPF include: domain varies by Zoho region. If you signed up at zoho.eu, use include:zoho.eu. If zoho.in, use include:zoho.in. Always use the exact SPF record Zoho provides during setup.

Breaking it down:

Part	Meaning
`v=spf1`	This is an SPF record (version 1)
`include:zoho.com`	Allow any server that Zoho authorizes
`~all`	Soft-fail everything else (mark as suspicious but don't reject)

ℹ️ ~all vs -all: The ~ (tilde) means "soft fail" — unauthorized emails are marked suspicious but still delivered. The - (hyphen) means "hard fail" — unauthorized emails are rejected outright. I started with ~all to make sure legitimate emails weren't accidentally blocked. Once you're confident everything works, you can switch to -all for stricter enforcement.

ℹ️ DevOps gotcha: SPF has a 10 DNS lookup limit. Each include: in your SPF record triggers DNS lookups, and nested includes count too. Zoho's include:zoho.com uses a few of those. If you later add services like SendGrid, Mailchimp, or AWS SES, you can easily exceed this limit — causing SPF to permanently fail. Use tools like dmarcian SPF Surveyor to audit your lookup count.

Step 4: DKIM (DomainKeys Identified Mail)

What Is DKIM?

DKIM answers the question: "Was this email actually sent by who it claims, and was it tampered with in transit?"

DKIM uses cryptographic signatures. When Zoho sends an email from your domain, it signs the email with a private key that only Zoho has. The receiving server verifies the signature using a public key that you publish in your DNS.

How It Works

1. You send an email from contact@yourdomain.com via Zoho
2. Zoho signs selected email headers (like From, Subject, Date) and a hash of the body with its private key
3. Zoho adds the signature to the email header as "DKIM-Signature"
4. Receiving mail server looks up the DKIM public key in your DNS
5. Server verifies: Does the signature match the email content?
   → Yes → Email is authentic and untampered
   → No  → Email was forged or modified in transit

The Record

Zoho gives you a DKIM TXT record to add. It looks something like:

Type	Name	Content
TXT	`zmail._domainkey`	`v=DKIM1; k=rsa; p=MIGfMA0GCS...` (long public key)

The zmail._domainkey is the selector — it tells receiving servers where to find the public key for Zoho-signed emails.

You get this record from Zoho's admin panel: Email Admin → Domain → Email Authentication → DKIM. Zoho generates the key pair and gives you the public key to put in DNS. You just copy-paste it into Cloudflare.

Step 5: DMARC (Domain-based Message Authentication, Reporting & Conformance)

What Is DMARC?

DMARC answers the question: "Does the domain in the From: header actually match the domain verified by SPF or DKIM — and what should happen if it doesn't?"

DMARC ties SPF and DKIM together into a unified policy. It tells receiving servers:

Check SPF — did the email come from an authorized server?
Check DKIM — is the signature valid?
Check alignment — does the authenticated domain match the From: header domain?
If neither SPF nor DKIM passes with alignment, apply the policy (nothing, quarantine, or reject)
Send me reports about pass/fail results

Why Alignment Matters

SPF and DKIM alone have a gap: an attacker could set up their own domain with valid SPF and DKIM, but forge your domain in the From: header that the recipient sees. Both SPF and DKIM would pass — for the attacker's domain — but the recipient would still see your spoofed address.

DMARC closes this gap by requiring alignment: the domain authenticated by SPF or DKIM must match the domain in the visible From: header.

Check	What Must Align
SPF alignment	`Return-Path` (envelope sender) domain must match `From:` header domain
DKIM alignment	`d=` domain in the DKIM signature must match `From:` header domain

DMARC passes if at least one of SPF or DKIM passes its check and is aligned with the From: domain. This means an email can fail SPF but still pass DMARC if DKIM passes and is aligned (or vice versa).

For a simple Zoho setup, alignment works automatically — Zoho uses your domain for both the envelope sender and DKIM signature. But if you ever add third-party email services (like Mailchimp or SendGrid), you'll need to make sure they can send with proper alignment, or those emails will fail DMARC.

The Record

Type	Name	Content
TXT	`_dmarc`	`v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com`

Breaking it down:

Part	Meaning
`v=DMARC1`	This is a DMARC record (version 1)
`p=none`	Policy: don't take action on failures (just monitor)
`rua=mailto:dmarc@yourdomain.com`	Send aggregate reports to this email

⚠️ Heads up: DMARC aggregate reports are not human-readable emails. They arrive as gzipped XML attachments that look like gibberish if you open them directly. You'll need a tool to parse them — services like DMARC Analyzer, Postmark DMARC, or dmarcian can ingest these reports and turn them into dashboards you can actually read.

ℹ️ Other useful DMARC tags you'll encounter:

ruf=mailto:... — Forensic (per-failure) reports with details about individual failures. Few providers send these due to privacy concerns, but it doesn't hurt to include.

adkim=r / aspf=r — Alignment mode: r for relaxed (subdomains can align, e.g., mail.yourdomain.com matches yourdomain.com), s for strict. Defaults are relaxed, which is correct for most setups.

pct=100 — Percentage of messages the policy applies to. Useful for gradually rolling out a stricter policy (e.g., pct=10 to apply p=quarantine to only 10% of failing messages at first).

DMARC Policy Levels

Policy	What Happens on Failure	When to Use
`p=none`	Nothing — just collect reports	Start here. Monitor for 2-4 weeks.
`p=quarantine`	Failed emails go to spam folder	After confirming legitimate emails pass
`p=reject`	Failed emails are rejected entirely	Maximum protection — use after `quarantine` works

💡 Tip: I started with p=none to monitor and make sure my legitimate emails from Zoho were passing SPF and DKIM checks. Once I confirmed everything was working, I could tighten the policy. Don't jump straight to p=reject — you might accidentally block your own emails.

Step 6: Email Aliases and Routing

The Setup

Instead of creating multiple Zoho accounts (the free tier allows up to 5 users, but paid plans charge per user), I use aliases to keep costs down and management simple:

Address	Purpose	Type
`yourname@yourdomain.com`	Main email (admin account)	Primary
`contact@yourdomain.com`	Displayed on website	Alias → forwards to primary

How Aliases Work

When someone sends an email to contact@yourdomain.com, Zoho delivers it to my primary inbox. When I reply, I can choose to reply as contact@yourdomain.com — so the person never sees my primary address.

The Security Catch with Aliases

There is one important detail to note: Zoho allows you to log into your account using any of your aliases as the username.

This can be both good and bad:

The Advantage: It's convenient. You don't have to remember your primary admin email; you can just log in using your public alias.
The Security Risk: If you created a private, hard-to-guess admin email to protect your account, that security is bypassed because attackers can simply use your public alias (like contact@yourdomain.com) to attempt to log into your admin panel.

🛡️ Security Tip: Use Group Aliases — To solve this login vulnerability, you can use Group Aliases instead of regular user aliases. Group aliases are strictly blocked from being used to sign in. With a bit of extra configuration in Zoho, you can still send and receive emails using the group alias, giving you the routing benefits without exposing your account to login attacks.

Folder-Based Rules

I also set up rules in Zoho to automatically organize incoming email:

Rule	Action
Email to `contact@`	Move to "Website" folder
Email from GitHub	Move to "GitHub" folder
Email from LinkedIn	Move to "LinkedIn" folder

This keeps my inbox clean and organized without manual sorting.

How All the Records Work Together

Here's what happens when someone receives an email "from" my domain:

Verifying Your Setup

After adding all the records, verify everything works:

Check DNS Records

# MX records
dig MX yourdomain.com +short
# Expected: 10 mx.zoho.com, 20 mx2.zoho.com, 50 mx3.zoho.com

# SPF
dig TXT yourdomain.com +short
# Expected: "v=spf1 include:zoho.com ~all"

# DKIM
dig TXT zmail._domainkey.yourdomain.com +short
# Expected: "v=DKIM1; k=rsa; p=MIGf..."

# DMARC
dig TXT _dmarc.yourdomain.com +short
# Expected: "v=DMARC1; p=none; rua=mailto:..."

Online Tools

🔗 MXToolbox — checks MX, SPF, DKIM, DMARC, and blacklist status
🔗 Mail Tester — send a test email and get a deliverability score out of 10
🔗 DMARC Analyzer — parse DMARC aggregate reports

Send a Test Email

Send an email from your custom domain to a Gmail address. In Gmail, open the email → click the three dots → "Show original". Look for:

SPF:   PASS
DKIM:  PASS
DMARC: PASS

✅ If all three show PASS, your authentication setup is complete. But read the next section — authentication alone doesn't guarantee inbox delivery.

But Your Emails Can Still Land in Spam

⚠️ Important: Setting up SPF, DKIM, and DMARC is essential — but it doesn't guarantee inbox delivery. These records prove authentication (that you are who you say you are), but major email providers like Gmail and Outlook also evaluate reputation and content.

Here are the other factors that can send your perfectly authenticated emails straight to spam:

1. Spammy Subject Lines or Body Content

Email providers run your email through content filters. If your subject line looks like FREE MONEY — ACT NOW!!! or your body is stuffed with sales language, excessive links, or all-caps text, it gets flagged regardless of your DNS setup. Write emails like a human, not a marketer.

2. IP or Domain Reputation

Every mail server has an IP address, and that IP has a reputation score. If the IP your emails are sent from has been used for spam in the past (even by other users on the same shared server), your emails inherit that bad reputation. You can check your IP's reputation using tools like MXToolbox Blacklist Check or Google Postmaster Tools.

3. Domain and IP Warming

This is the one most people don't know about. When you start sending emails from a brand new domain or IP address, email providers have zero trust in you. You have no sending history, no reputation — you're an unknown.

If you suddenly send 500 emails from a new domain, Gmail will almost certainly flag them. The solution is called warming — you start by sending a small number of emails (5-10 per day) and gradually increase the volume over 2-4 weeks. This lets providers build trust in your sending patterns over time. On shared hosting like Zoho, the IP addresses are already established — it's your domain reputation that starts from zero.

ℹ️ For a personal domain like mine, IP warming isn't a big concern since I only send a few emails a day. But if you're setting up email for a **business or newsletter, IP warming is critical.**

4. Recipients Marking You as Spam

This is the most brutal one. If enough people who receive your emails click the "Report Spam" button, email providers learn that people don't want your emails. Once your spam complaint rate crosses a threshold (Google's threshold is roughly 0.3%), your future emails start landing in spam for everyone — even people who want them.

This is why every newsletter has an unsubscribe link. It's better for someone to unsubscribe than to hit "Report Spam."

💡 Tip: Bottom line: SPF, DKIM, and DMARC get you through the authentication door. But content quality, sender reputation, IP warming, and user engagement determine whether you make it to the inbox or the spam folder. Think of DNS records as your ID card — they prove who you are, but they don't guarantee you'll be invited in.

Summary of All DNS Records

Here's the complete set of DNS records I added in Cloudflare for email:

Type	Name	Content	Proxy
MX	`@`	`mx.zoho.com` (priority 10)	DNS only
MX	`@`	`mx2.zoho.com` (priority 20)	DNS only
MX	`@`	`mx3.zoho.com` (priority 50)	DNS only
TXT	`@`	`v=spf1 include:zoho.com ~all`	—
TXT	`zmail._domainkey`	`v=DKIM1; k=rsa; p=MIGf...`	—
TXT	`_dmarc`	`v=DMARC1; p=none; rua=mailto:...`	—
TXT	`@`	`zoho-verification=...`	—

What I Learned

SPF, DKIM, and DMARC are not optional — without them, your emails land in spam or get rejected by Gmail/Outlook. Most people skip these and wonder why their emails aren't delivered.
Zoho gives you the records — you just paste them — I didn't generate any keys manually. Zoho's admin panel provides every DNS record you need. Your job is to copy them into your DNS provider (Cloudflare in my case) correctly.
Start with p=none for DMARC — don't jump to p=reject immediately. Monitor first, make sure legitimate emails pass, then tighten the policy.
Aliases are powerful — one Zoho account can receive email at multiple addresses. No need to create separate accounts.
DNS propagation takes time — after adding records, wait 15-30 minutes (sometimes up to 48 hours) before testing. Don't panic if verification fails immediately.
MX records must be DNS-only in Cloudflare — if you accidentally proxy them (orange cloud), email delivery breaks. Always set MX records to gray cloud (DNS only).

A Quick Warning: My Personal Choice on Using Custom Domain Email for Logins

💀 Warning: This section is not a general recommendation — it's my personal threat model and decision based on how I use custom domains. If you're only using your domain for professional or business email, you can skip this — but I recommend reading it anyway.

When I first set all this up, my immediate thought was: Awesome, I'm going to create a custom alias for every platform I use. github@yourdomain.com, linkedin@yourdomain.com... you get the idea. It felt super organized.

But after thinking about it for a while, a darker thought crossed my mind: What happens if I die?

Or even if I just forget to renew the domain?

A custom domain is basically a subscription. If I'm not around to keep paying for it, the domain will eventually expire. And once it expires, anyone on the internet can buy it. If someone else does manage to buy my expired domain, they can set up an email server and start receiving all my messages. They could hit "Forgot Password" on my GitHub, get the reset link, and attempt to take over my account.

This creates a dependency chain: accounts → email → domain ownership. Break any link, and everything downstream is at risk.

The Objections I Considered

"Can't I just pay for 10 years upfront or use auto-renew?"
You could! You can prepay for a decade or put a credit card on auto-renew. Those are good practices, but they still aren't bulletproof. Credit cards expire, banks block transactions, and 10 years isn't forever.

"What about leaving a Digital Will?"
You might think that leaving a "Digital Will" with instructions for your family to maintain and renew the domain solves the problem. While it's a nice thought, relying on it for your core security is a bad idea. Your family simply won't care about maintaining your infrastructure as much as you do.

More importantly, they probably don't have the deep technical knowledge required to navigate domain registrars, DNS records, and email hosting. Expecting them to manage all of that — or expecting them to spend money hiring a professional to do it for them while they are grieving — is highly unrealistic.

"But I'll be dead, why do I care?"
You might be thinking this — and honestly, if you don't have anything important tied to the email, maybe you don't need to care! But if you are a developer distributing software that other people rely on, an attacker could push malware or spyware under your name. Furthermore, if you've used that email for government IDs or highly private, sensitive information, you probably don't want a random stranger gaining access to your digital life — because it could ultimately be used to scam, extort, or hurt your family. Who knows what a malicious actor might do with that kind of leverage?

"But what about MFA?"
You might argue that setting up Two-Factor Authentication (2FA/MFA) would stop an attacker from getting in, even if they have access to the email. And technically, you're right. But why even put yourself in that situation? Why rely on a secondary defense mechanism when your primary one (your email) is compromised?

Furthermore, if an attacker is triggering password resets, your accounts will likely get flagged and locked down. Recovering a locked account through customer support is already an incredibly tedious and stressful process. Now imagine trying to prove to support that it's really you, when you don't even own the email address associated with the account anymore! It's a nightmare waiting to happen.

Important Context

This is not a flaw in custom domains themselves. They are widely used in companies, teams, and organizations safely because they have renewal processes, domain management policies, and ownership continuity. The risk is mainly relevant for individuals managing everything alone over long time periods.

What I Changed

Because of this risk, I completely backtracked. I moved all my critical platform logins back to standard public emails like Gmail or Outlook, and now keep my custom domain strictly for professional use:

Purpose	Email	Why
Public-facing (on this website)	`contact@yourdomain.com`	Professional impression
Replies and correspondence	`yourname@yourdomain.com`	Clean sender identity
Account recovery and critical logins	Gmail / Outlook	Can't be bought out from under me

This gives me a balance between professionalism and long-term account safety.

🛡️ Security Tip: If you still want to use your custom domain for everything: That's completely valid — just make sure to add a secure public email (like ProtonMail, Outlook, or Gmail) as a secondary recovery email on all your platforms, enable auto-renew on your domain, and keep your payment methods updated. That way, if your domain host goes down, or you forget to renew, or something bad happens, you still have a reliable backdoor to recover your accounts.

Topic	Resource
SPF specification	RFC 7208 — Sender Policy Framework
DKIM specification	RFC 6376 — DomainKeys Identified Mail
DMARC specification	RFC 7489 — Domain-based Message Authentication
Beginner-friendly explainers	Cloudflare Learning Center — DNS Email Security
Google's sender requirements	Google Email Sender Guidelines
Microsoft's sender requirements	Microsoft Anti-Spam Policies
DMARC report analysis	Postmark's Free DMARC Monitoring

How to Block Internet Access for Any Linux App (While Keeping LAN)

Khadirullah Mohammad — Wed, 08 Apr 2026 12:55:49 +0000

Ever wanted Jellyfin to stay off the internet? Or Chromium to only work on your local network? Maybe you want to test how an app behaves offline — without actually pulling the Ethernet cable.

This guide shows you how to block outbound internet for any specific app on Linux while keeping localhost and your home LAN fully functional.

I'll cover five approaches, from a quick 2-minute wrapper script to a production-hardened Chromium setup that survives apt upgrades. Then I'll show you the fundamental security flaw that most guides never mention — and what to use instead when it actually matters.

🔥 Safety First: Take a Snapshot!
You are modifying core network firewall rules. A simple typo can easily break your internet connection or lock you out of your server. It is highly recommended to take a VM/System Snapshot before starting. If a snapshot is not possible, please take a manual backup of your UFW rules first. Reverting a snapshot takes 10 seconds; troubleshooting a broken firewall can take hours.

Why UFW?

You might wonder why this guide uses UFW instead of raw nftables or iptables. The answer is simple: safety for beginners. If something goes wrong — you accidentally lock yourself out of the network, or an app stops working — you can just run sudo ufw disable or even sudo apt remove ufw to instantly restore full connectivity. With raw nftables, one wrong rule can leave you debugging kernel tables for an hour. UFW is a thin wrapper over iptables/netfilter — same power, much easier to roll back.

How Does This Actually Work?

Every time a process opens a network socket, the Linux kernel stamps it with the process's UID (User ID) and GID (Group ID). The firewall — specifically netfilter, which UFW sits on top of — can inspect those stamps on outgoing packets and decide: accept or reject.

That's the entire trick:

Mark the app's processes with a specific UID or GID
Write firewall rules that allow that UID/GID to reach LAN addresses but reject everything else

For services (Jellyfin, Syncthing), we match by UID because they already run as dedicated users. For desktop apps (Firefox, Chromium), we match by GID using a no-internet group.

Which Approach Should You Use?

Your Situation	Best Option	Difficulty
"I just want to test this quickly"	Option A — Wrapper script	⭐ Easy
Desktop GUI app (Firefox, KeePassXC)	Option B — setgid on ELF	⭐⭐ Medium
System service (Jellyfin, Syncthing)	Option C — UID owner-match	⭐ Easy
Chromium or Electron apps	Option D — dpkg-divert	⭐⭐⭐ Advanced
You don't use UFW	Option E — Direct iptables/nftables	⭐⭐ Medium
Need real enforcement	Bypass-Proof Alternatives — Firejail / namespaces	⭐⭐ Medium

Quick Glossary

Term	Meaning	How to check
UID	User Identifier (numeric)	`id -u username`
GID	Group Identifier (numeric)	`getent group groupname`
EGID	Effective GID — the runtime GID the kernel actually uses for socket ownership	`ps -eo egid,egroup,cmd`
UFW	Uncomplicated Firewall — Debian/Ubuntu frontend for iptables	`sudo ufw status`
`sg`	Run a command with a different primary group	`sg groupname command`
`dpkg-divert`	Debian tool to relocate a package-managed file so your file can sit at the original path	`dpkg-divert --list`
conntrack	Connection tracking — lets the firewall allow replies to established connections	—
owner-match	iptables module that matches packets by the UID/GID of the process that created the socket	—

Before You Start: Back Up Everything

If you didn't take a VM or system snapshot, you must back up your current firewall state. Take 30 seconds to save your current rules so you can easily revert them later:

sudo iptables-save > ~/iptables.before
sudo mkdir -p ~/ufw_rules_backup
sudo cp /etc/ufw/before.rules ~/ufw_rules_backup/before.rules.backup
sudo cp /etc/ufw/before6.rules ~/ufw_rules_backup/before6.rules.backup

If anything goes wrong:

sudo cp ~/ufw_rules_backup/before.rules.backup /etc/ufw/before.rules
sudo cp ~/ufw_rules_backup/before6.rules.backup /etc/ufw/before6.rules
sudo ufw reload

The Firewall Rules (The Core of Everything)

Every option below ends up using the same firewall rules. The only difference is how you mark the app. Here's what the rules look like — you'll paste these into /etc/ufw/before.rules.

Where Exactly to Paste

Open the file and look for the *filter section at the top:

*filter
:ufw-before-input - [0:0]
:ufw-before-output - [0:0]
:ufw-before-forward - [0:0]
← YOUR RULES GO HERE, right after these lines

Your file should initially look like this:

For Desktop Apps (GID Match)

Once you paste your rules into the editor, it should look exactly like this:

Replace GID with your actual numeric group ID:

# --- BEGIN no-internet block (IPv4) ---
-A ufw-before-output -m owner --gid-owner GID -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-output -m owner --gid-owner GID -d 127.0.0.0/8 -j ACCEPT
-A ufw-before-output -m owner --gid-owner GID -d 10.0.0.0/8 -j ACCEPT
-A ufw-before-output -m owner --gid-owner GID -d 172.16.0.0/12 -j ACCEPT
-A ufw-before-output -m owner --gid-owner GID -d 192.168.0.0/16 -j ACCEPT
-A ufw-before-output -m owner --gid-owner GID -j LOG --log-prefix "Blocked noinet: "
-A ufw-before-output -m owner --gid-owner GID -j REJECT
# --- END no-internet block (IPv4) ---

Do the same in /etc/ufw/before6.rules (use ufw6-before-output, allow ::1 and fe80::/10):

# --- BEGIN no-internet block (IPv6) ---
-A ufw6-before-output -m owner --gid-owner GID -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw6-before-output -m owner --gid-owner GID -d ::1 -j ACCEPT
-A ufw6-before-output -m owner --gid-owner GID -d fe80::/10 -j ACCEPT
# Optional: uncomment for mDNS / DLNA / SSDP LAN service discovery
# -A ufw6-before-output -m owner --gid-owner GID -d ff00::/8 -j ACCEPT
-A ufw6-before-output -m owner --gid-owner GID -j LOG --log-prefix "Blocked noinet v6: "
-A ufw6-before-output -m owner --gid-owner GID -j REJECT
# --- END no-internet block (IPv6) ---

For Services (UID Match — `/etc/ufw/before.rules`)

Same structure, but use --uid-owner with the service's numeric UID:

# --- BEGIN service UID block (IPv4) ---
-A ufw-before-output -m owner --uid-owner UID -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-output -m owner --uid-owner UID -d 127.0.0.0/8 -j ACCEPT
-A ufw-before-output -m owner --uid-owner UID -d 10.0.0.0/8 -j ACCEPT
-A ufw-before-output -m owner --uid-owner UID -d 172.16.0.0/12 -j ACCEPT
-A ufw-before-output -m owner --uid-owner UID -d 192.168.0.0/16 -j ACCEPT
-A ufw-before-output -m owner --uid-owner UID -j LOG --log-prefix "Blocked uid: "
-A ufw-before-output -m owner --uid-owner UID -j REJECT
# --- END service UID block (IPv4) ---

And in /etc/ufw/before6.rules:

# --- BEGIN service UID block (IPv6) ---
-A ufw6-before-output -m owner --uid-owner UID -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw6-before-output -m owner --uid-owner UID -d ::1 -j ACCEPT
-A ufw6-before-output -m owner --uid-owner UID -d fe80::/10 -j ACCEPT
-A ufw6-before-output -m owner --uid-owner UID -j LOG --log-prefix "Blocked uid v6: "
-A ufw6-before-output -m owner --uid-owner UID -j REJECT
# --- END service UID block (IPv6) ---

Why This Order?

The rules are evaluated top-to-bottom, first match wins:

RELATED,ESTABLISHED — Don't break existing connections mid-stream
Loopback (127.x) — App can still talk to localhost
LAN ranges (10.x, 172.16.x, 192.168.x) — App can reach your home network
LOG — Audit blocked attempts in /var/log/kern.log or journalctl
REJECT — Everything else (the actual internet) gets blocked

Safe Way to Edit

⚠️ Warning: Always backup your original firewall rules to a safe, persistent location (like your root directory) before editing. Temporary files in /tmp/ are wiped upon every reboot!

Don't edit the live file directly. Backup, copy to a temp file, edit, test, then apply:

# 1. Create a permanent backup
sudo cp /etc/ufw/before.rules /root/before.rules.backup

# 2. Copy to a temporary file for editing
sudo cp /etc/ufw/before.rules /tmp/before.rules.edit
sudo nano /tmp/before.rules.edit                          # paste your rules

# 3. Syntax check (safe, doesn't apply)
sudo iptables-restore --test < /tmp/before.rules.edit     

# 4. Apply the rules
sudo mv /tmp/before.rules.edit /etc/ufw/before.rules
sudo chown root:root /etc/ufw/before.rules
sudo chmod 644 /etc/ufw/before.rules
sudo ufw reload

Option A: Quick Wrapper Script

Time: 2 minutes · Best for: Testing, quick experiments

This is the fastest way. You create a tiny script that launches any app under a no-internet group.

Setup

# Create the group
sudo groupadd -f no-internet
getent group no-internet    # note the GID (e.g., 1001)

# Add your user to the group so 'sg' doesn't prompt for a password
sudo usermod -aG no-internet $USER

3. Create the wrapper script

sudo tee /usr/local/bin/no-internet > /dev/null <<'EOF'
#!/bin/bash
exec sg no-internet "$@"
EOF
sudo chmod 755 /usr/local/bin/no-internet

Add the GID firewall rules to UFW and reload.

Usage

no-internet firefox &
no-internet steam &
no-internet keepassxc &

Verify It Works

# Should be BLOCKED:
sg no-internet -c 'curl -I -m 10 https://example.com' && echo "FAIL" || echo "BLOCKED ✓"

# Should still work:
sg no-internet -c 'curl -I -m 10 http://192.168.1.1' && echo "LAN works ✓" || echo "FAIL"

Downside: If you launch the app from the desktop menu, it won't use the wrapper. You'd need to edit the .desktop file:

cp /usr/share/applications/firefox.desktop ~/.local/share/applications/
nano ~/.local/share/applications/firefox.desktop
# Change: Exec=firefox %u
# To:     Exec=/usr/local/bin/no-internet firefox %u

Option B: setgid on the Binary

Time: 5 minutes · Best for: Desktop apps you always want restricted

Instead of a wrapper, you set the GID flag directly on the app's binary. Every time it runs — from the menu, terminal, wherever — it automatically gets the no-internet group.

Find the Real Binary

This is important. Many apps have wrapper scripts. You need the actual ELF binary (Executable and Linkable Format — the compiled program file that Linux actually runs):

which firefox                              # might be /usr/bin/firefox
readlink -f "$(which firefox)"             # resolves symlinks
file "$(readlink -f "$(which firefox)")"   # should say "ELF 64-bit"

If file says "shell script" or "Python script", dig deeper — that script calls the real binary somewhere.

Apply setgid

sudo chown root:no-internet /path/to/real/elf/binary
sudo chmod 750 /path/to/real/elf/binary
sudo chmod g+s /path/to/real/elf/binary    # the magic: setgid bit

Now every process spawned from this binary inherits EGID = no-internet, which the firewall matches.

Verify

firefox & sleep 1
ps -eo pid,uid,egid,cmd | grep firefox
# EGID column should show your no-internet GID number

Rollback

sudo chmod g-s /path/to/real/elf/binary
sudo chown root:root /path/to/real/elf/binary
sudo chmod 755 /path/to/real/elf/binary

⚠️ Caveat: This doesn't work on Snap or Flatpak apps — they run in sandboxes with their own network stack. For Flatpak, use Flatseal (GUI) to toggle off "Network" permissions, or run flatpak override --user --unshare=network com.app.Name. For Snap, use snap connections app-name and snap disconnect app-name:network to revoke the network plug. Or install the app as a native .deb.

Option C: Service UID Match

Time: 3 minutes · Best for: Daemons like Jellyfin, Syncthing, qBittorrent

Services already run as dedicated system users. You just match their UID in the firewall. This is the strongest of the five options because a service can't change its own UID.

Find the UID

id -u jellyfin    # e.g., 112

Add UID Rules to UFW

Same as the GID rules above, but use --uid-owner 112 instead of --gid-owner. Paste into before.rules and before6.rules, then:

sudo ufw reload

Test

# Internet should be blocked:
sudo -u jellyfin curl -I -m 10 https://example.com && echo "FAIL" || echo "BLOCKED ✓"

# LAN should work (reaches a local Python HTTP server):
sudo -u jellyfin curl -I -m 10 http://192.168.1.10 && echo "LAN works ✓" || echo "FAIL"

The Ultimate Proof: LAN vs Internet

One of the best ways to verify your setup is to try reaching an external site and a local IP in the same process. Here is the result of that test:

Don't Forget: Allow Incoming on the Service Port

If your UFW default is "deny incoming" (it should be), LAN clients can't reach your service unless you explicitly allow the port:

sudo ufw allow from 192.168.0.0/16 to any port 8096 proto tcp

For Custom Services Without a Dedicated User

sudo adduser --system --group --no-create-home --shell /usr/sbin/nologin myservice
sudo passwd -l myservice
id -u myservice    # use this UID in rules

Option D: dpkg-divert + Wrapper

Time: 15 minutes · Best for: Chromium, Electron, multi-process apps

Note: dpkg-divert is a Debian/Ubuntu tool. If you're on Fedora, Arch, or another distro, you'll need to manually relocate the binary instead — the firewall rules themselves are distro-agnostic.

Chromium is special. It spawns renderer processes, GPU processes, utility processes — all from different code paths. A simple setgid on one binary won't catch them all.

The solution: use Debian's dpkg-divert to relocate the real binary, then put a wrapper at the original path. Every invocation — menu, terminal, child processes — goes through your wrapper.

The Full Setup

# 1. Create the group
sudo groupadd -f no-internet
getent group no-internet    # note the GID

# Add your user to the group so 'sg' doesn't prompt for a password
sudo usermod -aG no-internet $USER

# 2. Divert the real binary to a new location
sudo mkdir -p /usr/lib/chromium
sudo dpkg-divert --local --add --rename \
  --divert /usr/lib/chromium/chromium.distrib /usr/bin/chromium

# 3. Reinstall so the diverted file lands at the new path
sudo apt install --reinstall chromium

# 4. Lock down the real binary
sudo chown root:no-internet /usr/lib/chromium/chromium.distrib
sudo chmod 0750 /usr/lib/chromium/chromium.distrib

# 5. Put a shell wrapper at the original path
sudo tee /usr/bin/chromium > /dev/null <<'EOF'
#!/bin/bash
exec sg no-internet /usr/lib/chromium/chromium.distrib "$@"
EOF
sudo chmod 0755 /usr/bin/chromium

Add the GID firewall rules, reload UFW, and test.

Option D Variant: Compiled C Wrapper

Instead of a shell wrapper, you can compile a minimal C binary. It avoids spawning an extra bash process and the binary isn't human-readable (though strings will still reveal the path — see Security Limitations below).

Save as /tmp/sg-wrapper.c:

/* sg-wrapper.c — execv /bin/sg no-internet -- /usr/lib/chromium/chromium.distrib */
#define _GNU_SOURCE
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

int main(int argc, char *argv[]) {
    const char *group = "no-internet";
    const char *sg_path = "/bin/sg";
    const char *real_binary = "/usr/lib/chromium/chromium.distrib";

    int extra = argc - 1;
    /* count: sg_path + group + "--" + real_binary + extra_args + NULL */
    int sg_argc = 1 + 1 + 1 + 1 + extra + 1;
    char **sg_argv = calloc(sg_argc, sizeof(char *));
    if (!sg_argv) { fprintf(stderr, "calloc failed\n"); return 127; }

    int i = 0;
    sg_argv[i++] = (char *)sg_path;
    sg_argv[i++] = (char *)group;
    sg_argv[i++] = (char *)"--";
    sg_argv[i++] = (char *)real_binary;
    for (int j = 1; j < argc; ++j) sg_argv[i++] = argv[j];
    sg_argv[i] = NULL;

    execv(sg_path, sg_argv);
    fprintf(stderr, "execv(%s) failed: %s\n", sg_path, strerror(errno));
    /* free is technically unreachable if execv succeeds, but kept for completeness */
    free(sg_argv);
    return 126;
}

Compile and install:

gcc -O2 -s -o /tmp/sg-wrapper /tmp/sg-wrapper.c
sudo mv /tmp/sg-wrapper /usr/bin/chromium
sudo chown root:no-internet /usr/bin/chromium
sudo chmod 2751 /usr/bin/chromium    # setgid(2) + rwx(7) + r-x(5) + --x(1)

Surviving `apt upgrade`

Package updates can overwrite your changes. Protect them:

# Tell dpkg to enforce ownership/permissions
sudo dpkg-statoverride --add root no-internet 0750 /usr/lib/chromium/chromium.distrib

# Create a script that reapplies permissions
sudo tee /usr/local/sbin/reapply-noinet.sh > /dev/null <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
GROUP=no-internet
[ -e /usr/bin/chromium ] && chown root:$GROUP /usr/bin/chromium && chmod 2751 /usr/bin/chromium || true
[ -e /usr/lib/chromium/chromium.distrib ] && chown root:$GROUP /usr/lib/chromium/chromium.distrib && chmod 0750 /usr/lib/chromium/chromium.distrib || true
EOF
sudo chmod 755 /usr/local/sbin/reapply-noinet.sh

# Hook it into APT so it runs after every package update
sudo tee /etc/apt/apt.conf.d/99-reapply-noinet > /dev/null <<'EOF'
DPkg::Post-Invoke {"[ -x /usr/local/sbin/reapply-noinet.sh ] && /usr/local/sbin/reapply-noinet.sh";};
EOF

Rollback

sudo rm -f /usr/bin/chromium
sudo dpkg-divert --remove --rename /usr/bin/chromium
sudo apt install --reinstall chromium

Option E: Raw iptables / nftables

Best for: Systems that don't use UFW, or if you prefer direct control.

iptables

GID=1001  # your no-internet group ID

sudo iptables -I OUTPUT 1 -m owner --gid-owner $GID -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
sudo iptables -I OUTPUT 2 -m owner --gid-owner $GID -d 127.0.0.0/8 -j ACCEPT
sudo iptables -I OUTPUT 3 -m owner --gid-owner $GID -d 10.0.0.0/8 -j ACCEPT
sudo iptables -I OUTPUT 4 -m owner --gid-owner $GID -d 172.16.0.0/12 -j ACCEPT
sudo iptables -I OUTPUT 5 -m owner --gid-owner $GID -d 192.168.0.0/16 -j ACCEPT
sudo iptables -A OUTPUT -m owner --gid-owner $GID -j LOG --log-prefix "NOINTERNET: "
sudo iptables -A OUTPUT -m owner --gid-owner $GID -j REJECT

Persist with:

sudo apt install iptables-persistent
sudo netfilter-persistent save

nftables

Add to /etc/nftables.conf:

table inet lanlock {
  chain output {
    type filter hook output priority 0;
    meta skgid 1001 ct state related,established accept
    meta skgid 1001 ip daddr 127.0.0.0/8 accept
    meta skgid 1001 ip daddr 10.0.0.0/8 accept
    meta skgid 1001 ip daddr 172.16.0.0/12 accept
    meta skgid 1001 ip daddr 192.168.0.0/16 accept
    meta skgid 1001 ip6 daddr ::1 accept
    meta skgid 1001 ip6 daddr fe80::/10 accept
    meta skgid 1001 counter log prefix "NOINTERNET: "
    meta skgid 1001 drop
  }
}

sudo nft -f /etc/nftables.conf
sudo systemctl enable --now nftables

The Security Flaw Nobody Talks About

Now that you know how to set this up, let's talk about when it's actually enough — because the GID-based approach (Options A, B, and D) has a fundamental bypass that most guides never mention.

The Problem: EGID vs Supplementary Groups

The firewall's --gid-owner match checks the process's EGID (Effective Group ID) — not its supplementary group list. Here's what that means in practice:

How the app is launched	Process EGID	Firewall matches?	Internet?
Via wrapper (`sg no-internet ...`)	`no-internet` (1001)	✅ Yes	❌ Blocked
Directly (`/usr/lib/chromium/chromium.distrib`)	User's primary group (1000)	❌ No	✅ Full access

When a user runs a binary directly, their primary group becomes the EGID. The no-internet supplementary group membership is irrelevant to the firewall.

And there's a catch-22: sg (which the wrapper uses) requires the user to be a member of the no-internet group. But if they're a member, they also have permission to execute the chmod 0750 binary directly — bypassing the wrapper entirely.

"What If I Hide the Binary Path?"

You might think: "I'll compile the wrapper as a C binary so users can't read the script to find the real path." That doesn't work either:

Attempt	Why it fails
Compiled C wrapper	`strings /usr/bin/chromium` reveals the embedded path
Random filename	`ps aux` and `/proc/PID/exe` expose it at runtime
setgid on the binary itself	Chromium and Firefox refuse to run with setgid (browser security feature)

So When IS the GID Approach Good Enough?

✅ Self-discipline — you want YOUR OWN app to stop phoning home (telemetry, metadata downloads, auto-updates)
✅ Services and daemons — Option C uses UID matching, which IS unbypassable since processes can't change their own UID
✅ Non-technical users — people who won't think to look for the diverted binary

When You Need Something Stronger

❌ Technical users who actively want to bypass your restrictions
❌ Multi-user machines where you're enforcing policy
❌ Any scenario where "security through obscurity" isn't acceptable

For those cases, keep reading.

Bypass-Proof Alternatives (Not-Tested By Me)

When the GID approach isn't enough, here are three methods that provide real, kernel-enforced isolation.

Note: I haven't personally tested these alternatives end-to-end. They're included for completeness based on documentation and community guides. If you try any of these and find issues (or get them working), feel free to reach out.

Alternative 1: Separate User + UID Match

Run the app as a completely separate user. UID matching cannot be bypassed — a user can't change their own UID.

# Create a restricted user
sudo adduser --disabled-password --gecos "" --shell /usr/sbin/nologin chromium-user
sudo passwd -l chromium-user
id -u chromium-user    # use this UID in UFW rules (same format as Option C)

# Allow X11 display access
xhost +SI:localuser:chromium-user

# Launch
sudo -u chromium-user chromium

Tradeoffs: You lose your keyring, D-Bus session, bookmarks, and cookies from your main user. Wayland compositors may block other users entirely. But the network restriction is absolute.

Alternative 2: Firejail (Easiest True Isolation)

Firejail uses kernel network namespaces under the hood. No firewall rules needed — the app physically cannot see the external network.

sudo apt install firejail

# No network at all — this works reliably
firejail --net=none chromium

⚠️ My experience: firejail --net=none works perfectly — the app has zero network access. However, I was unable to get LAN-only mode working using the theoretical setup for reference, but your mileage may vary.

LAN-only (theoretical):

firejail --netfilter=/etc/firejail/lan-only.net chromium

Create /etc/firejail/lan-only.net:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT DROP [0:0]
-A OUTPUT -d 127.0.0.0/8 -j ACCEPT
-A OUTPUT -d 10.0.0.0/8 -j ACCEPT
-A OUTPUT -d 172.16.0.0/12 -j ACCEPT
-A OUTPUT -d 192.168.0.0/16 -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
COMMIT

Alternative 3: Network Namespaces (Manual, Full Control)

For maximum control, create a network namespace directly. No extra packages needed.

# Create a namespace with no external network
sudo ip netns add no-inet

# Run the app inside it
sudo ip netns exec no-inet sudo -u $USER chromium

# Optional: Add LAN-only access via a veth pair
sudo ip link add veth-host type veth peer name veth-jail
sudo ip link set veth-jail netns no-inet
sudo ip addr add 192.168.100.1/24 dev veth-host
sudo ip link set veth-host up
sudo ip netns exec no-inet ip addr add 192.168.100.2/24 dev veth-jail
sudo ip netns exec no-inet ip link set veth-jail up
sudo ip netns exec no-inet ip link set lo up

Quick Comparison

Threat Model	Best Solution
Block your own apps from phoning home	GID wrapper (Option A/D) — simple, good enough
Block a daemon/service	UID owner-match (Option C) — unbypassable
Restrict technical/untrusted users	Separate user + UID match (Alt 1)
True network sandbox, easy setup	Firejail (Alt 2)
Full manual control, no dependencies	Network namespace (Alt 3)
Enterprise/production	AppArmor + containers

Troubleshooting

"sg: no such group"
→ Group doesn't exist yet. Run sudo groupadd -f no-internet.

Internet is still working after adding rules
→ Double-check the numeric UID/GID in your rules matches reality. Make sure you pasted the block right after the :ufw-before-output line, not at the bottom. Run sudo ufw reload.

UFW reload fails
→ Syntax error in your rules. Test before applying: sudo iptables-restore --test < /etc/ufw/before.rules. If it fails, restore your backup.

It works, but breaks after reboot
→ You might have iptables-persistent installed, which conflicts with UFW. Remove it: sudo apt remove iptables-persistent. Let UFW handle everything.

setgid isn't working
→ You probably applied it to a shell script wrapper, not the real ELF binary. Use readlink -f $(which app) and file to find the actual binary.

Snap/Flatpak apps are unaffected
→ They run in sandboxes with their own network stack. Flatpak: Use Flatseal (GUI) to toggle off "Network" permissions, or run flatpak override --user --unshare=network com.app.Name. Snap: Use snap connections app-name and snap disconnect app-name:network to revoke the network plug. Or install the app as a native .deb.

DNS seems to leak
→ systemd-resolved runs on 127.0.0.53. Since we allow 127.0.0.0/8, DNS resolves even for blocked apps — but the actual connections still get rejected.

Testing Checklist

After setting up any option, run through this:

# 1. Group exists and GID is correct?
getent group no-internet
# Expected: no-internet:x:<GID>:

# 2. Service UID correct? (Option C only)
id -u jellyfin
# Expected: numeric UID, e.g., 107

# 3. File ownership and permissions correct? (Options B/D)
stat -c "%n: %U %G %a" /usr/lib/chromium/chromium.distrib /usr/bin/chromium
# Expected: real binary → root:no-internet 0750, wrapper → per your policy

# 4. Running processes have correct EGID/UID?
ps -eo pid,ppid,uid,euid,gid,egid,cmd | egrep 'chromium|jellyfin|firefox'
# Look for: EGID == no-internet GID (Options A/B/D) or UID == service UID (Option C)

# 5. Internet blocked?
sg no-internet -c 'curl -I -m 10 https://example.com' && echo "FAIL" || echo "BLOCKED ✓"
# For services:
sudo -u jellyfin curl -I -m 10 https://example.com && echo "FAIL" || echo "BLOCKED ✓"

# 6. LAN still works?
sg no-internet -c 'curl -I -m 10 http://192.168.1.1' && echo "LAN works ✓" || echo "FAIL"

# 7. Check firewall logs (if LOG rules added)
sudo journalctl -k --since "10 minutes ago" | grep -i 'Blocked\|NOINTERNET'

Emergency Rollback

If something goes wrong, these commands restore everything:

# Restore UFW backups
sudo cp /root/before.rules.bak /etc/ufw/before.rules
sudo cp /root/before6.rules.bak /etc/ufw/before6.rules
sudo ufw reload

# If you need immediate connectivity recovery
sudo iptables -I OUTPUT 1 -m owner --gid-owner <GID> -j ACCEPT
# Remove when fixed:
sudo iptables -D OUTPUT -m owner --gid-owner <GID> -j ACCEPT

# Last resort — disable the entire firewall
sudo ufw disable
# Fix your rules, then: sudo ufw enable

# Undo dpkg-divert (Option D)
sudo dpkg-divert --remove --rename /usr/bin/chromium
sudo apt install --reinstall chromium

🎬 Watch it in Action: Full GUI Demo

This walkthrough puts the system to the test using a real-world browser (Google Chrome). Here’s exactly what you’ll see:

🚫 The Block
Chrome tries to reach Google—and fails instantly while the firewall rules are active.

🌐 LAN Routing
Despite the block, Chrome successfully loads a local dashboard on your LAN, proving internal traffic still works flawlessly.

🎛️ The Control
With a simple toggle:

ufw disable → restores full internet access
ufw enable → locks everything down again

Curious to see it all in action? Watch the full high-resolution 75-second demo:

🔗 https://khadirullah.com/blog/block-internet-linux-apps/#watch-it-in-action-full-gui-demo

✨ A complete visual walkthrough of the interface, behavior, and control flow—from block to restore.

Summary

The GID-based approach (Options A–E) is a clean, elegant way to restrict app networking — and it's good enough for most personal use cases. If you want to stop Jellyfin from downloading metadata, or prevent a game from phoning home, it works perfectly.

But if you need real enforcement against users who know their way around Linux, the GID approach has a fundamental EGID bypass. For those cases, use UID matching (unbypassable for services), Firejail (easiest for desktop apps), or network namespaces (maximum control).

Tested on Debian 13 (Trixie) with UFW. Should work on any Debian/Ubuntu-based distro with kernel 4.x+.

I Built an Interactive SVG Viewer Because Static Diagrams Deserve Better

Khadirullah Mohammad — Wed, 11 Feb 2026 13:23:28 +0000

As developers, we love clear documentation. Use Case diagrams, Cloud Architectures, Flowcharts — they are the lifeblood of understanding complex systems. Tools like Mermaid.js, PlantUML, and Draw.io are fantastic for creating them.

But viewing them? That experience is often stuck in the past.

If you export a complex architecture diagram as an SVG and embed it on your docs site, it's just a static image. The text is too small to read, you can't search for that one specific microservice, and if you zoom with your browser, the whole page breaks.

I looked for a library to solve this. I found D3.js (too complex for just viewing) and Leaflet (too heavy for a diagram). I didn't want to write hundreds of lines of code just to let a user zoom into a flowchart.

So, I built DiagView.

Demo

What is DiagView?

DiagView is a feature-rich, interactive wrapper that gives your static SVGs superpowers.

It is built on top of the excellent panzoom library, which handles the low-level matrix math for smooth 60fps zooming and panning. But while panzoom gives you the engine, DiagView gives you the entire car.

Feature Overview

Feature	Description
🔍 Deep Search	Traverses the SVG DOM to find and highlight matching nodes
📤 Multi-Format Export	PNG, SVG, PDF, WebP, or copy to clipboard
🎯 Meeting Mode	Built-in laser pointer for remote presentations
🔗 Share Links	Generate URLs that preserve zoom/pan state
⌨️ Keyboard Navigation	Arrows to pan, +/- to zoom, F to search
🌗 Auto-Theming	Detects light/dark mode automatically
📱 Mobile-First Touch	Pinch-to-zoom, double-tap to reset

The Landscape: Why Wasn't This Already Solved?

Before writing any code, I scoured npm and GitHub. Here's what I found:

D3.js — The titan of data visualization. But D3 is for creating graphics from data, not for viewing pre-made SVGs.

svg-pan-zoom — A focused library for adding pan/zoom to SVGs. But it's just the engine — no UI, no search, no export.

Leaflet.js — The standard for interactive maps. Overkill for a simple flowchart.

The gap was clear: I needed a batteries-included solution — something that would just work with a single init() call.

Quick Start

CDN (Fastest)

<!-- Panzoom (optional, for zoom/pan) -->
<script src="https://cdn.jsdelivr.net/npm/@panzoom/panzoom@4.5.1/dist/panzoom.min.js"></script>

<!-- DiagView -->
<script src="https://cdn.jsdelivr.net/npm/diagview@1.0.0/dist/diagview.umd.min.js"></script>

<!-- Your diagram -->
<div class="diagram">
  <svg><!-- Your SVG content --></svg>
</div>

<!-- Initialize -->
<script>
  DiagView.init();
</script>

NPM

npm install diagview @panzoom/panzoom

import DiagView from 'diagview';

DiagView.init({
  layout: 'floating',
  accentColor: '#3b82f6',
});

Flexible Layouts

DiagView supports three layout modes to fit your design:

Layout	Best For
Header	Classic top-bar controls, documentation sites
Floating	Clean HUD-style buttons on hover, minimal UIs
Off	Invisible UI, the diagram itself is the trigger

Under the Hood: Technical Decisions

The Search Engine

This was the feature I was most proud of. The search system:

Pre-Caches Candidates — On first open, queries all text elements and stores them in a WeakMap
Uses Dirty Checking — Before writing to the DOM, checks if values have changed
Batches Updates — All DOM mutations are wrapped in requestAnimationFrame

The result? Searching through diagrams with 2,500+ nodes is instant.

The Export System

The export module handles edge cases:

Robust Dimension Calculation — Uses getBBox() to find actual content area
Cross-Origin Font Handling — Inlines Google Fonts for consistent exports
High-DPI Scaling — Up to 6x resolution for print-quality images

Optional Panzoom Dependency

I made panzoom an optional peer dependency:

With panzoom: Full zoom, pan, touch gestures
Without panzoom: Fullscreen, search, and export still work

This keeps DiagView usable even in constrained environments.

Bundle Size

Metric	Size
Raw Minified	~70 KB
Gzipped (Transfer)	~19 KB

For context, that's smaller than a single hero image. And it includes all CSS, SVG icons, and the entire UI framework.

Try It Out

I built this to scratch my own itch. If you write technical documentation for a living, I think you'll find it useful too.

🧪 Live Demo: khadirullah.github.io/diagview
⭐ GitHub: github.com/khadirullah/diagview
📦 NPM: npmjs.com/package/diagview

Have feedback or found a bug? Open an issue on GitHub.

Originally published on khadirullah.com

DEV Community: Khadirullah Mohammad

Setting Up Custom Domain Email with SPF, DKIM, and DMARC

Why Custom Domain Email?

Why Zoho Mail?

Step 1: Add Your Domain to Zoho

Step 2: MX Records (Mail Exchange)

Step 3: SPF (Sender Policy Framework)

What Is SPF?

How It Works

The Record

Step 4: DKIM (DomainKeys Identified Mail)

What Is DKIM?

How It Works

The Record

Step 5: DMARC (Domain-based Message Authentication, Reporting & Conformance)

What Is DMARC?

Why Alignment Matters

The Record

DMARC Policy Levels

Step 6: Email Aliases and Routing

The Setup

How Aliases Work

The Security Catch with Aliases

Folder-Based Rules

How All the Records Work Together

Verifying Your Setup

Check DNS Records

Online Tools

Send a Test Email

But Your Emails Can Still Land in Spam

1. Spammy Subject Lines or Body Content

2. IP or Domain Reputation

3. Domain and IP Warming

4. Recipients Marking You as Spam

Summary of All DNS Records

What I Learned

A Quick Warning: My Personal Choice on Using Custom Domain Email for Logins

The Objections I Considered

Important Context

What I Changed

Further Reading

How to Block Internet Access for Any Linux App (While Keeping LAN)

Why UFW?

How Does This Actually Work?

Which Approach Should You Use?

Quick Glossary

Before You Start: Back Up Everything

The Firewall Rules (The Core of Everything)

Where Exactly to Paste

For Desktop Apps (GID Match)

For Services (UID Match — /etc/ufw/before.rules)

Why This Order?

Safe Way to Edit

Option A: Quick Wrapper Script

Setup

3. Create the wrapper script

Usage

Verify It Works

Option B: setgid on the Binary

Find the Real Binary

Apply setgid

Verify

Rollback

Option C: Service UID Match

Find the UID

Add UID Rules to UFW

Test

The Ultimate Proof: LAN vs Internet

Don't Forget: Allow Incoming on the Service Port

For Custom Services Without a Dedicated User

Option D: dpkg-divert + Wrapper

The Full Setup

Option D Variant: Compiled C Wrapper

Surviving apt upgrade

Rollback

Option E: Raw iptables / nftables

iptables

nftables

The Security Flaw Nobody Talks About

The Problem: EGID vs Supplementary Groups

For Services (UID Match — `/etc/ufw/before.rules`)

Surviving `apt upgrade`