The Red Teamer’s Pre-Flight Checklist for Domain Reputation

The alert fires less than ten minutes after your first payload goes out. Your beautifully crafted pretext, the C2 infrastructure you spent days on, the bespoke payload—all burned. The blue team didn't outsmart your TTPs; they didn't even see them. Your email never made it past the gateway.

This isn't a failure of offensive tradecraft. It's a failure of basic infrastructure hygiene. In the age of automated, cloud-native security stacks, the reputation of your sending domain and IP is analyzed before a human ever sees the subject line. If you look like a threat actor, you are one, and the email dies in quarantine.

The goal of a modern phishing campaign isn't just to evade the sandbox. It's to look so boringly legitimate, so compliant with email standards, that you sail right through the automated trust and reputation scanners. Here's how to build that infrastructure, one DNS record at a time.

Step 1: Stop Buying Freshly Registered Domains

Every security appliance on the planet places zero trust in a brand-new domain. The correlation between a domain registered yesterday and a malicious email sent today is astronomically high. Buying a domain and using it immediately is the single loudest signal of amateur offensive operations.

The Art of 'Aging' and Acquiring History

Reputation is built on history. You need a domain with some. Your options are to buy a new domain and 'age' it, or to acquire an expired domain that already has a benign history. Aging means registering the domain and letting it sit dormant for 30, 60, or even 90 days. During this time, you can put up a simple, static website—a single `index.html` with some plausible placeholder text is sufficient. The key is that for weeks, resolvers and crawlers see the domain exist without it ever sending a single malicious email.

Acquiring expired domains is faster but riskier. You might inherit a domain with a great reputation, or you might inherit one that was previously used for spam and is blacklisted across the internet. Diligence is non-negotiable. Look for domains that had actual content, have some backlinks from legitimate sites, and don't appear on threat intelligence feeds. The TLD matters, too. Stick to `.com`, `.org`, `.net`, or a plausible country code. Novelty TLDs like `.zip` or `.live` are themselves a massive red flag.

Step 2: Authenticate Like You Mean It (But Not Too Much)

Email authentication isn't a checkbox; it's a statement about your operational maturity. SPF, DKIM, and DMARC are the three pillars, and getting them right—but not *too* right—is critical for your pretext. The goal is to look like a legitimate organization in the process of implementing security, not a perfectly locked-down fortress.

SPF and DKIM: The Non-Negotiables

Sender Policy Framework (SPF), defined in RFC 7208, is a TXT record that declares which IP addresses are authorized to send mail for your domain. It must be present, and it must be valid. A common mistake is a syntax error or including too many DNS lookups. Your SPF record should be simple, referencing the IP of your mail server: `v=spf1 ip4:198.51.100.10 -all`. This passes the check. That's the only job it has.

DomainKeys Identified Mail (DKIM), per RFC 6376, provides a cryptographic signature that verifies the message body hasn't been altered in transit. This is crucial for bypassing filters that look for content rewriting, a common issue with mail forwarders. You must generate a key pair, publish the public key in a TXT record, and configure your mail server to sign every outgoing message. A `pass` on DKIM is a huge trust signal.

DMARC: The Tell-Tale `p=none`

This is where nuance wins. Domain-based Message Authentication, Reporting, and Conformance (DMARC), via RFC 7489, tells a receiver what to do if SPF or DKIM checks fail. An aggressive policy of `p=reject` on a brand new, low-volume domain is suspicious. It screams that you know exactly what you're doing. A far more believable policy is `p=none`. This policy says, 'I'm starting to monitor my email authentication, but I don't want you to block anything yet.' It's the posture of a typical IT department.

Authentication-Results: mta.example.com; dkim=pass header.d=yourphish.com; spf=pass (sender IP is 198.51.100.10); dmarc=pass (p=none sp=none dis=none) header.from=yourphish.com

This header line is your goal. A `pass` on SPF and DKIM for authentication, and a `pass` on DMARC because your policy is set to monitoring-only. It’s the perfect signature of a harmless, administratively normal domain.

Step 3: Your IP Address Is Your Neighborhood

You can have a perfectly aged domain and flawless DNS records, but if your mail server is running on an IP address in a bad neighborhood, you're still going to land in spam. IP reputation isn't just about your specific address; it's about the entire subnet and the Autonomous System (AS) it belongs to.

Most cheap VPS providers recycle IPs frequently. The address you were just assigned might have been used for a C2 server last week. Security vendors don't just blacklist single IPs; they blacklist entire /24 blocks and assign poor reputation scores to ASNs known for hosting malicious infrastructure. Spinning up a server on a $5/month host is practically an admission of guilt.

Invest a little more in a dedicated server or a VPS from a provider that caters to businesses, not botnets. Before you commit, run the provider's IP ranges through public blocklist checkers. Is the ASN frequently flagged for abuse? Are adjacent IPs on blacklists? You are judged by the company you keep, and on the internet, your neighbors are the other IPs in your subnet.

Step 4: Audit Yourself Before They Do

The biggest operational mistake a red teamer can make is flying blind. You must validate your setup using the same kinds of tools your target's security team uses. Publicly available domain reputation and email security checkers are your best friends. They give you a defender's-eye view of your own infrastructure.

Send a test email from your phishing domain to an address you control that logs headers, or use one of the many online mail testers. Then, scrutinize the results. Don't just look for a pass/fail. Look at the details.

Your Pre-Launch Checklist

First, check the basics. Did your SPF and DKIM records validate correctly? Does your DMARC policy appear as `p=none`? Are there any syntax warnings or `temperror` verdicts? A temporary error is as bad as a fail; it signals misconfiguration and incompetence.

Second, analyze the IP and domain reputation scores. Do these tools flag your IP as being part of a known hostile network? Is your domain flagged as newly registered? Do you have a proper reverse DNS (PTR) record that matches your mail server's hostname? Missing a PTR record is a classic spammer trait.

Finally, check for email server best practices. Are you using TLS for transport? Do you have an MTA-STS policy (RFC 8461)? While not strictly necessary, having one in place adds another layer of legitimacy. The goal is to have zero red flags. Not one. Any small warning could be the one variable that tips the scale from `deliver` to `quarantine`.

Advanced Evasion: The Power of Subdomain Reputation

Once you have a primary domain that is aged, warmed, and has a history of sending non-malicious traffic, you unlock a powerful new technique: subdomain delegation. Many reputation systems are heavily weighted toward the parent domain. The trust established by `legitcorp.com` can be inherited, at least partially, by `security-update.legitcorp.com`.

This allows for more rapid campaign deployment. Instead of aging a new domain for 90 days, you can create a new subdomain on your trusted parent domain, point its MX and SPF records to your new campaign infrastructure, and launch much faster. The implicit trust granted to the parent domain provides cover.

This isn't a silver bullet. Some security products are smart enough to treat subdomains with new, distinct sending infrastructure as entirely new entities. But in many cases, especially within less mature security environments, the reputation of the parent domain provides enough of an initial trust boost to get your first emails delivered. It diversifies your infrastructure portfolio and makes you less reliant on a single, slow method of establishing credibility.

The takeaway

The days of `sendmail` from a shell script are long gone. Successful phishing campaigns are now exercises in meticulous bureaucracy. They require patience, an understanding of internet protocols, and a willingness to emulate the mundane reality of corporate IT. Your goal isn't to look clever; it's to look boring.

The core principle is to use a defender's toolkit against itself. Before you ever send an email to a target, you should know exactly how your infrastructure appears to an automated gateway. Run your domain through a full-stack analysis tool, fix every warning, and present a surface that is indistinguishable from a new but legitimate business. A pre-flight check using a tool like MailSleuth.AI isn't paranoia; it's just good opsec.