Rich Gibbs

Ubuntu/Debian EC2 hardening checklist (2026)

Sun, 10 May 2026 00:20:00 +0000

You spun up an EC2 instance, pointed a domain at it, and now real traffic — and real bots — can reach it. Most “hardening guides” online are either copy-paste cargo cult from 2014 or vendor whitepapers selling a SIEM. This is the version I actually run on Ubuntu 22.04, Ubuntu 24.04, and Debian 12 boxes, written for solo founders and small teams who don’t have a dedicated security person.

Work through it top to bottom on a fresh box. On an existing box, treat it as a diff: read each section, run the audit command, fix the gap, move on.

Why this checklist

The threats most small EC2 fleets actually get hit by aren’t APTs. They’re:

SSH brute force from random botnets
Exposed services you forgot were listening (Redis, Postgres, Docker API, an old admin panel)
Stolen IAM credentials via SSRF on a misconfigured app reaching the EC2 metadata service
An unpatched kernel or library with a known CVE
A compromised dependency or container image that opens a reverse shell

Everything below is aimed at those concrete risks. There’s no checklist on earth that makes you “secure” — but a tight baseline closes the cheap, automated attack paths so an attacker has to actually work.

Threat model assumptions

Before any commands, make these explicit:

This is a single-tenant Linux server (or small fleet) on AWS EC2.
You are the only admin, or there’s a tiny ops team with shared SSH keys.
The instance runs a public-facing web app and/or some background workers.
You’re not in a regulated environment yet (PCI/HIPAA/SOC 2 controls are not what this checklist gives you).
You can tolerate a few minutes of downtime to reboot for kernel updates.

If any of those don’t match, adjust before applying.

1. SSH

SSH is still the single biggest “front door” on a Linux server.

Use keys, not passwords. Disable root login. Limit who can log in.

Edit /etc/ssh/sshd_config (or drop a file in /etc/ssh/sshd_config.d/ on Ubuntu 22.04+):

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
PermitEmptyPasswords no
X11Forwarding no
MaxAuthTries 3
LoginGraceTime 20
ClientAliveInterval 300
ClientAliveCountMax 2
AllowUsers ubuntu deploy

Replace ubuntu deploy with the actual non-root accounts you use. Then validate and reload:

sudo sshd -t
sudo systemctl reload ssh

Optional but worth it on small boxes:

Move SSH off port 22. It doesn’t stop a determined attacker, but it cuts log noise from internet-wide scanners by ~95%. If you do this, update the EC2 security group too.
Restrict the SSH security group to your office/VPN IP, your home IP, or a bastion. 0.0.0.0/0 on port 22 is a choice, not a default.
Install fail2ban for cheap brute-force throttling:

bash sudo apt-get update && sudo apt-get install -y fail2ban sudo systemctl enable --now fail2ban

Audit:

sudo sshd -T | grep -Ei 'permitrootlogin|passwordauth|pubkeyauth|allowusers|port'

2. Firewall and listeners

The cheapest mistake on EC2 is a service binding to 0.0.0.0 that you thought was on 127.0.0.1. Defense in depth: lock it down at the OS and at the security group.

See what’s actually listening:

sudo ss -tulpn

Anything bound to 0.0.0.0 or :: that isn’t your web server, SSH, or something you explicitly want public is a finding. Common offenders: Redis (6379), Postgres (5432), MySQL (3306), Docker API (2375/2376), Elasticsearch (9200), Memcached (11211), node dev servers.

Bind to localhost in the service config (e.g. bind 127.0.0.1 in /etc/redis/redis.conf, listen_addresses = 'localhost' in postgresql.conf).

Then layer UFW on top:

sudo apt-get install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

On the AWS side, the security group is your real perimeter. Rules of thumb:

One SG per role (web, db, worker), not one giant SG that allows everything internally.
DB and cache SGs accept traffic only from the app SG, never from 0.0.0.0/0.
SSH SG limited to known IPs or a bastion/VPN SG.
No 0.0.0.0/0 on anything except 80/443 on the public web tier.

Audit:

sudo ss -tulpn | awk '$5 ~ /0\.0\.0\.0|\[::\]/'
sudo ufw status numbered

Cross-check the AWS console / CLI:

aws ec2 describe-security-groups \
  --query 'SecurityGroups[].{Name:GroupName,Ingress:IpPermissions}' \
  --output json

3. OS updates and reboots

Unpatched kernels and OpenSSL/libc libraries are the most boring and most common way servers get owned.

Enable unattended security upgrades:

sudo apt-get install -y unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades

Check /etc/apt/apt.conf.d/50unattended-upgrades includes the security pocket and that Unattended-Upgrade::Automatic-Reboot is set deliberately. On a single box with a real user, automatic reboots at 3am can be fine; on production-critical workers, prefer notification + manual.

Patch now:

sudo apt-get update
sudo apt-get -y dist-upgrade
sudo apt-get -y autoremove --purge

Detect a needed reboot:

[ -f /var/run/reboot-required ] && cat /var/run/reboot-required.pkgs

If the kernel was updated, schedule a reboot. Live-patching (Ubuntu Pro / Livepatch) is great if you’re paying for it, but it doesn’t cover everything — you’ll still need occasional reboots.

Audit:

apt list --upgradable 2>/dev/null
uname -r

4. Admin surface

Every account that can sudo is part of your admin surface. Trim it.

getent group sudo
getent group adm
awk -F: '($3 == 0) {print}' /etc/passwd   # any extra UID 0 account is a finding

Rules:

One sudo user per real human, no shared logins where avoidable.
Service accounts (www-data, postgres, deploy) should not have shell or sudo. Use usermod -s /usr/sbin/nologin <user> if needed.
Rotate or remove SSH keys when someone leaves the team. ~/.ssh/authorized_keys for every login user is your source of truth — review it.
Disable cloud-init’s default password if any (cloud-init shouldn’t set one on official AMIs, but check).
If you must allow sudo without a password for automation, scope it to specific commands in /etc/sudoers.d/, not blanket NOPASSWD: ALL.

Audit:

for u in $(awk -F: '$7 ~ /sh$/ {print $1}' /etc/passwd); do
  echo "== $u =="; sudo cat /home/$u/.ssh/authorized_keys 2>/dev/null
done

5. EC2 metadata service (IMDSv2)

This one is non-negotiable in 2026. The EC2 instance metadata service hands out IAM role credentials. With IMDSv1 enabled, any server-side request forgery (SSRF) bug in your app can pop those credentials and walk into your AWS account.

Force IMDSv2 only, with a low hop limit:

TOKEN=$(curl -sX PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 60")
curl -sH "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/instance-id

If that works but the same call without a token also works, you’re still on IMDSv1. For old AMIs, containers, or ASGs you cannot blindly rotate, follow the IMDSv2 migration sequence before making it mandatory.

Enforce v2 on the instance (run from your laptop with the AWS CLI):

aws ec2 modify-instance-metadata-options \
  --instance-id i-xxxxxxxxxxxxxxxxx \
  --http-tokens required \
  --http-endpoint enabled \
  --http-put-response-hop-limit 1

hop-limit 1 means a container or proxy can’t trivially relay a request to the metadata service. If you run Docker with bridge networking, you may need 2 — but start at 1, raise only if needed, and never to 64.

Also: the IAM role attached to the instance should be least privilege. “Read this one S3 bucket and write to this one log group” beats AdministratorAccess every time.

Audit:

aws ec2 describe-instances \
  --query 'Reservations[].Instances[].[InstanceId,MetadataOptions.HttpTokens,MetadataOptions.HttpPutResponseHopLimit]' \
  --output table

Anything where HttpTokens is not required is a finding.

Mid-article CTA

If you’d rather have someone else go through this list on your servers and hand you back a clear report, that’s exactly what Tuck Sentinel QuickCheck does: a one-shot, read-only audit of a single Linux box with prioritized findings and copy-pasteable fixes. You can see what the output looks like in this sample report before deciding.

Back to the checklist.

6. Logging and time sync

You can’t investigate what you didn’t record, and you can’t correlate logs that disagree on what time it is.

Time sync. Ubuntu 22.04+ and Debian 12 ship systemd-timesyncd or chrony. Either is fine, just make sure one is running:

timedatectl
# or
chronyc tracking

If you’re on AWS, the local time source 169.254.169.123 is reliable and low-latency. chrony config example:

server 169.254.169.123 prefer iburst minpoll 4 maxpoll 4

Logging. journald is the default. A few sane settings in /etc/systemd/journald.conf:

Storage=persistent
SystemMaxUse=1G
SystemMaxFileSize=128M
ForwardToSyslog=no

Then:

sudo systemctl restart systemd-journald

For anything beyond a single box, ship logs off the instance — CloudWatch Logs, a Loki/Grafana stack, or any hosted log service. The reason isn’t compliance, it’s that the first thing an attacker tries to do is rm /var/log/* and journalctl --rotate --vacuum-time=1s.

Auditd is worth installing if you want a record of which user ran which command:

sudo apt-get install -y auditd
sudo systemctl enable --now auditd

You don’t need elaborate rules to start; the defaults plus shipping /var/log/audit/audit.log off-box is already a huge upgrade.

Audit:

journalctl --disk-usage
timedatectl | grep 'System clock synchronized'

7. Backups and restore drills

A backup you’ve never restored is a wish, not a backup.

For a small EC2 setup:

Use AWS Backup or scheduled EBS snapshots for the volume(s).
For databases, also take logical backups (pg_dump, mysqldump) on a schedule and copy them to S3 with versioning + lifecycle to Glacier.
Encrypt at rest (EBS encryption + S3 SSE-KMS). On modern AWS regions/accounts, EBS encryption-by-default should be on — check it.
Keep at least one backup copy in a different AWS account or region. Ransomware-style attackers will delete in-region snapshots if they get the chance.

Restore drill — once a quarter, on a throwaway instance:

Pick a recent snapshot/dump.
Spin up a new instance/volume from it.
Verify the app starts and recent data is present.
Time how long it took. That’s your real RTO.

If you’ve never done step 4, you don’t know your RTO; you have a hope.

Audit:

aws ec2 describe-snapshots --owner-ids self \
  --query 'Snapshots[?StartTime>=`2026-01-01`].[SnapshotId,StartTime,VolumeSize,Description]' \
  --output table

8. Docker basics (if applicable)

If you don’t run Docker on the box, skip this. If you do, the most common foot-guns:

Don’t expose the Docker daemon over TCP. 2375 unauthenticated is root-on-box for anyone who can reach it. Use the local socket (/var/run/docker.sock) and SSH for remote control.
Mind the -p flag. -p 5432:5432 binds to 0.0.0.0 and bypasses UFW on most Docker setups (Docker writes its own iptables rules). If you only need the port locally, use -p 127.0.0.1:5432:5432.
Run containers as non-root where possible. USER directive in your Dockerfile, or --user 1000:1000 at runtime.
Pin base images to a digest (FROM ubuntu:24.04@sha256:...) for production, and rebuild on a schedule to pick up CVE fixes.
Don’t bind-mount the Docker socket into containers unless you fully understand that’s equivalent to giving that container root on the host.
Set --read-only and --cap-drop=ALL for containers that don’t need to write to their filesystem or hold extra capabilities; add back only what’s needed.

A useful audit one-liner:

docker ps --format '{{.Names}} {{.Ports}}' | grep -E '0\.0\.0\.0|:::'

Anything in that list is reachable from the public internet (modulo the security group). Decide if that’s intentional.

For containerd/k8s setups this barely scratches the surface — but on a single EC2 box running a few containers, those bullets close ~80% of the cheap holes.

What this is not

Be honest with yourself about what a checklist like this does and doesn’t do.

It is not a penetration test. Nobody is exploiting your application logic, your auth flows, or your business rules here. A pentest is a different (and more expensive) thing.
It is not compliance. SOC 2, HIPAA, PCI, ISO 27001 all require documented policies, evidence collection, access reviews, vendor management, and a lot more. A hardened box is part of that, not a substitute.
It is not a guarantee. New CVEs ship every week. Your application code changes. Someone leaks a key on GitHub. Hardening is a continuous practice, not a one-time event.
It is not opinionated about your app stack. TLS configuration, WAF rules, secrets management, dependency scanning, CI/CD security — all out of scope here.

What it does do: dramatically reduce the set of “stupid ways your server gets owned by a bot at 3am” and give you a baseline you can re-run on every new instance.

End-article CTA

If you got this far and want to skip the manual audit, that’s exactly what I built Tuck Sentinel QuickCheck for: a single-instance, read-only Linux audit that runs the kind of checks above and produces a prioritized report with concrete fixes — no agent left behind, no ongoing access. Take a look at the sample report to see exactly what you’d get.

Either way: run the checklist. Future-you will thank present-you.

About Tuck Sentinel

Tuck Sentinel is a small, focused security tooling project from indie operator Rich Gibbs. It produces practical, no-nonsense audits and content for solo founders and small teams running their own Linux infrastructure — the kind of work most SOC platforms ignore because the deal size is too small. Start with QuickCheck if you want a one-shot review of a single server.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Ubuntu/Debian EC2 hardening checklist (2026)",
  "description": "A practical 2026 hardening checklist for Ubuntu and Debian EC2 instances: SSH, UFW, IMDSv2, updates, logging, backups, and Docker basics.",
  "author": {
    "@type": "Person",
    "name": "Rich Gibbs",
    "url": "https://richgibbs.dev/"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Tuck Sentinel",
    "url": "https://richgibbs.dev/"
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://richgibbs.dev/blog/ubuntu-debian-ec2-hardening-checklist-2026/"
  },
  "image": "https://richgibbs.dev/og/ubuntu-debian-ec2-hardening-2026.png",
  "datePublished": "2026-05-10",
  "dateModified": "2026-05-10",
  "keywords": "ubuntu, debian, ec2, hardening, security, devops, sysadmin, aws, imdsv2, ssh, ufw",
  "inLanguage": "en"
}

The Indie Founder's VPS Security 101

Sun, 10 May 2026 00:22:00 +0000

You shipped the thing. It runs on one Linux box at DigitalOcean or Hetzner or wherever. Customers are starting to show up, and somewhere in the back of your head a little voice is asking: is this thing actually safe?

This guide is for that voice.

It’s written for solo founders and very small teams who are not security professionals but can copy a command into a terminal. The goal is “secure enough that you can sleep” — not “audit-grade fortress.” Those are different jobs, and treating one like the other is how you waste a weekend installing seven intrusion detection tools and shipping nothing for a month.

What “secure enough” looks like for one box

For a single VPS running your SaaS, “secure enough” is a short list:

Nobody can log in as root from the internet.
Logging in requires a key you have, not a password someone could guess.
Only the ports you actually use are open.
The OS gets security patches automatically.
You’d notice if something obviously bad started happening.
If the disk caught fire tomorrow, you could rebuild from a backup before the end of the day.

That’s the whole bar. Everything else is optimization. Hit those six and you’ve already done more than the majority of small-team production servers I’ve seen.

First-day setup

Do these once, when the server is fresh. They take about twenty minutes.

1. Create a non-root user with sudo

Logging in as root is a footgun. One typo and you’ve nuked the box. Make a normal user instead.

# As root, on a fresh server
adduser deploy
usermod -aG sudo deploy

Pick a real password for deploy even though you’ll be using SSH keys — you’ll need it for sudo prompts.

On your laptop, if you don’t already have a key:

ssh-keygen -t ed25519 -C "you@laptop"

Copy it to the server:

ssh-copy-id deploy@your.server.ip

Now log in as deploy and confirm sudo works:

ssh deploy@your.server.ip
sudo whoami   # should print: root

Once you’re sure key login works, lock down SSH. Edit /etc/ssh/sshd_config (or drop a file in /etc/ssh/sshd_config.d/):

sudo tee /etc/ssh/sshd_config.d/99-hardening.conf >/dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
EOF

sudo sshd -t          # test config — must print nothing
sudo systemctl reload ssh

Do not close your existing SSH session yet. Open a second terminal and confirm you can log in fresh. If that works, you’re good. If it doesn’t, you’ve still got the first session to fix things.

3. Turn on the firewall

Ubuntu ships with ufw, which is a friendly wrapper around iptables/nftables. Default-deny inbound, allow only what you need:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

If you don’t run a web server on this box, drop the 80/443 lines. The rule is simple: open a port only when something on the box actually needs to listen on it.

4. Enable automatic security updates

Most successful attacks are not clever zero-days — they’re known bugs in software you forgot to patch. Let the OS patch itself.

sudo apt update
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades   # answer "Yes"

Then check /etc/apt/apt.conf.d/50unattended-upgrades and make sure security updates are uncommented. On Ubuntu the default config already covers ${distro_id}:${distro_codename}-security, which is what you want.

For peace of mind, make it tell you when reboots are needed and when to install them:

sudo tee /etc/apt/apt.conf.d/51auto-reboot >/dev/null <<'EOF'
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";
EOF

Pick a time when nobody’s using the app. Yes, this means the box reboots itself sometimes. That’s fine. Your app should already survive a reboot — and if it doesn’t, that’s a bigger problem than security.

That’s first-day setup. Non-root sudo user, keys-only SSH, default-deny firewall, automatic patching. You’re now ahead of a lot of production servers.

Worried you missed something on first-day setup?

Run a free QuickCheck on your server →

It’s a read-only scan that flags the boring stuff: SSH still allows passwords, port 22 open to the world, no automatic updates configured, sketchy listening services, and so on. No agent, no signup wall. Here’s a sample report if you’d like to see the format first.

What to actually monitor

You don’t need a SIEM. You need a few things you can eyeball once a week (or get a tiny script to email you about). For a single VPS, this short list catches almost everything that matters.

Failed logins

If somebody is hammering your SSH port, this shows it:

sudo journalctl -u ssh --since "24 hours ago" | grep -i "failed\|invalid"

A handful of attempts per day is internet background noise. Thousands per hour from one IP is worth blocking with ufw or installing fail2ban.

Listening ports

What’s actually accepting connections on this box? Run this every so often and make sure nothing surprising is there:

sudo ss -tulpn

You’re looking for things bound to 0.0.0.0: or :::. Anything bound to 127.0.0.1 is fine — only your box can talk to it. The classic mistake: running a dev database with bind = 0.0.0.0 and no password. Don’t do that.

Disk free

Servers don’t usually die from hackers. They die from full disks at 3 AM.

df -h /
du -sh /var/log /var/lib/docker 2>/dev/null

If / is over 80% full, plan on cleaning it up before it hits 100% and your database refuses to write.

Package updates available

Even with unattended-upgrades, it’s worth a manual sanity check now and then:

sudo apt update
apt list --upgradable 2>/dev/null

And: is a reboot pending after a kernel update?

[ -f /var/run/reboot-required ] && cat /var/run/reboot-required

If yes, schedule one. A patched kernel that hasn’t been booted into is just a download.

You can wire any of these into a weekly cron that emails you a one-page digest. Five lines of bash. Don’t overthink it.

Backups and restore drills

This is the boring section everyone skips. Skip it and you have a hobby project, not a business.

The minimum viable backup setup for a single VPS:

Database: nightly dump (pg_dump, mysqldump, or your equivalent), encrypted, sent off-box. To S3, B2, or any object store. Keep at least 7 daily and 4 weekly copies.
User-uploaded files: same deal — sync to object storage on a schedule. restic and rclone both work fine.
Config: keep it in git. If your nginx.conf lives only on the server, it’s already half-lost.

That’s the easy part. Here’s the part people skip:

Actually do a restore. From scratch. On a fresh VPS. Once.

Spin up a new box. Pull last night’s backup. Restore the database. Boot the app. Did it work? How long did it take? What did you forget? (Spoiler: an environment variable, an SSL cert, a cron job, or a system package.)

If you’ve never done this drill, you don’t have backups. You have files you hope will work. There is a meaningful difference, and you really, really don’t want to discover it during an outage.

Re-do the drill at least once a year, or any time you make a big infrastructure change.

Don’t over-do it

There is a tempting path where, in the name of “being thorough,” you install:

An intrusion detection system
A second intrusion detection system in case the first one misses something
A file integrity monitor
A custom auditd ruleset you found on a blog
An EDR agent
A SIEM forwarder

…on a VPS that hosts one Rails app and gets 200 visitors a day.

Don’t. Each of these has a cost: CPU, memory, alert noise you’ll learn to ignore, and your time. For one small box, the basics in this article handle 95% of realistic risk. Adding more tools without tuning them often makes you less secure, because real signals get buried in junk alerts you stop reading.

If your business actually grows into the territory where you need that stuff (regulated data, big customer base, real compliance), you’ll know — and at that point you’ll also have the budget to do it properly. Until then: keep the surface small, keep it patched, and keep watching the four things in the monitoring section.

Common mistakes

The same handful of things bite small-team servers over and over:

Port 22 open to the entire internet with password login still enabled. This is the #1 thing scanners look for. Even with a strong password, you’re contributing to the noise. Keys only.
Logging in as root. Either directly, or via a sudoers rule that means a single mistake takes the whole box down. Make a real user.
Skipping reboots after kernel updates. A patched-but-not-rebooted kernel still runs the old, vulnerable kernel. unattended-upgrades with Automatic-Reboot "true" fixes this for free.
IMDSv1 left enabled on AWS. If you’re on EC2/Lightsail, the legacy instance metadata endpoint can be reached by anything that can make an outbound HTTP request from the box — including a bug in your app. Use the IMDSv2 migration playbook to enforce HttpTokens=required without breaking older agents or SDKs.
Dev services bound to 0.0.0.0. Postgres, Redis, MongoDB, Elasticsearch, a debug UI, that one Jupyter notebook you spun up “just for a sec” — anything that listens on all interfaces with no auth is a free shell waiting to happen. Bind to 127.0.0.1, or at minimum require a password and put it behind the firewall.
No backups, or backups that have never been restored. See previous section. This is the one that ends businesses.
Storing secrets in committed .env files. You’ll forget, push to a public repo, and your API keys are now public. Use a .env.example checked in, and the real .env ignored.

None of these are exotic. All of them are still everywhere.

Worth a free second opinion?

Even after a careful first-day setup, things drift. A teammate enables password auth “just for a minute.” A new service starts listening on 0.0.0.0. Auto-updates silently break and stop running. The point of a periodic external check is to catch that drift before it matters.

Run a QuickCheck on your VPS → — read-only, no install, takes a few minutes. Or look at a sample report first to see what it covers.

What this is not

This article is a sensible starting checklist for one Linux VPS run by one person or a tiny team. It is not:

A replacement for security advice from someone who knows your specific stack and threat model.
A compliance program. If you handle health data, payment data, or anything else regulated, you need more than a blog post.
A guarantee. Nothing in security is. The goal is to make yourself a much less appealing target than the millions of other servers on the internet that haven’t done any of this.

Do the basics, do them well, then go back to building the actual product. That’s the job.

About Tuck Sentinel

Tuck Sentinel is a small operation focused on practical security checks for indie founders and small teams running production on a VPS. We build QuickCheck, a free read-only scan that highlights the boring-but-important configuration issues most one-person ops teams miss. No agents, no upsell maze — just the things worth fixing.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "The Indie Founder's VPS Security 101",
  "description": "A practical, no-nonsense guide for solo founders running one Linux VPS. Lock the doors, watch the right things, and skip the security theater.",
  "author": {
    "@type": "Organization",
    "name": "Tuck Sentinel",
    "url": "https://richgibbs.dev/"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Tuck Sentinel",
    "url": "https://richgibbs.dev/"
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://richgibbs.dev/blog/indie-founder-vps-security-101/"
  },
  "image": "https://richgibbs.dev/og/indie-founder-vps-security-101.png",
  "keywords": "VPS security, indie founder, Linux server hardening, Ubuntu, Debian, SSH, ufw, unattended-upgrades, backups",
  "articleSection": "Security",
  "inLanguage": "en"
}

AWS IMDSv2 Migration Without Breaking Things

Sun, 10 May 2026 00:22:00 +0000

If you have EC2 instances older than a year or two, some of them probably still allow IMDSv1. The Instance Metadata Service is the HTTP endpoint at 169.254.169.254 every EC2 instance can hit to learn about itself: instance ID, region, attached IAM role, and the temporary credentials that come with it. IMDSv1 is the original unauthenticated GET protocol. IMDSv2 is the session-token version that blocks a class of SSRF and confused-deputy attacks from walking off with your IAM Role credentials.

AWS has been nudging everyone toward IMDSv2 for years, but existing fleets, AMIs baked before the change, and ASGs pinned to old launch templates are full of IMDSv1-allowing instances. Migration is conceptually simple — flip a setting per instance — and operationally annoying, because flipping it on the wrong workload breaks credential lookups for SDKs, kubelet, the ECS agent, or your own scripts.

This guide walks through the migration the way an operator actually has to do it: detect what is still using v1, change instances in safe waves, validate, and have a rollback path. If you are using the migration window to clean up the rest of the instance, pair this with the broader Ubuntu/Debian EC2 hardening checklist.

Why Migrate

IMDSv1 is a plain HTTP GET against the link-local address. Anything inside the instance that can make an outbound HTTP request — including a vulnerable web app with SSRF — can read instance metadata, including the IAM Role Credentials path:

GET http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>

That returns short-lived credentials for whatever role is attached to the instance. With IMDSv1, no proof of locality is required. An SSRF in a public-facing service can pivot directly to your IAM credentials.

IMDSv2 changes the protocol in two important ways:

Session tokens. Callers PUT to /latest/api/token for a session token, then send it back as X-aws-ec2-metadata-token. SSRF primitives that only allow GET are blocked.
Hop limit. The token response honors a TTL hop limit. Default is 1, so a container behind a Docker bridge or a pod behind a CNI cannot reach IMDS unless explicitly allowed.

Set IMDSv2 to required and v1 stops responding. That’s the goal state.

What Breaks

The realistic breakage list is short and well-known. Knowing it upfront is most of the migration.

Old AWS SDKs. Anything older than the published cutoffs only knows IMDSv1: AWS CLI v1 < 1.18.x, boto3 < 1.12.x, AWS SDK for Java v1 < 1.11.678, Go SDK v1 < 1.25.38, .NET SDK before late-2019. Modern SDKs auto-negotiate v2 with v1 fallback, but if v2 is required the fallback never engages.
Containers behind Docker bridge or CNI. The default hop limit of 1 denies pods/containers that route through the bridge. Raise the hop limit to 2 — or better, use IRSA on EKS, EC2 Pod Identity, or task roles on ECS so workloads don’t depend on instance metadata at all.
kubelet on self-managed nodes. Older kubelets only spoke v1. Modern EKS-optimized AMIs are fine; legacy kops clusters and old custom AMIs are the usual offenders.
ECS agent. amazon-ecs-init >= 1.50 supports IMDSv2. Old ECS-optimized AMIs not re-rolled in years can fail credential fetch.
CloudWatch / SSM agent. Recent versions fine; very old pinned versions not.
Custom scripts. curl http://169.254.169.254/latest/meta-data/... without a token will 401 once v1 is off.
Third-party agents in old AMIs. Old Datadog, New Relic, Splunk, or backup agents from years-old golden images can be v1-only.

That’s the whole list. Everything else either works on day one or never touched IMDS.

Detect IMDSv1 Use

Don’t flip the switch blind. Find the callers first.

CloudWatch metric: `MetadataNoToken`

Every EC2 instance emits a CloudWatch metric called MetadataNoToken in the AWS/EC2 namespace. It increments every time something on the instance hits IMDSv1. This is the single most useful signal you have.

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name MetadataNoToken \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
  --statistics Sum \
  --period 3600 \
  --start-time "$(date -u -d '7 days ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time   "$(date -u +%Y-%m-%dT%H:%M:%SZ)"

If Sum across the last 7 days is 0, that instance is not making any IMDSv1 calls and is safe to switch. Anything non-zero means something is still hitting v1.

For a fleet view, query across all instance IDs or use CloudWatch Metrics Insights / Metric Math to graph MetadataNoToken aggregated. Tag the noisy instances and dig in.

Inventory: which instances even allow v1?

aws ec2 describe-instances \
  --query 'Reservations[].Instances[].{
    Id:InstanceId,
    State:State.Name,
    HttpTokens:MetadataOptions.HttpTokens,
    HopLimit:MetadataOptions.HttpPutResponseHopLimit,
    Endpoint:MetadataOptions.HttpEndpoint
  }' \
  --output table

HttpTokens is what you care about. It will be one of:

optional — IMDSv1 still allowed (the thing you’re trying to remove)
required — IMDSv2 only (the goal state)

A simple “what’s left?” query:

aws ec2 describe-instances \
  --filters "Name=metadata-options.http-tokens,Values=optional" \
            "Name=instance-state-name,Values=running" \
  --query 'Reservations[].Instances[].InstanceId' \
  --output text

CloudTrail and VPC flow logs

CloudTrail does not log calls to IMDS itself — those never leave the instance. What it does show is the AWS API calls made with the credentials IMDS handed out, via userIdentity.sessionContext and the accessKeyId of the temporary credentials. Useful for finding workloads still authenticating via instance role that should have moved to IRSA or task roles.

VPC flow logs do not see 169.254.169.254 traffic either — link-local stays inside the host. Stick to MetadataNoToken plus the inventory query.

On-host detection

If you have shell access to a candidate instance, run something quick before you change settings:

# Try IMDSv1 — if this returns data, v1 is still on
curl -s -o /dev/null -w "%{http_code}\n" \
  http://169.254.169.254/latest/meta-data/instance-id

# Try IMDSv2 — should always return 200 once v2 is supported
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/instance-id

To find callers on a host, auditd rules on connects to 169.254.169.254 plus ss -tnp snapshots usually identify the offending process. On a Kubernetes node, look at old DaemonSets and sidecars first.

Migration Steps

The flow that has worked reliably for small and mid-size fleets:

1. Baseline and freeze new IMDSv1

Set account-level defaults so anything launched from now on is IMDSv2-required and any new AMIs are also v2-required:

# Default IMDS options for new instances in this region
aws ec2 modify-instance-metadata-defaults \
  --http-tokens required \
  --http-put-response-hop-limit 2 \
  --http-endpoint enabled

# Default for newly-registered AMIs
aws ec2 modify-image-attribute \
  --image-id ami-xxxxxxxxxxxxxxxxx \
  --imds-support v2.0

Use modify-image-attribute --imds-support v2.0 on each AMI you control. Once set, instances launched from that AMI get v2-required automatically.

Also set the launch template / Auto Scaling group launch template versions to require IMDSv2:

aws ec2 create-launch-template-version \
  --launch-template-id lt-0123456789abcdef0 \
  --source-version 1 \
  --launch-template-data '{
    "MetadataOptions": {
      "HttpTokens": "required",
      "HttpPutResponseHopLimit": 2,
      "HttpEndpoint": "enabled"
    }
  }'

This stops the bleeding. Old instances may still be on v1, but no new ones are.

2. Sort instances into waves

Pull the list of HttpTokens=optional instances. Group them by:

Wave 0 — disposable. Stateless workers, batch nodes, dev/test. Cheap to break, cheap to recreate. Migrate first.
Wave 1 — replaceable through autoscaling. ASG-managed web tiers, ECS/EKS nodes. New launches are already v2-required; old nodes get rotated out by simply triggering an instance refresh.
Wave 2 — stateful or hand-built. Bastions, databases on EC2, single-instance services, anything pet-shaped.

For waves 0 and 1, prefer rotation over modification — relaunch from updated launch templates rather than mutating live instances. Less risky, fewer surprises.

3. Optional: try `optional` → `required` with a hop bump

For a stateful instance you cannot easily relaunch, raise the hop limit first (so containers keep working), then flip tokens to required:

# Step A: bump hop limit while still allowing v1
aws ec2 modify-instance-metadata-options \
  --instance-id i-0123456789abcdef0 \
  --http-put-response-hop-limit 2 \
  --http-tokens optional \
  --http-endpoint enabled

# Verify everything still works for at least one full agent cycle
# (CloudWatch agent, SSM agent, your app, container credential lookups)

# Step B: require v2
aws ec2 modify-instance-metadata-options \
  --instance-id i-0123456789abcdef0 \
  --http-tokens required

Watch MetadataNoToken after step A — if any callers are still using v1, they will keep showing up in the metric. Fix or upgrade them before step B.

4. Roll Auto Scaling groups

After the launch template is updated:

aws autoscaling start-instance-refresh \
  --auto-scaling-group-name my-asg \
  --preferences '{"MinHealthyPercentage": 90, "InstanceWarmup": 300}'

For EKS managed node groups, the equivalent is updating the node group to a new launch template version and letting AWS drain and replace nodes. For ECS, update the capacity provider’s launch template and either drain instances or wait for natural turnover.

5. Sweep and confirm

After each wave, re-run the inventory query and the MetadataNoToken check. Anything still on optional should have a name attached to it and a reason.

Mid-article CTA: Want a one-shot read-only audit that tells you which of your EC2 instances still allow IMDSv1, plus a dozen other quiet AWS posture issues? That’s exactly what QuickCheck is built for. Skim a sample report before you decide.

Validation

After you flip an instance, you want fast confirmation it’s actually on v2 and nothing is silently failing.

Confirm v2-required at the API level

aws ec2 describe-instances \
  --instance-ids i-0123456789abcdef0 \
  --query 'Reservations[0].Instances[0].MetadataOptions'

Expected:

{
  "State": "applied",
  "HttpTokens": "required",
  "HttpPutResponseHopLimit": 2,
  "HttpEndpoint": "enabled",
  "HttpProtocolIpv6": "disabled",
  "InstanceMetadataTags": "disabled"
}

State: applied matters — pending means the change has not landed yet.

Confirm v1 is actually rejected on the host

# Should now return 401 Unauthorized
curl -s -o /dev/null -w "v1: %{http_code}\n" \
  http://169.254.169.254/latest/meta-data/instance-id

# Should return 200 with the instance ID
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  -w "\nv2: %{http_code}\n" \
  http://169.254.169.254/latest/meta-data/instance-id

v1: 401 and v2: 200 is the correct pair.

Confirm credentials still resolve

TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
ROLE=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/)
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE \
  | head -c 200; echo

You should see AccessKeyId, SecretAccessKey, Token, and Expiration.

Confirm app-level health

aws sts get-caller-identity from the instance using whichever SDK your workloads use.
Container credential lookups from inside one container per host (especially if you raised the hop limit).
ECS agent: curl -s http://localhost:51678/v1/metadata should still respond.
kubelet health: nodes still Ready, image pulls from ECR still work.

Confirm `MetadataNoToken` is zero

After 24–48 hours on v2-required, MetadataNoToken should be a flat zero line. If not, something is still calling v1 — which now means it is failing. Find it.

Rollback

You want this written down before you need it.

Per-instance rollback is one CLI call:

aws ec2 modify-instance-metadata-options \
  --instance-id i-0123456789abcdef0 \
  --http-tokens optional \
  --http-put-response-hop-limit 2 \
  --http-endpoint enabled

That re-enables IMDSv1 immediately, no instance restart required. It is the same call you used to flip forward — just with optional instead of required.

Launch template rollback: revert to the previous version.

aws ec2 modify-launch-template \
  --launch-template-id lt-0123456789abcdef0 \
  --default-version 1

Auto Scaling rollback: trigger another instance refresh against the previous LT version, or roll forward with a fixed template once you know what broke. Avoid the temptation to mutate live ASG instances; relaunch is cleaner.

For account-level defaults, you can re-relax them, but generally do not. Once new instances are v2-required by default, leave that in place even if you have to roll back individual stragglers.

QuickCheck CTA

If you’d rather not hand-roll the inventory queries and CloudWatch checks across every account and region, QuickCheck runs a read-only, one-shot review of your AWS posture and produces a plain-English report. IMDSv1 stragglers are one of the dozen things it surfaces — alongside open security groups, public S3, missing MFA on root, untagged keys, and a few other “you’d rather know” items. See an example in the sample report. It is not magic and not a replacement for proper cloud security tooling, but it is a fast way to know where you stand before you start migrating.

What This Is Not

To set expectations clearly:

This is not a penetration test. It is a configuration migration, not an adversarial exercise.
This is not a certification or compliance attestation. Migrating to IMDSv2 is a control improvement; it does not by itself constitute SOC 2, ISO 27001, PCI, or anything else. Your auditor still wants the artifacts they always want.
This is not a guarantee. Cloud security is a portfolio of controls. IMDSv2 closes one well-known SSRF-to-credentials path; it does not address misconfigured security groups, overly broad IAM policies, leaked long-lived keys, or vulnerable application code. Treat it as one item on the list.
This is not a substitute for moving workloads to IRSA / EC2 Pod Identity / ECS task roles where those fit. IMDSv2 makes instance metadata safer; per-workload identity is still the better long-term answer for containers.

Migrate to IMDSv2 because it is cheap, well-understood, and removes a real foot-gun. Then keep going.

About Tuck Sentinel

Tuck Sentinel is the security-focused side of an indie operator workshop by Rich Gibbs. It builds small, sharp tools — like QuickCheck — for founders and small teams who want a competent read of their cloud posture without an enterprise platform. The bias: fast, honest, read-only assessments and migrations you can actually finish.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "AWS IMDSv2 Migration Without Breaking Things",
  "description": "A practical, indie-founder guide to migrating EC2 instances from IMDSv1 to IMDSv2 without breaking SDKs, containers, kubelet, or the ECS agent.",
  "author": {
    "@type": "Organization",
    "name": "Tuck Sentinel"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Tuck Sentinel",
    "url": "https://richgibbs.dev/"
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/blog/aws-imdsv2-migration-without-breaking-things"
  },
  "image": "https://example.com/og/aws-imdsv2-migration.png",
  "articleSection": "Cloud Security",
  "keywords": "AWS, EC2, IMDSv2, IMDSv1, cloud security, IAM, SSRF, migration",
  "about": [
    { "@type": "Thing", "name": "AWS EC2 Instance Metadata Service" },
    { "@type": "Thing", "name": "IMDSv2" },
    { "@type": "Thing", "name": "Cloud Security Posture" }
  ]
}

SPF, DKIM, DMARC for indie founders: the 20-minute checklist

Sun, 10 May 2026 04:30:00 +0000

You shipped a product. Stripe sends receipts. Postmark sends magic links. Mailchimp blasts your launch list. You replied to a support ticket from your own founder address.

Then someone said “hey, your password reset went to spam.”

This guide is for that moment.

It is not a deliverability bible. It is the smallest correct version of the SPF / DKIM / DMARC story for a solo founder or a 2-3 person SaaS team, with one custom domain and two-to-five tools that send email on its behalf. If you can edit DNS and copy a record, you can finish it tonight.

We are also not selling you a deliverability platform. The point of this post is for you to do it yourself, correctly, in one sitting.

What “set up email DNS” actually means in 2026

Mailbox providers — Gmail, Yahoo, Outlook, Apple, ProtonMail — use three DNS-anchored signals to decide whether a message is plausibly from your domain at all:

SPF says “these IP addresses / hostnames are allowed to send mail using my domain in the envelope sender.”
DKIM says “messages from my domain will carry a cryptographic signature in the headers, signed by a key whose public half lives in DNS.”
DMARC says “if SPF and DKIM both fail to align with my visible From: domain, here is what you should do — nothing, quarantine to spam, or reject — and please send me reports.”

In 2024–2025 Gmail and Yahoo started requiring all three from any sender shipping more than 5,000 messages a day to their users, and they have been quietly tightening the rules for low-volume senders ever since. In practice, by 2026:

If your domain has no SPF and no DKIM, password resets and receipts will sometimes silently disappear into spam.
If your domain has no DMARC at all, anyone can spoof “from your domain” until enough recipients complain.
If your DMARC record is malformed, mailbox providers behave the same as if it isn’t there — except now your reports vanish too.

You do not need to be perfect. You need to be not broken.

The 20-minute checklist

Before you touch DNS, do the boring inventory step. This is the part most founders skip and most spam problems come from.

1. List every tool that sends mail “from” your domain (3 minutes)

Open a notes file. Write the domain you want to fix at the top. Then list every place that sends email as that domain. Real examples for a typical indie SaaS:

Founder mail (you replying from you@yourdomain.com) — Google Workspace or Fastmail.
Transactional / product mail — Postmark, Resend, Mailgun, AWS SES, SendGrid, Mailtrap.
Marketing / newsletter — ConvertKit, Mailchimp, Beehiiv, Buttondown, Substack custom domain.
Helpdesk — Help Scout, Front, HubSpot, Zendesk, Plain.
App-platform notifications — Vercel/Render/Heroku notifications using your domain, GitHub on a custom domain.
Stripe receipts and Tally form notifications, when configured to “send from” your domain rather than the platform default.

If you cannot remember, search your inbox for from:@yourdomain.com and note every “tool integration” message you find from the last 90 days.

This list is the single most useful artifact in this entire process. If anyone ever asks you “do you know who sends as your domain?”, you can answer in one screen.

2. Pick exactly one SPF record (5 minutes)

SPF is one TXT record at the apex of your domain (yourdomain.com, not mail.yourdomain.com). You are allowed exactly one. If there are two SPF TXT records in DNS, every conforming mailbox server treats the result as permerror and ignores both.

A working SPF for the example list above might be:

v=spf1 include:_spf.google.com include:spf.mtasv.net include:_spf.mailgun.org include:_spf.constantcontact.com -all

Rules:

Start with v=spf1.
One include: per provider, taken from each provider’s docs. Do not invent them.
End with -all (hard fail) or ~all (soft fail). Use ~all while you are setting up DMARC, then move to -all once DMARC reports are clean.
Do not put +all anywhere. Ever. That tells the world anyone can send as you.
Do not exceed 10 DNS lookups across all the include: and redirect= directives combined. Tools like Google Workspace + Mailgun + Mailchimp + Constant Contact + Help Scout will quietly exceed 10. If you see permerror reports, this is usually why.

If you use mail.yourdomain.com as a separate sending subdomain (some providers configure it that way), publish a separate SPF record at that subdomain.

3. Add DKIM for each sending tool (5 minutes)

DKIM is per-provider. Every provider that sends mail for you should give you one or more selector._domainkey.yourdomain.com CNAME or TXT records to add.

Examples of selectors you’ll see in a real indie SaaS:

Google Workspace: google._domainkey
Postmark: <assigned>._domainkey (Postmark assigns the selector when you verify the domain)
Mailgun: mailo._domainkey and pic._domainkey
ConvertKit / Mailchimp: their dashboard prints the exact CNAMEs.
Resend: resend._domainkey

Two rules that catch people:

DKIM records do not show up in plain dig TXT yourdomain.com. You have to query the selector explicitly: dig TXT selector._domainkey.yourdomain.com. If you cannot remember selectors, you cannot validate your own DKIM from public DNS — write them down.
“DKIM is set up” is not the same as “messages are being signed.” Each provider has its own toggle for “sign outbound mail with this key.” If signing is off in the provider dashboard, the selector record alone is useless.

The Authentication-Results header in any actual sent email is the source of truth. If it says dkim=pass from your visible domain, signing is real.

4. Publish a cautious DMARC (3 minutes)

DMARC is one TXT record at _dmarc.yourdomain.com. Start safe:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; adkim=r; aspf=r; pct=100

Translation:

p=none — do not block anything yet, just ask for reports.
rua=mailto: — a real mailbox you actually read; not a personal Gmail you ignore. Many founders use a forwarding alias like dmarc-reports@yourdomain.com that lands in a labeled folder.
adkim=r; aspf=r — relaxed alignment. Strict alignment is for later.

A 14-day p=none window before you tighten anything is the difference between “I learned my newsletter platform sends as mail.mydomain.com” and “I broke my newsletter for two days.”

After 14 days of clean reports — meaning every legitimate sender shows up in the reports as passing SPF or DKIM aligned with yourdomain.com — move to:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=25

The pct=25 ramp is intentional. It means “quarantine 25 % of messages that fail alignment” so you can detect any forgotten sender before going full p=quarantine or p=reject.

If you are an indie founder, you may stop at p=quarantine forever. p=reject is for senders who are confident no legitimate mail anywhere uses their domain incorrectly.

5. Verify the result with one real email (4 minutes)

Send one email to yourself at Gmail, Yahoo, and Outlook from each sending tool you care about most (founder mail, password reset, newsletter). Open the message header.

You are looking for an Authentication-Results line that says all three of:

spf=pass with smtp.mailfrom= matching a domain that contains yourdomain.com.
dkim=pass with header.d=yourdomain.com (alignment) — not header.d=postmarkapp.com or header.d=mailgun.org.
dmarc=pass.

dkim=pass header.d=mailgun.org while your visible From: is support@yourdomain.com is the most common deliverability bug among indie founders. The message is technically signed, but DMARC-wise it is unsigned by your domain. Fix it by completing the provider’s “Use my own domain” / “Custom domain DKIM” configuration. Postmark, Mailgun, Resend, SendGrid, Mailchimp, ConvertKit, and AWS SES all support this; they just don’t enable it by default.

Things to deliberately ignore in v1

You do not need:

BIMI. Useful only after DMARC is at p=quarantine or stricter for a long time, and even then it is a logo-display feature, not a deliverability feature.
ARC. Mailing-list specific.
DKIM key rotation. Whatever your provider gave you is fine until they tell you to rotate.
Per-subdomain DMARC strictness (sp=). Default is fine until you operate dedicated sending subdomains.

You also do not need:

A paid “deliverability platform” subscription.
A reputation-monitoring agency.
An IP warmup schedule (you are using shared IPs from your ESP; they handle warmup).

Common gotchas an indie founder will hit

These are the failure modes I see most often when reviewing single-domain setups:

Two SPF records. Often a leftover from when you were trying providers. Merge into one.
+all left over from a Google guide that said “for testing only.” Remove.
DMARC rua pointing at you@yourdomain.com itself. Your inbox will fill with unreadable XML aggregate reports. Use a sub-alias (dmarc-reports@) that auto-files.
DKIM “set up” but provider has signing disabled. Toggle it on in the provider, and confirm with a real test message header.
Marketing tool added later, but DKIM never aligned. New newsletter platform turns SPF green, leaves DKIM header.d= pointing at the platform’s domain. DMARC fails alignment for that one tool.
Personal Gmail “Send mail as” alias used to reply from you@yourdomain.com. Even if Workspace is fine, that alias often sends as gmail.com underneath. Reply-To is fine; the sending identity matters for alignment.
Subdomain forgotten. Stripe receipts sometimes go through mail.yourdomain.com. If subdomain SPF/DKIM is missing, mailbox providers can still apply the apex DMARC. Check at the exact subdomain.

If any of those sound like a problem you cannot debug from your provider’s dashboard alone, that is the moment a second pair of eyes is worth more than another deliverability article.

Next step: a $99 second pair of eyes

Once you’ve done the 20-minute pass above, the question is usually not “is the record there?” It’s “are all these records aligned with the way I actually send mail?” That answer lives partly in DNS and partly in a few real message headers.

If you’d like a written, prioritized fix list for one domain — SPF, DKIM, DMARC, MX, sender-tool inventory, and the obvious mistakes — that is exactly the Inbox/DNS QuickCheck we offer. $99, one domain, no DNS login needed, 24-hour turnaround. No managed retainers, no inbox-placement guarantees, no spam help.

If you’d rather DIY but want the printable, fillable Markdown version of the entire process — sender inventory template, SPF builder, DKIM provider reference, DMARC ramp, Authentication-Results decoder — that’s the Indie Founder Email DNS Pack, $19 (pay what you want, $9 minimum) on Gumroad.

That is also the point at which most founders realize there was one tool nobody remembered to align. That tool is almost always a marketing platform.

You don’t have to buy anything to follow the checklist above. The above is the whole working answer for most one-domain indie SaaS. The QuickCheck exists for when you’ve done the obvious and still have a quiet 5–10 % of legitimate mail disappearing into spam, and you want a second set of eyes before you tighten DMARC further.

Either way, the goal is the same: your password resets, your receipts, and your founder replies should reach the inbox. The boring DNS hygiene above is most of the answer.

If you’ve already finished the checklist above and tightened DMARC to p=quarantine, and now a specific sender — newsletter tool, Stripe receipts, a sub-domain — has started being quarantined or hard-bounced (Gmail 5.7.26, Microsoft 5.7.509 / 5.7.515), the DMARC Quarantine Pack is the focused diagnostic runbook for that exact moment. It includes a DSN decoder cheat-sheet, three real-world incident walkthroughs (marketing-tool DKIM drift, forgotten sub-domain, forwarding/ARC breakage), and a single-file Python aggregate-XML reader so you can read your own DMARC reports without paying for a SaaS dashboard.

DMARC Quarantine Pack — $29 on Gumroad · 14-day refund, no questions.

Cloudflare Email Routing for indie founders: the 10-minute support@ setup

Sun, 10 May 2026 05:00:00 +0000

You launched. Your domain has a website, a payment link, a privacy page that says “support@yourdomain.com,” and… no actual mailbox at that address. Real customer mail is silently bouncing.

You don’t need a $6-per-user-per-month Workspace seat to fix this. Cloudflare Email Routing forwards support@yourdomain.com (and any other alias you want) to a Gmail/Fastmail/Proton mailbox you already pay for, for free, in about ten minutes.

This post is the boring, working playbook to set it up — plus the one thing it can’t do that surprises every founder who tries it for the first time.

What Email Routing actually is

Cloudflare Email Routing is inbound-only forwarding for any domain whose DNS lives at Cloudflare. You publish a few MX and TXT records that Cloudflare manages for you, define some routing rules in the dashboard (“send anything to support@yourdomain.com to my Gmail”), and incoming mail gets re-injected into your real mailbox.

What it is not:

Not a mailbox. You can’t log in to a Cloudflare interface to read mail.
Not an outbound SMTP server. You can’t send from support@yourdomain.com through Email Routing. Replies will go from whatever mailbox you forwarded into, unless you also configure your replying client (more on this below).
Not a deliverability service. It accepts mail from the public internet and re-delivers it. SPF/DKIM/DMARC for your domain are still your job.

The 10-minute path

Two prerequisites:

Your domain’s nameservers are Cloudflare’s. (If they aren’t, follow Cloudflare’s “Add a site” flow first; it’s free, takes about 5 minutes plus DNS propagation.)
You have a Gmail / Fastmail / Proton / Mailbox.org / etc. mailbox you actually read.

1. Enable Email Routing (1 minute)

In the Cloudflare dashboard:

Pick your zone → Email → Email Routing.
Click Get started. Cloudflare will offer to add the required DNS records automatically. Say yes.

Cloudflare will publish:

Three MX records pointing at route1.mx.cloudflare.net, route2.mx.cloudflare.net, route3.mx.cloudflare.net.
A TXT record at the apex with v=spf1 include:_spf.mx.cloudflare.net ~all.
A DKIM CNAME (cf2024-1._domainkey) for the routing service.

If you already have an SPF record at the apex, stop and merge them by hand. You should never have two SPF records. We’ll come back to that in the gotchas.

2. Verify the destination address (2 minutes)

Still in Email → Email Routing:

Destination addresses → Add destination address.
Enter the personal mailbox you want forwarded mail to land in.
Cloudflare emails a verification link. Click it.
The destination’s status should flip to Verified.

You can verify multiple destinations and route different aliases to different mailboxes. Useful if billing@ should go to a finance address and security@ should go to a different one.

3. Add a routing rule (1 minute)

Custom addresses → Create address.
Custom address: support (so the full address is support@yourdomain.com).
Action: Send to an email.
Destination: pick the verified address.
Save.

Repeat for every alias you advertise: hello@, billing@, legal@, security@, dmarc-reports@ (very useful, more on this in a minute).

4. (Optional) Catch-all (30 seconds)

In Custom addresses → Catch-all address, set it to either:

Drop — anything not matched is silently dropped. Good for spam hygiene.
Send to — any unknown alias is forwarded to your fallback mailbox. Good if you advertise lots of aliases on signup forms and don’t want misspellings to bounce.

There is no third option. Pick one. “Drop” is what most indie SaaS founders should use.

5. Send a real test (1 minute)

From a different mailbox (not the destination — Gmail will helpfully suppress mail you sent to yourself), email support@yourdomain.com. It should arrive at the destination within a few seconds, with the original sender preserved in the From: header.

That’s the whole setup. The remaining time is what’s between you and a working outbound support address, which is the part that catches everyone.

The one thing Email Routing does not do — and what to do instead

Email Routing is inbound only. If you reply to a customer’s email and you do nothing else, your reply will go from your.personal@gmail.com, not from support@yourdomain.com. The customer sees a different address than the one they wrote to, the conversation feels off, and you might also leak a personal address you didn’t mean to advertise.

Three options, in order of effort:

Option A — Live with replies coming from the personal mailbox

OK for a v0 SaaS while you have ten customers. Set the Reply-To header in your mail tool to support@yourdomain.com so further replies route correctly. Most mail clients let you set a default Reply-To per identity. Customers will see your personal address in the visible From, which they will probably tolerate while you’re small.

Option B — Use Gmail’s “Send mail as” with a real outbound SMTP server

In Gmail: Settings → Accounts and Import → Send mail as → Add another email address.

You will need:

A real outbound SMTP host that authorizes you to send as support@yourdomain.com. Gmail itself will not let you do this without an SMTP server; the “treat as alias” path that worked years ago is gone.
An SMTP host can be a paid Workspace seat ($6/mo/user — the thing we just avoided), or a transactional ESP like Postmark / Resend / Mailgun / SES configured with your custom domain and DKIM.

If you already use Postmark/Resend/Mailgun/SES for product mail, set up an authorized “transactional support” sender there and feed the SMTP credentials into Gmail’s Send-mail-as flow. Postmark and Resend both have specific docs for this. Now your replies go from support@yourdomain.com over a path that aligns with DKIM.

Option C — Use a help-desk tool with custom-domain support

Help Scout, Plain, Front, Missive, HubSpot Service. These all accept inbound mail forwarded to a tool-specific address (you point Cloudflare Email Routing at it instead of your Gmail) and send outbound replies as support@yourdomain.com with their own DKIM you authorize. Per-seat pricing varies; some have free tiers up to a few mailboxes.

For an indie SaaS at 0–500 customers, Option B is usually the sweet spot. For a 2-3 person team that wants conversation handling, Option C earns its keep.

Common gotchas

These are the things I see indie founders get wrong with Email Routing.

Gotcha 1: dual SPF records

If your DNS already had an SPF record (because you set up Postmark or Mailgun before adding Email Routing), Cloudflare will silently publish a second one. Conforming receivers will treat dual SPF as permerror and ignore both. Result: legitimate inbound delivery may still work via MX, but your outbound SPF alignment quietly breaks.

Fix: keep one record at the apex. If you also send via Postmark and Mailgun and have routing on:

v=spf1 include:_spf.mx.cloudflare.net include:spf.mtasv.net include:_spf.mailgun.org ~all

Verify with dig +short TXT yourdomain.com | grep spf1. You should see exactly one line.

Gotcha 2: forwarded mail lands in spam

Forwarding rewrites the SMTP envelope. The original sender’s SPF/DKIM may no longer align by the time Gmail receives the forwarded copy. Symptoms: real customer mail to support@ shows up in Gmail’s Spam folder.

Fix:

In Gmail, open one such message → More → Filter messages like this → set criteria to to:support@yourdomain.com OR deliveredto:support@yourdomain.com, then Never send to spam + apply a Support label + optionally categorize as Primary.
Test from a non-destination address; do not test from another mailbox owned by the same Google account.

This is a Gmail filter, not a Cloudflare problem. Email Routing sets ARC headers correctly; some receivers still ding forwarded mail.

Gotcha 3: DMARC reports vanish

You set up DMARC at _dmarc.yourdomain.com with rua=mailto:dmarc-reports@yourdomain.com. That alias must actually route somewhere. If you forgot to add a Cloudflare Email Routing rule for dmarc-reports, the reports get dropped, and you’ll think DMARC is broken when really you just have no inbox to read it from.

Fix: add dmarc-reports@ as a routed alias. In Gmail set a filter to auto-label and skip the inbox. Aggregate reports are XML and noisy.

Gotcha 4: your “send mail as” alias still routes through gmail.com

Even with Send-mail-as configured, if you don’t enable “Treat as alias” or you don’t use a true outbound SMTP host, Gmail will sometimes send through gmail.com and tag it as a forwarded sender. The visible From: looks right, but Authentication-Results will tell on you.

Fix: read the Authentication-Results header on a real reply (View original in Gmail). You want dkim=pass header.d=yourdomain.com, not header.d=gmail.com.

Gotcha 5: paid Workspace already exists for the domain

If your domain previously had Google Workspace MX records, or M365 MX records, the dashboard will warn before overwriting them. Do not click through that warning unless you intend to abandon the existing mailbox. Cloudflare’s MX records replace whatever was there — including your live Workspace inbox.

Fix: pick one. Either keep Workspace and don’t enable Email Routing, or migrate everything to Email Routing first.

Authentication after Email Routing is on

Once routing is live, dig your domain. You should see exactly:

3 MX records → route{1,2,3}.mx.cloudflare.net.
1 SPF TXT (only) at the apex.
1 DKIM TXT (cf2024-1._domainkey) for the routing service.
Your existing DKIMs from product/transactional senders.
1 DMARC TXT at _dmarc.

If any of those is duplicated or missing, you have homework. The matching SPF/DKIM/DMARC checklist walks the rest.

When to upgrade past Email Routing

Email Routing is the right answer when:

You need 1–10 aliases on one domain.
Volume is “real customer mail,” not “we send 50k newsletters a month from this address.”
A 5–60 second delay on inbound is fine.

Outgrow it when:

You want a shared inbox for two or more people without forwarding to the same Gmail.
You need calendar/contacts/Drive on the domain (that’s Workspace’s actual value, not the email forwarding).
You need server-to-server inbound webhooks (Email Routing supports a “Send to a Worker” action for this; useful but past the 10-minute mark).

Want a written second-pair-of-eyes on your setup

Once routing is live and SPF/DKIM/DMARC are published, the most useful thing you can do is verify every authorized sender is aligned with your visible From: address. That’s exactly the Inbox/DNS QuickCheck — a $99 written report on one domain, delivered within 24 hours, no DNS login required.

If you’d rather DIY the whole thing, the same content in printable, fillable Markdown form (sender inventory template, SPF builder, DMARC ramp, Authentication-Results decoder) is in the Indie Founder Email DNS Pack — $19 (pay what you want, $9 minimum) on Gumroad. Either is fine. The point is to do it once, well, then never think about it again.

If you set up Cloudflare Email Routing and also publish DMARC at p=quarantine or stricter, a small but real failure mode is forwarded mail that breaks SPF or DKIM alignment at the receiving mailbox. The DMARC Quarantine Pack ($29) is the focused runbook for diagnosing that and related cases — Gmail 5.7.26 and Microsoft 5.7.509 / 5.7.515 decoded with source citations, three incident walkthroughs (one of them is a forwarding/ARC case), and a single-file Python aggregate-XML reader for reading your own reports.

DMARC Quarantine Pack — $29 on Gumroad · 14-day refund, no questions.

I had 80,000 unread emails. Here's the cleanup playbook (no apps, no OAuth)

Sun, 10 May 2026 17:11:52 +0000

Last weekend I sat down to clean out my personal Gmail.

I had 80,675 unread messages older than one year. Most were newsletters from companies I’d long since stopped caring about — receipts from a 2019 ride-share account, password-reset emails from accounts that no longer exist, every “weekly digest” I’d ever opted into and forgotten.

The cleanup itself took about 20 minutes once I had a plan. The having a plan part took three evenings.

This post is the playbook I actually used. It isn’t a SaaS pitch. It doesn’t ask you to log into anything. It’s the boring, working sequence for someone who has tens of thousands of old unread emails in a personal Gmail and wants them gone tonight, without nuking something they’ll wish they’d kept.

Why most “inbox zero” advice fails on a real mailbox

If you Google “how to delete old unread emails Gmail bulk,” you get three kinds of answers:

SaaS apps that want full mailbox OAuth. Mailstrom, Clean Email, Cleanfox. They work, but the permission cost is large for a job that runs once.
Blog posts from 2014. They reference Outlook 2010, IMAP folders, and Gmail’s old desktop UI. The screenshots don’t match anything you actually see today.
“5 tips” listicles that assume you have 800 unread emails, not 80,000. The “select all” trick doesn’t survive paging through 1,600 pages of 50 messages each.

None of these are useful when you’re staring down a five-figure unread count.

The reason isn’t the operations — Gmail’s older_than: operator does most of the heavy lifting. The reason is order. If you don’t survey first, you’ll start deleting things you wanted to keep, panic, stop halfway, and end up with a mailbox that’s somehow worse than when you started.

The order I followed (and you can copy)

The whole playbook is five steps. None of them involve installing anything.

1. Survey before you touch anything

Open Gmail. Open the search bar. Run these queries one at a time and write the result count down on a piece of paper:

is:unread older_than:1y
is:unread older_than:3y
from:newsletters older_than:6m (or substitute a sender domain you know is noise)
has:attachment older_than:2y larger:10M
category:promotions older_than:6m

Five numbers. That’s your map.

If the first number is over 5,000, congratulations — you have the same shape of problem most indie founders have. Mine was 80,675 against the first query. Yours will be different but the playbook scales.

If you want a more thorough survey — top 20 senders, oldest cohorts by year, attachment age buckets, label sprawl — that’s what the Inbox Cleanup Pack ships: a small read-only shell script that calls the Gmail API under your own OAuth client and writes a single survey.json file. No message bodies, no subjects, no message ids. Just counts. You can also do the survey by hand with the queries above; the script just makes it faster on big mailboxes.

2. Filter the recurring noise first

Before you delete anything, kill the inbound flow.

Open Gmail → Settings → Filters and Blocked Addresses → Create a new filter.

For each of the top 5 newsletter senders you can name off the top of your head, create a filter:

from:(news@somecompany.com) → “Skip the Inbox” + “Mark as read” + “Apply label: Newsletters” + “Also apply filter to existing matching conversations.”

The “also apply” checkbox is the part most people miss. It silently archives the existing 4,000 unread newsletters from that sender in one click. No manual select-all required.

Repeat this for your top 5–10 noisy senders. You’ll be surprised how much of the unread count is concentrated in a small number of domains. In my case, six senders accounted for 41% of the 80,675.

3. Bulk-archive the old promotions cohort

Now that the inbound is filtered, attack the standing cohort.

In the search bar:

is:unread category:promotions older_than:1y

Click the small “Select all conversations that match this search” link that appears above the message list. (The plain “select all” checkbox at the top only ticks the 50 visible messages — this is the most common gotcha and the reason people quit halfway.)

Then Archive, not Delete. Archiving keeps the messages in All Mail; deleting moves them to Trash. For promotions older than a year, archive is enough — they’ll never come up in your inbox again unless you specifically search for them.

4. Delete the truly dead — with `older_than:` and a safety net

For the cohort that genuinely has no future use:

is:unread older_than:2y

Same “Select all conversations that match this search” link, then Delete.

Two things to know:

Gmail’s Trash auto-purges after 30 days. That’s your real undo window. If you delete 50,000 messages today, you have 30 days to walk into Trash and pull anything important back.
Deleting from Gmail does not delete from Google Takeout history. If you’ve ever exported your mail with Takeout, that snapshot is still in Drive. The Trash purge is a Gmail-only concept.

I deliberately did not delete anything younger than two years. The marginal value of “unread receipt from 2024” is small but non-zero — there’s still a chance you’ll need to find one. The marginal value of “unread newsletter from 2019” is zero.

5. Set up the maintenance you’ll actually keep

The cleanup is a one-day job. Maintenance is what keeps you from being here again in two years.

Three filters that survive long-term:

One filter per platform that sends transactional mail you don’t read in real time (Stripe receipts, Vercel deploy notifications, GitHub digest mails) → “Skip the Inbox” + “Apply label: Transactional.”
One filter for unsubscribe in body → “Apply label: Newsletter.” This labels every newsletter going forward without skipping the inbox; once a quarter you can sweep the label.
One filter for from:(*@yourdomain.com) → “Star” or “Mark as important.” Mail from your own domain to yourself is almost always something you actually wanted to act on.

Don’t go past three. Filter sprawl is the second cause of inbox bankruptcy after newsletter sprawl.

What I deliberately did not do

No third-party apps. No Mailstrom, no Clean Email. They work for the people they fit; they’re the wrong shape for a one-time cleanup.
No “inbox zero” rules. Inbox zero is a discipline, not a software problem. Either you’ll keep up or you won’t; no app changes that.
No deletion of mail younger than two years — too much chance of needing one of them.
No bulk-unsubscribe service. Most of them either MITM your unsubscribe (and re-sell the implied opt-in signal) or get blocked by sender reputation systems. Manual unsubscribe from the noisiest five senders, then filter the rest, beats a bulk service every time.
No DNS or sender-config changes. That’s a different problem — see the Inbox/DNS Pack and Inbox/DNS QuickCheck for the SPF/DKIM/DMARC side.

The boring summary

Survey before you touch anything.
Filter the recurring noise first, with “Also apply filter to existing matching conversations” checked.
Archive (not delete) the old Promotions cohort.
Delete the cohort older than two years, knowing the 30-day Trash window is your safety net.
Three maintenance filters, no more.

That’s the whole playbook. It’s enough for most personal Gmails carrying tens of thousands of unread.

Want this packaged?

If you’d rather have the survey script, the printable Markdown version of the cleanup order, the full filter templates, and the cohort-by-cohort cleanup-order I followed, that’s exactly the Inbox Cleanup Pack — $19 (pay-what-you-want, $9 minimum) on Gumroad.

If you’d rather hand me the counts-only survey.json from the script and get a written, prioritized cleanup plan tailored to your mailbox in 24 hours, that’s the $79 Inbox Cleanup QuickCheck. I never see message content; just the counts.

If you’re a small Workspace team with up to 10 mailboxes — typical pre-migration scenario — the $499 Enterprise tier handles it under your own internal-app OAuth path, no third-party permissions added.

Either way, the playbook above is the working answer for most personal Gmails. The product exists for the case where you’d rather pay $19 for a pre-written cleanup order than reverse-engineer one yourself, or pay $79 for a custom plan, or have a teammate run the same survey across 10 mailboxes before a migration.

The 30-day Trash window is your safety net. Use it.

— Rich

I wouldn't give a SaaS my Gmail to clean it. Here's the 30-line read-only alternative.

Mon, 11 May 2026 16:55:00 +0000

I sat down three weekends in a row to clean out my personal Gmail.

The first two weekends I did what most people do. I opened the “free inbox cleaner” tab everyone keeps tweeting about, read the OAuth consent screen — Read, compose, send, and permanently delete all your email from Gmail — closed the tab, and went back to scrolling. The cost felt wrong for a job I’d only run once.

The third weekend I wrote my own script. Survey-only, read-only, runs under my own Google account, no tokens ever leave my laptop. The actual cleanup, once I had a plan, took less than half an hour: I cleared 80,675 messages older than a year, archived another 14,000-odd, and built three filters that have kept the backlog at zero ever since.

This is what I learned about doing it without handing a stranger the keys to my mailbox.

The OAuth scope problem nobody wants to say out loud

A free email cleanup app is not, in fact, free.

When you click “Sign in with Google” and the consent screen asks for https://mail.google.com/ — that’s the all-of-Gmail scope. It’s not “look at counts.” It’s not “look at senders.” It’s read every message, write every message, delete every message, send mail as you to anyone. There is no narrower scope that lets a third-party app do bulk cleanup the way most of these tools do it.

A few honest consequences of granting that scope:

The app’s server can read message bodies, attachments, contacts, calendar invites, and 2FA codes at any time it holds a valid token. Most don’t advertise doing that. The capability exists either way.
OAuth refresh tokens last for months by default. Removing the app from your Google account dashboard revokes new tokens, not stored ones. If the vendor’s database was already scraped, the bird has flown.
You are now an upstream dependency of every breach that vendor will ever have. The 2014–2024 history of mailbox-OAuth apps is not encouraging on that point — look up any of the big-name “smart inbox” companies and you’ll find at least one incident.

This isn’t a hit piece on any specific tool. I won’t name any. The economics of “free, ad-funded inbox cleaner with full mailbox OAuth” are the same regardless of who’s running it. The product is the inbox.

For a recurring assistant you trust — a calendar app, a CRM you live in — that scope is sometimes a fair trade. For a one-time cleanup, it isn’t. The right tool for a one-time job is one that doesn’t outlive the job.

Survey-then-Delete: the methodology

Here’s the method that actually worked. I call it Survey-then-Delete because reversing those two words is what causes most cleanups to fail halfway.

Survey, counts only. Don’t look at bodies. Don’t look at subjects. Don’t even pull message IDs. Just ask Gmail “how many messages match this query?” for a handful of useful queries — top senders, age cohorts, attachment sizes.
Identify the top 12 senders by volume. In every five-figure mailbox I’ve audited, fewer than 15 senders account for 40–70% of the noise. This is universal.
Filter the recurring inbound first. For each of those senders, build a Gmail filter that skips the inbox, marks as read, and “Also apply filter to existing matching conversations.” That single checkbox is where most manual cleanups stall.
Bulk delete by sender and age cohort, not by clicking individual messages. Use Gmail’s from: and older_than: operators. The 30-day Trash window is your safety net — anything you delete is recoverable for 30 days.
Run two maintenance filters so you never have to do this again.

Notice what’s not on the list: no mailbox migration, no archive-everything panic, no “select all 80,000 and pray.” You don’t even need to know which individual messages you’re deleting. You’re operating on counts and senders, like a sysadmin culling logs, not on individual emails.

That’s the whole product worldview. Cleanup is a one-time cohort operation, and a third-party app with permanent mailbox access is overkill for it.

What the survey actually looks like

The survey step is the part the script does. It calls the Gmail API under your own OAuth — read-only scope, gmail.metadata plus gmail.readonly for counts — and writes a single survey.json to your laptop. No message bodies, no subjects, no message IDs. Just counts.

Here’s a redacted version of what one row looks like, the way the script renders it so you can read it before deciding anything:

sender                          count    oldest                  recommended action
─────────────────────────────────────────────────────────────────────────────────────
news@<redacted-saas>.com       11,842   2017-03-12   filter+delete (>1y)
deals@<redacted-airline>.com    7,901   2014-08-19   filter+delete (>1y)
updates@<redacted-network>.com  5,617   2016-01-08   filter+delete (>1y)
no-reply@<redacted-bank>.com    3,402   2018-04-22   filter only (keep — statements)
receipts@<redacted-cart>.com    2,883   2019-06-30   filter only (keep — receipts)
hello@<redacted-newsletter>     2,114   2020-11-04   filter+delete (>2y)
… 6 more rows …                              
─────────────────────────────────────────────────────────────────────────────────────
top 12 senders                 51,883   covers 64.3% of unread >1y

That’s the whole output. Four columns, twelve rows, one summary line. With that table you can decide, in 90 seconds, which senders you want to filter and delete (most of them), which you want to filter only (anything with statements, receipts, security alerts), and which you want to leave alone (the 30%-ish tail of senders you might still care about).

The actual deletion is a second pass — different command, explicit confirmation, dry-run by default. You read the count, you say yes, Gmail moves the cohort to Trash, the 30-day undo window protects you.

Safety properties, in plain English

This is the bit I want to be very precise about, because “we never see your mail” is something every cleaner says, and most of them are stretching.

Read-only OAuth at survey time. The survey command requests gmail.metadata + gmail.readonly. Those scopes cannot delete, send, or modify mail. Google enforces this at the API edge; it’s not a promise, it’s a permission.
Deletion runs under a separate, on-demand gmail.modify scope that you grant only when you actually want to delete, and revoke from your Google account afterwards in one click. The script doesn’t ask for mail.google.com/ (the all-powerful scope) — ever.
The OAuth client is yours. You create the Google Cloud project in your own account, paste the client ID and secret into a config file on your laptop. The tokens are written to a file in your home directory with 0600 permissions. They never touch our infrastructure. I literally cannot read your mail; the credentials only exist on your machine.
The Enterprise tier sidesteps the same problem differently: your IT admin publishes the script as an Internal app inside your Google Cloud organization, which means it’s exempt from Google’s app verification process and the 100-user cap, but also that there’s no “third-party app” to revoke — the script runs as you, on your own org’s Cloud project.

If you’re the kind of person who reads OAuth scope strings before clicking through them — same — that’s the design.

The three ways to do this

Pick the one that matches how much DIY you want to wrangle.

$19 — Inbox Cleanup Pack (DIY). Get it on Gumroad → Pay-what-you-want, $9 floor. The same shell script I used (read-only survey + opt-in deletion), the Gmail filter templates, the exact cohort-by-cohort cleanup order, and the printable Markdown playbook. You run everything on your own laptop under your own Google Cloud OAuth client. No third-party permissions added to your account.

$79 — Inbox Cleanup QuickCheck (we write the plan). Buy on Stripe → You run the same survey script. You send me the survey.json file (counts only — no message bodies, no subjects, no IDs). I send back a written, prioritized cleanup plan tailored to your top senders, your age cohorts, and your tolerance for “delete vs archive.” Delivered within 24 hours, plus one async clarification pass within 14 days — up to 30 minutes’ worth of follow-up questions over email at support@richgibbs.dev.

$499 — Inbox Cleanup Enterprise (up to 10 Workspace mailboxes). Buy on Stripe → For pre-migration or pre-acquisition cleanups across a small team — typically a 2-to-10-person Google Workspace org. Your IT admin publishes our script as an Internal app under your own Cloud project (no third-party verification, no app-store entry, no shared tokens). You run the survey across up to 10 mailboxes, send the merged survey.json, and we write a per-mailbox plan plus the cross-mailbox patterns (shared newsletters worth bulk-filtering across the org, etc.). 5 business day SLA, one async clarification pass within 14 days — up to 30 minutes’ worth of follow-up questions, via email to support@richgibbs.dev. More details on the Inbox Cleanup service page.

All three deliverables are async-only. Email is the only follow-up channel.

If you came in through the deliverability rabbit-hole — receipts going to spam, password resets vanishing — the inbox problem is downstream of the outbox problem, and both are fixable in one sitting:

SPF, DKIM, DMARC for indie founders: the 20-minute checklist — the matching DNS-side hygiene pass for your sending domain.
Cloudflare Email Routing for indie founders: the 10-minute support@ setup — if you don’t even have a support@yourdomain.com yet, start here before you do anything else.

The short version

The “free inbox cleaner” model is a scope-creep trap for a job that runs once.
Survey-then-Delete: count first, identify the top 12 senders, filter the inbound, then bulk-delete by sender and age cohort.
Read-only OAuth at survey time; on-demand gmail.modify only when you’re actually deleting; tokens live on your laptop, not ours.
$19 if you want to run it yourself. $79 if you want me to write the cleanup plan. $499 if you need to do it across a small Workspace team without exposing tokens to a third party.

The 30-day Trash window is your safety net. So is reading the OAuth scope string before you click “Allow.”

— Rich

Tuck Sentinel — independent. Not affiliated with, endorsed by, or certified by Google, Yahoo, Microsoft, AWS, Cloudflare, Stripe, Tally, or any email or cloud provider.

DMARC aggregate reports without a SaaS: read your own rua XML in 30 minutes

Tue, 12 May 2026 14:45:00 +0000

You published a DMARC record. The rua=mailto: part is pointing at a real mailbox you actually read. Reports started arriving 24 hours later. They are zipped XML files with names like google.com!yourdomain.com!1715472000!1715558400.zip, you cannot read them, and every blog post you find tells you to sign up for Postmark, Valimail, dmarcian, EasyDMARC, or some other $20–$200/month SaaS to “decode” them.

You don’t need any of that. The DMARC aggregate-report format is a stable, well-defined XML schema published in RFC 7489 (§7.2), and a working reader takes about 120 lines of stdlib-only Python — no extra packages, no API keys, runs in cron on the same $20 VPS that already runs your mail.

This post is the reading half of that story. What the reports actually contain, what every field means in practice, the 20-line skeleton to walk the XML yourself, what the full reader adds beyond the skeleton, and the cron-friendly workflow that makes the data actionable. If you ever decide you want a SaaS, you will be a much better customer for it.

Why DMARC aggregate (`rua`) reports exist

DMARC, defined in RFC 7489, is a policy layer on top of SPF and DKIM. A receiver (Gmail, Microsoft, Yahoo, Apple, ProtonMail, …) checks each incoming message and decides three things: does SPF pass and align with the RFC5322.From domain, does DKIM pass and align, and what does the domain owner’s published _dmarc TXT record say to do when neither aligns.

The receiver acts on every message immediately. But the domain owner (you) has no idea what happened until somebody complains. Aggregate reports close that loop. From RFC 7489 §7.2:

Aggregate reports are most useful when they all contain the same data; thus this section describes a single report format, generated daily, sent via email, encoded as XML.

In practice, every major receiver who supports DMARC sends one aggregate report per UTC day per sender domain they saw mail from, to the address (or addresses) listed in the rua= tag of your _dmarc record. Each report says: “Here is every source IP that claimed to be sending as your domain in the last 24 hours, how many messages each one sent, and what we decided about each one.” It does not contain message bodies, subjects, recipients, or any other PII. It is metadata only.

That is what makes the format safe to receive, store, and parse on a $20 VPS. Failure reports (ruf=, separate spec) sometimes carry redacted message content; aggregate reports do not. We are talking about rua only.

The shape of a real aggregate XML report

A real Gmail aggregate report, opened in a text editor after gunzip, looks roughly like this (one record shown; a real report typically has 5–50):

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>1234567890123456789</report_id>
    <date_range>
      <begin>1715472000</begin>
      <end>1715558400</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>yourdomain.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>quarantine</p>
    <sp>quarantine</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>50.31.156.6</source_ip>
      <count>42</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>yourdomain.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>yourdomain.com</domain>
        <selector>pm</selector>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>pm-bounces.yourdomain.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Every aggregate report from any receiver has the same top-level shape: one <feedback> element, one <report_metadata> block, one <policy_published> block, and one <record> per source IP per disposition outcome. The schema is fixed by RFC 7489 Appendix C; receivers don’t get to invent new fields.

The report decoder ring

Once you have the XML in front of you, three fields do most of the work.

<source_ip> is the IP address the receiver saw the message arrive from. If it is one of your sending platform’s IPs (a Postmark, Resend, Mailgun, SES, ConvertKit, Mailchimp range), that is good. If it is an IP you have never heard of and the count is non-trivial and alignment failed, that is either a forwarder you forgot about or somebody actively spoofing your domain. Both are worth investigating, but in 2026, the boring forwarder explanation is the answer about 95 % of the time.

<policy_evaluated> is the receiver’s verdict on this batch of messages. Three sub-fields matter:

<disposition> — what the receiver did. none means delivered normally; quarantine means spam-foldered; reject means refused at SMTP time. This is the applied outcome, after any pct= ramp and local override.
<dkim> — whether DKIM passed and aligned with the RFC5322.From domain in <identifiers><header_from>.
<spf> — same, for SPF alignment (the MAIL FROM / Return-Path domain must align with header_from).

The single most common indie-founder confusion is the difference between <auth_results> (the raw SPF/DKIM verification result on whatever domains the message presented) and <policy_evaluated> (whether those results aligned with the visible From: domain). A message can have <auth_results><dkim><result>pass</result></dkim> and still show <policy_evaluated><dkim>fail</dkim> — DKIM technically passed, but the signing domain was mailgun.org instead of your domain, so DMARC alignment failed. That is the most common deliverability bug in this whole article. Fix it by enabling “Custom domain DKIM” on the offending provider.

<header_from> under <identifiers> is the RFC5322.From domain — what the recipient sees. If this is ever a domain other than yours (a subdomain you forgot, an old sending domain), every alignment decision in the same record is being judged against that domain, not your apex.

RFC 7960 (“Interoperability Issues Between DMARC and Indirect Email Flows”) is the official, RFC-blessed description of why honest forwarders break DMARC alignment — mailing lists, forward-to-personal-inbox aliases, and any hop that rewrites headers will show <policy_evaluated><dkim>fail</dkim> on aggregate reports while not being malicious. That is the moment to read the ARC spec, RFC 8617, and decide whether to enable ARC on your forwarder or just stop forwarding mail you publish DMARC for.

A 20-line stdlib-only skeleton

You can read every report on disk with nothing but the Python standard library. Here is the smallest correct skeleton that walks every record in a single XML file:

import xml.etree.ElementTree as ET
from pathlib import Path

def walk(path: Path):
    tree = ET.parse(path)
    root = tree.getroot()
    org = root.findtext("report_metadata/org_name", default="?")
    dom = root.findtext("policy_published/domain", default="?")
    for rec in root.findall("record"):
        ip    = rec.findtext("row/source_ip", default="?")
        count = int(rec.findtext("row/count", default="0"))
        disp  = rec.findtext("row/policy_evaluated/disposition", default="?")
        dkim  = rec.findtext("row/policy_evaluated/dkim", default="?")
        spf   = rec.findtext("row/policy_evaluated/spf", default="?")
        hfrom = rec.findtext("identifiers/header_from", default="?")
        yield (org, dom, ip, count, disp, dkim, spf, hfrom)

for f in Path("reports").glob("*.xml"):
    for r in walk(f):
        print("\t".join(map(str, r)))

That is the whole reading layer. Run it against a directory of un-gzipped XML reports and you have a tab-separated table you can pipe into awk, sort -k4 -n, or just grep fail.

What a full reader adds on top of this 20-line skeleton — and what the paid pack ships pre-built — is:

Transparent .gz, .zip, and raw-.xml handling (receivers disagree on compression; some send a .zip containing an .xml, some send a .xml.gz, Microsoft used to email both).
Grouping by source domain and by sending sub-domain, so the report says “Postmark sent 1,420 messages on your behalf today, all aligned” instead of one row per IP.
Disposition rollups: how many none vs. quarantine vs. reject per sender, per day.
ARC results from <auth_results> (per RFC 8617), so legit forwarders are flagged as “ARC-rescued, ignore” instead of “DKIM fail, panic.”
A multi-day rolling view so a one-bad-day spike does not page you but a seven-day trend does.
An “unknown sender” alert for any source IP that has never appeared in your historical reports and is sending more than N messages a day.

The 20-line skeleton is enough to learn the data. The 120-line full reader is what you keep in cron.

A cron-friendly daily workflow

Once you can read the reports, the workflow is short.

Use a dedicated mailbox. Point rua=mailto:dmarc-reports@yourdomain.com at an alias you do not read directly. Cloudflare Email Routing forwarding into a labeled Gmail folder works perfectly for this; so does a Postfix .forward into a Maildir on the same VPS. Google’s own Workspace Admin Help DMARC guide recommends the same separation.
Fetch on a schedule. Pull the new attachments out of that mailbox once an hour. IMAP, the Gmail API (under your own internal-app OAuth client), or a simple notmuch new + maildir scan all work. Drop the attachments under ~/dmarc/reports/.
Parse and roll up. Run the reader nightly. Append a row per (date, sender_domain, source_ip, count, dkim_aligned, spf_aligned, disposition) to a CSV or SQLite file. This is the historical record you query when something breaks.
Alert only on change. Mail yourself when (a) a brand-new source IP appears and sends more than ~50 messages, (b) a previously-aligned sender’s DKIM-alignment rate drops below 95 % for two consecutive days, or (c) any disposition=reject count goes above zero for a sender you care about.

That is the entire pipeline. There is no dashboard, no per-domain license, no “trust score.” The data is the data.

When you actually do need a SaaS

Be honest: the boring DIY pipeline above is correct for a single domain, one or two sending sub-domains, and 5–50 reports a day. The point at which a SaaS starts pulling its weight is roughly:

More than ~5 active domains, especially if a deliverability team wants a shared dashboard.
High-volume marketing senders (>500k messages/month) where you want forensic (ruf=) reports correlated with bounce categories.
Anything that needs SPF/DKIM hygiene enforced across an org with 50+ employees and rotating contractors.
Compliance contexts (Microsoft anti-spam configuration docs are worth reading here too) where someone external wants an audit trail of the policy itself.

For one indie founder with one domain and three senders? You are the worst customer dmarcian will ever have. Read your own reports.

If you want the full Python reader (gzip- and zip-aware, sub-domain rollups, ARC handling, the unknown_sender alert function, plus three real incident walkthroughs — marketing-tool DKIM drift, forgotten sub-domain, forwarder/ARC breakage — and a DSN decoder cheat-sheet for Gmail 5.7.26 and Microsoft 5.7.509 / 5.7.515) in one bundle, the DMARC Quarantine Pack — $29 on Gumroad has it. 14-day refund, no questions.

SPF, DKIM, DMARC for indie founders: the 20-minute checklist — the prerequisite. Publish a sane _dmarc record and a rua= target first; then the aggregate reports in this post will actually start arriving.
Cloudflare Email Routing for indie founders: the 10-minute support@ setup — the cleanest way to give your dmarc-reports@yourdomain.com alias a real destination without paying for a Workspace seat, and the post that explains the one forwarder hop ARC (RFC 8617) is designed to rescue.
Related downloadable pack: DMARC Quarantine Pack — $29 on Gumroad — the full single-file Python reader, three real-incident walkthroughs, and the DSN decoder cheat-sheet for when DMARC moves from p=none to p=quarantine and a specific sender starts getting bounced. 14-day refund, no questions.

Rich Gibbs

Ubuntu/Debian EC2 hardening checklist (2026)

Why this checklist

Threat model assumptions

1. SSH

2. Firewall and listeners

3. OS updates and reboots

4. Admin surface

5. EC2 metadata service (IMDSv2)

Mid-article CTA

6. Logging and time sync

7. Backups and restore drills

8. Docker basics (if applicable)

What this is not

End-article CTA

About Tuck Sentinel

The Indie Founder's VPS Security 101

What “secure enough” looks like for one box

First-day setup

1. Create a non-root user with sudo

2. Set up SSH keys and disable password login

3. Turn on the firewall

4. Enable automatic security updates

Worried you missed something on first-day setup?

What to actually monitor

Failed logins

Listening ports

Disk free

Package updates available

Backups and restore drills

Don’t over-do it

Common mistakes

Worth a free second opinion?

What this is not

About Tuck Sentinel

AWS IMDSv2 Migration Without Breaking Things

Why Migrate

What Breaks

Detect IMDSv1 Use

CloudWatch metric: MetadataNoToken

Inventory: which instances even allow v1?

CloudTrail and VPC flow logs

On-host detection

Migration Steps

1. Baseline and freeze new IMDSv1

2. Sort instances into waves

3. Optional: try optional → required with a hop bump

4. Roll Auto Scaling groups

5. Sweep and confirm

Validation

Confirm v2-required at the API level

Confirm v1 is actually rejected on the host

Confirm credentials still resolve

Confirm app-level health

Confirm MetadataNoToken is zero

Rollback

QuickCheck CTA

What This Is Not

About Tuck Sentinel

SPF, DKIM, DMARC for indie founders: the 20-minute checklist

What “set up email DNS” actually means in 2026

The 20-minute checklist

1. List every tool that sends mail “from” your domain (3 minutes)

2. Pick exactly one SPF record (5 minutes)

3. Add DKIM for each sending tool (5 minutes)

4. Publish a cautious DMARC (3 minutes)

5. Verify the result with one real email (4 minutes)

Things to deliberately ignore in v1

Common gotchas an indie founder will hit

Next step: a $99 second pair of eyes

Related downloadable pack

Cloudflare Email Routing for indie founders: the 10-minute support@ setup

What Email Routing actually is

The 10-minute path

1. Enable Email Routing (1 minute)

2. Verify the destination address (2 minutes)

3. Add a routing rule (1 minute)

4. (Optional) Catch-all (30 seconds)

5. Send a real test (1 minute)

The one thing Email Routing does not do — and what to do instead

CloudWatch metric: `MetadataNoToken`

3. Optional: try `optional` → `required` with a hop bump

Confirm `MetadataNoToken` is zero

4. Delete the truly dead — with `older_than:` and a safety net

Why DMARC aggregate (`rua`) reports exist