Ever wonder why your critical system alerts are buried under pizza delivery receipts? Here’s a real-world guide from the trenches on why users mix personal and work emails for services, and how you, the DevOps engineer, can fix it without starting an office war.

Confessions of a Cloud Architect: Your Pizza Order Isn’t a P0 Incident

It was 2:15 AM. My phone buzzed with the fury of a thousand angry hornets—the high-priority alert channel for our production database cluster, prod-db-01. My heart pounded as I scrambled for my laptop, imagining data corruption, a full-blown outage, or worse. I finally got the alert open, eyes blurry, and read the subject line: “Your Grubhub order is on its way!” Someone—a junior engineer, it turned out—had used our primary PagerDuty email, critical-alerts@techresolve.com, to sign up for a food delivery service. In that moment, I wasn’t angry. I was just tired. And this, my friends, is a story that plays out in every IT department, every single day.

First, Let’s Understand the “Why”

Before we start locking things down, let’s put on our empathy hats for a second. No one does this to be malicious. The root cause is simple: convenience. A user is setting up a new tool, a SaaS platform, or a developer account. The system asks for an email. What email are they already logged into on their work machine, with the password saved and multi-factor auth already cleared? Their work email. It’s the path of least resistance. They see an input box, they fill it with what’s easiest, and they move on, completely oblivious to the alert-storm they may have just unleashed on some poor on-call engineer.

Pro Tip: Never attribute to malice that which is adequately explained by convenience. Your users aren’t your enemy; their habits are. Our job is to make the correct path the easiest path.

The Fixes: From a Gentle Nudge to a Sledgehammer

We can’t just send a company-wide memo and hope for the best. We need to architect solutions that guide users toward the right behavior. I’ve got three approaches in my toolkit, ranging from a quick patch to a permanent architectural change.

1. The Quick Fix: The Targeted Mail Filter

This is the “stop the bleeding now” approach. It’s hacky, it’s not scalable, but it’ll get you through the night. The idea is to create server-side rules that filter out the noise before it ever hits your inbox or alert system. Let’s say you’re using a distribution list or a shared mailbox in Google Workspace or O365, or even a service like AWS Simple Email Service (SES).

You can implement a rule that automatically deletes or archives messages from common non-work domains. In AWS SES, you could create a Receipt Rule Set that triggers a Lambda function to inspect the sender. The Lambda can check the sender’s domain against a blocklist (`@dominos.com`, `@uber.com`, `@github.com` for personal account notifications, etc.) and simply stop processing the email if it matches.

// A super simple pseudocode example for an AWS Lambda function
// triggered by an SES Receipt Rule

const blocklist = ['dominos.com', 'grubhub.com', 'amazon.com'];

exports.handler = async function(event) {
  const record = event.Records[0].ses;
  const fromAddress = record.mail.source;
  const fromDomain = fromAddress.split('@')[1];

  if (blocklist.includes(fromDomain)) {
    console.log(`Blocking email from ${fromAddress}. Reason: Domain on blocklist.`);
    // Returning 'STOP_RULE_SET' tells SES to stop processing this email.
    return { disposition: 'STOP_RULE_SET' };
  }

  // If not on the blocklist, continue processing.
  return { disposition: 'CONTINUE' };
};

It works, but you’ll be playing a constant game of whack-a-mole, adding new domains to your blocklist forever.

2. The Permanent Fix: Dedicated Service Accounts & Aliases

This is the right way to do it. Stop using user-like emails for services. Your monitoring, CI/CD, and cloud platforms should not be tied to an email address that looks like a person’s.

Instead, create dedicated, non-human service principals. For example:

• For monitoring: monitoring.svc@techresolve.com or even better, a plus-aliased address like monitoring.svc+pagerduty@techresolve.com.
• For CI/CD notifications: cicd.runner.svc+github@techresolve.com.
• For cloud provider billing alerts: cloud.billing.svc+aws@techresolve.com.

Why is this better? Three reasons:

1. Clarity: It’s immediately obvious what the address is for. No one is going to accidentally use cicd.runner.svc+github@techresolve.com to order a burrito.
2. Granular Control: You can set up extremely strict mail flow rules for these accounts. For example, the cloud.billing.svc+aws@techresolve.com account can be configured to only accept emails from `@amazon.com` addresses. Everything else gets bounced.
3. Security: These accounts shouldn’t have human login privileges. They are mail-enabled objects, not full-fledged user accounts. This reduces your attack surface.

Warning: This requires buy-in and a bit of re-architecture. You’ll have to go back through your services and update the contact information. It’s a project, not a quick fix, but it pays dividends in sanity.

3. The ‘Nuclear’ Option: The IAM Policy Sledgehammer

Sometimes, you have that one team or that one application that just won’t comply. They keep using a shared email for everything, personal and professional. It’s time to get tough. This is where you enforce policy through code.

Let’s say the problematic email is dev-team-alerts@techresolve.com, and it’s being used to send alerts from an EC2 instance via SES. You can write an IAM policy that restricts *what that EC2 instance’s role is allowed to do*. Specifically, you can restrict the ses:SendEmail action to only allow sending emails to approved internal domains.

Here’s an example IAM policy statement:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowSendingOnlyToInternalAndPagerDuty",
            "Effect": "Allow",
            "Action": "ses:SendEmail",
            "Resource": "*",
            "Condition": {
                "ForAllValues:StringLike": {
                    "ses:Recipients": [
                        "*@techresolve.com",
                        "*@techresolve.pagerduty.com"
                    ]
                }
            }
        }
    ]
}

If a developer tries to sign up for “Cool Dev Tool Weekly” using that address from an application running with this IAM role, the confirmation email will simply fail to send from the backend. The API call to SES will be denied. No alert, no angry email, just a silent, effective block. It forces them to ask, “Why isn’t this working?” and that’s when you can teach them the right way.

Choosing Your Weapon

So, which path should you take? It depends on your situation. Here’s how I break it down.

At the end of the day, our job isn’t just to build infrastructure; it’s to build stable, reliable systems. That means managing the biggest variable of all: people. By making the right way the easy way—and the wrong way impossible—we can finally get some sleep. And maybe even order a pizza for ourselves, using our personal email address.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions