The 'Good Enough' Domain: A Red Teamer's Guide to Reputation Evasion

The most dangerous phish in your user's inbox won't come from a domain like `micros0ft-login.biz`. That's amateur hour. The real threat arrives from `corp-billing.net`, a domain registered 90 days ago, with perfect SPF and DKIM, and a history of sending nothing but benign newsletters until today.

This isn't about burning a zero-day or finding a complex vulnerability in an email gateway. This is about playing the long game. It's about understanding that most automated email defenses aren't looking for sophisticated attacks. They're programmed to spot the obvious failures: the blacklisted IPs, the missing authentication records, the domains born yesterday. They are lazy gatekeepers.

The objective isn't to build a domain with a pristine, A+ reputation. That takes too much time and effort. The goal is to build a 'C-minus' domain—one that is just good enough to not trigger the obvious alarms. It blends in by looking slightly, and believably, imperfect.

The Acquisition: Aged Wine or Freshly Minted?

Your first decision is where to source your domain. This choice dictates the entire timeline of your operation. You're balancing the immediate trust of an aged domain against the clean-slate control of a new registration.

Expired Domains: A Risky Head Start

Scouring auction sites and expired domain lists for something with a few years of age is tempting. The primary benefit is bypassing the most basic filter: domain age. A domain registered in 2018 is inherently less suspicious than one registered last Tuesday. It might even come with a benign categorization from previous use, like 'business' or 'blogging', and some non-spammy backlink history.

But this path is loaded with risk. You have no idea what that domain was *really* used for. The previous owner could have used it for a spam campaign that got it on private blocklists you can't easily check. Its 'clean' history might just be a period of dormancy after being part of a botnet's C2 infrastructure. The due diligence required is significant, and you might end up with a toxic asset that gets your entire infrastructure burned on day one.

Newly Registered Domains: The Slow Burn

Registering a new domain gives you absolute control, but you start with a massive trust deficit. Zero domain age is the reddest of red flags for any reputation system. This means you are committing to a longer warm-up phase, sometimes lasting weeks or months, before you can even think about sending a payload.

The art here is in the name itself. Obvious typosquatting (`googgle.com`) is for script kiddies. The professional choice is combosquatting or level-squatting. Think `[target]-portal.com`, `[target]-secure.net`, or `[target].auth.app`. These look plausible. They look like the kind of domains a marketing department or an IT vendor would spin up for a specific project. Stick to reputable TLDs like `.com`, `.net`, or `.org`. Using `.xyz`, `.top`, or `.icu` is like wearing a fake mustache to a security conference—it just draws the wrong kind of attention.

The Foundation: Minimum Viable Authentication

Once you have your domain, you need to build its technical foundation. Getting email authentication right is critical, but 'right' in this context means 'plausibly configured,' not 'perfectly secure.' You want to pass the checks, not win an award for security posture.

SPF and DKIM: Check the Box

Sender Policy Framework (SPF), defined in RFC 7208, is a DNS record that says which IP addresses are allowed to send mail for your domain. A missing SPF record is an immediate fail. But an overly restrictive one (`v=spf1 -all`) can be problematic if you need flexibility. The sweet spot is often a softfail: `v=spf1 mx ~all`. This tells the receiver, "Mail should probably come from my MX records, but if it comes from somewhere else, just treat it as slightly suspicious, don't hard-reject it." This configuration is common for legitimate businesses struggling with third-party senders and forwarders, making it an excellent camouflage.

DomainKeys Identified Mail (DKIM), per RFC 6376, provides a cryptographic signature that verifies the message body hasn't been tampered with. Setting it up is non-negotiable. Most gateways will heavily penalize mail without a valid DKIM signature. The key is that just having a `dkim=pass` verdict is usually enough. Many gateways, shockingly, do not validate DMARC *alignment*—meaning they don't check if the domain in the DKIM signature (`d=`) actually matches the domain in the `From:` header. This is a massive gap that attackers exploit daily.

DMARC: The Art of p=none

Domain-based Message Authentication, Reporting, and Conformance (DMARC), outlined in RFC 7489, tells a receiver what to do if SPF or DKIM checks fail. An attacker doesn't want to enforce a strict policy. The perfect DMARC record for a 'good enough' domain is `v=DMARC1; p=none; rua=mailto:someaddress@domain.com`. This policy does three things beautifully: it signals that you are a modern, DMARC-aware sender; the `p=none` (monitoring) policy tells the receiver not to quarantine or reject your mail even if something fails; and it provides a reporting address, adding another layer of legitimacy.

Authentication-Results: mta.example.com; spf=pass smtp.mailfrom=billing-corp.net; dkim=pass (2048-bit key) header.d=billing-corp.net; dmarc=pass (p=none) header.from=billing-corp.net — A sample Authentication-Results header showing perfect passes with a non-enforcing DMARC policy.

This combination is the holy trinity of 'good enough' authentication. It passes every automated check without imposing any real restrictions on your operations.

The Warm-Up: Faking Legitimacy at Scale

With a newly registered domain and perfect-looking authentication records, your reputation is still zero. Any sudden spike in email volume will immediately flag your domain for review. The warm-up phase is a delicate process of building a positive sending history without getting noticed.

The first step is to establish a sending rhythm. Start by sending a tiny volume of emails—maybe 10-20 per day—to a distributed set of mailboxes that you control at high-reputation providers (Gmail, Outlook.com, ProtonMail). The content must be utterly benign. Think fake newsletters, privacy policy updates, or account verification emails. Include unsubscribe links that actually work. The goal is to generate positive engagement signals: deliveries, not bounces; opens, not spam complaints.

This process helps email providers categorize your domain. If your first hundred emails are about 'Cloud Solutions Monthly', your domain gets tagged as 'marketing' or 'business services', not 'suspicious'. You are actively shaping your own reputation.

Slowly increase the volume, following a logarithmic curve. 20 emails one day, 40 the next, then 80, and so on. Mix up the content and sending times. Any predictable pattern is a potential indicator for a machine learning model. During this phase, you must avoid all known traps. Never use scraped email lists, which are riddled with honeypots designed to instantly blacklist you. Every bounce, every spam complaint is a step backward. This is a grind, but it's the only way to build the history needed to survive the automated filters when you finally send your payload.

Blue Team Defense: It's All About Composite Scoring

So how do you defend against an attacker who isn't making obvious mistakes? You stop relying on single data points. A `dmarc=pass` verdict is not a seal of approval. It's just one signal, and a weak one at that. The only effective defense is to build a composite risk score based on a mosaic of signals.

Stop trusting the `Authentication-Results` header at face value. A domain registered 21 days ago should not be sending password reset links, regardless of its SPF pass. Your gateway rules should correlate domain age with message intent. A young domain sending marketing material might be okay. A young domain sending an urgent wire transfer request is a five-alarm fire.

Dig into the headers. Where did the email originate? Look at the `Received` headers. Was it sent from a known, reputable email service provider, or from a cheap VPS provider in a country you don't do business with? Look at the ASN of the sending IP. Does the sending MUA (Mail User Agent) look legitimate or is it a generic, script-generated value? These are all pieces of the puzzle.

A passing DMARC check with a p=none policy from a domain less than 90 days old is more suspicious than an SPF failure from a trusted ten-year-old partner domain.

Furthermore, enforce DMARC alignment. It's not enough that DKIM passes; the domain in the `d=` tag of the DKIM signature must match the domain in the `From:` header. This single check defeats a huge swath of phishing attacks that use legitimate third-party sending services. Most SEGs can enforce this, but it's often not the default setting. Turn it on. Finally, look for the 'too perfect' signature. An attacker warming up a domain sends benign content with unsubscribe links and clean HTML. When that same domain suddenly sends a message with a weaponized attachment, that behavioral shift is the most important signal you have.

The takeaway

The 'good enough' domain evades security filters because it's designed to look like the noisy, imperfect, legitimate email ecosystem we all inhabit. It doesn't trigger alarms because it mimics the background radiation of everyday corporate mail. For red teamers, this is a patient, effective tradecraft. For blue teamers, it's a call to action.

Defenders must move beyond binary pass/fail logic. You have to think like an intelligence analyst, not a security guard. Every email has a history, a context, a motive. Correlating dozens of small, seemingly insignificant signals is the only way to spot the chameleon in the weeds. A platform like MailSleuth.AI can help automate the deep header analysis and signal correlation, but the strategic shift from trusting authentication to questioning everything must start with the analyst.