Building a covert SMTP infrastructure – Part 1


Phishing is a ray of light when every attempt to breach an organization fails. However, setting up a covert SMTP infrastructure for phishing is a time consuming and painful process. By a covert SMTP infrastructure, I mean an infrastructure:

  • which has an ability to evade detection; typically to throw off blue teams
  • which has resilience; to spin up a new infra quickly

Obviously, instead of setting up your own infrastructure, you can use third party services such as Sendgrid, Elastic Email, etc. , but these have their own constraints such as:

  • Inability to have granular control over the IP assignment: In many cases IP address assigned to the SMTP server has a poor reputation, compromising success rate of your phishing campaign
  • Rate limiting: Most of the vendors implement rate-limiting controls when sending emails, especially for newly created accounts
  • Account suspension: Personally, I have faced this issue multiple times, wherein, your account gets suspended as suspicious activity is detected from your account, which you cannot argue with.

I tasked myself to set up an SMTP infra recently for red team engagement. I referenced a lot of good resources but till the time of writing this post, I could not find a guide to set up an end to end infrastructure which ensures email delivery (though email delivery depends upon many factors apart from SMTP configuration which is out of the scope of this post).

In this series, I will cover the complete setup of a covert infrastructure which has the following key highlights:

  • Entire infrastructure will be setup on DigitalOcean cloud environment
  • For a newly configured domain and basic HTML email content, the email score should be near perfect, e.g. scoring 9 out of 10 on a popular email spam check portals such as
  • Redirector will be used to hide the identity of the backend SMTP server


Let’s talk about the design and components of the infrastructure.

Basic Infrastructure Design

Let’s explore all the components in the figure:

  1. Attacker: It’s an attacker who will send an email by connecting to the SMTP server. In this case, the attacker connects with the core SMTP server.
  2. Core SMTP server: This is the SMTP server that we use as a backend SMTP server. Details are below:
    • The attacker connects to this server to send the email to the target.
    • It is integrated with the relay server. So, instead of sending them emails directly to the victim, the emails are relayed via the redirector server.
  3. Redirector server: This is the SMTP server which acts as a buffer between the victim and the core SMTP server. The purpose of this server, as mentioned earlier, is to evade detection and maintain resiliency, in case this server is blacklisted by the blue teams such as SOC.
  4. Target: An email is received by the victim. Once the configuration and setup is proper:
    • The victim will not be able to trace the identity of the core SMTP server.
    • Traffic and header analysis will only show communication with the redirector server.

What will this series cover

Now that we have laid down the vision, let us get started with setup on the infrastructure. The process of setting up the infrastructure will be as follows:

  1. Core SMTP server Setup
  2. Setting DNS Records
  3. Other Major Considerations
  4. Pilot Run
  5. Setup of SMTP redirector
  6. Integration of SMTP redirector with the core SMTP server
  7. Configuration changes to conceal the identity of our core (backend) SMTP server

In this first part, we will be cover from point 1 to point 4. The remaining areas will be covered in the next part.

Core SMTP server setup

Let’s dive into the setup of the core SMTP server. I have provisioned an Ubuntu 18.04 LTS droplet on DigitalOcean for this. For the entire series, I will refer to this machine as “coremx”, which denotes our core SMTP server. The setup goes as follows:

Installing a mail server solution

For this, we are going to use iRedMail, which is a full-fledged email server solution. This will give us a nice web front end to configure the mail server and will also install all other necessary components. Following are the open-source components that are integrated in iRedMail:

I won’t walk you through the steps for the installation of iRedMail. You can follow for a detailed guide on installing iRedMail

I will use my domain “” for the setup. Post completion of the installation, I get the following output:

Ensure that you change hostname of the server to an FQDN. The hostname along with the domain will be used to make up the URL for accessing the web portals

Setting DNS records

Once you have installed the iRedAdmin, essential email services such as Postfix, etc. have been installed too. The next step is to work on the DNS records which will essentially decide whether your email will land in the Inbox or not. Specifically, we will be setting the below records:

A Record

An “A” record simply points a fully qualified domain name to an IP address. To access the above-created URLs by iRedAdmin (, etc.), we need to add an A record pointing to our droplet’s IP which is running iRedAdmin. I am using Godaddy and an “A” record will look like this:

MX Record

An “MX” records tell the world the email server they need to contact to send an email to your domain. In this case, we need to advertise an MX record for the domain “”. This will again be the IP address on which our mail service is running.

SPF Record

An “SPF” record verifies if the email is received from an approved list of the sender. For a domain, the owner publishes a list of approved senders. The receiving mail server does the following:

  • checks the “Return-Path” message header to extract the domain
  • checks the SPF TXT record for that domain
  • validates if the sender IP address is in the list of the approved list of senders in SPF

You can use to generate an SPF record.

DKIM Record

DKIM is an email authentication mechanism to detect email spoofing. It allows the receiver to verify if the email is coming from a domain who is an authorized owner of the domain.

For each outgoing message, a private key is used to generate a DKIM signature. The owner of the domain publishes the public key as a DNS TXT record. Once the receiver receives the message, it queries the DNS record to retrieve the public key. This public key is then used decode the signature and verify if the message is from a genuine sender or if someone is spoofing your domain

Note that as we configured while the installation of iRedAdmin, the DKIM keys are already generated. For a new domain, you will first need to generate the DKIM keys. Refer to for detailed steps.

Lets look at the steps to configure DKIM for domain

Once I login into coremx, I ran the amavisd-new showkeys to list the keys:

From this output, we need to extract the data within the () block, but we need to remove the quotes. The extracted value is the DKIM DNS record. The output will look something like this.


Now, we need to add this record in the domain. Note that the name of the DNS record is dkim._domainkey. This is also called the DKIM selector.

I verified if DKIM had been configured correctly by amavisd-new testkeys running on the coremx, and got the following output:

You can also verify the DKIM record via It analyses the record such as key strength, the configuration of tags used, etc.

DMARC Record

Quoting from Microsoft, Domain-based Message Authentication, Reporting, and Conformance (DMARC) work with Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) to authenticate mail senders and ensure that destination email systems trust messages sent from your domain. Implementing DMARC with SPF and DKIM provides additional protection against spoofing and phishing emails. DMARC helps to receive mail systems determine what to do with messages sent from your domain that fail SPF or DKIM checks,

To state the working of DMARC more precisely, DMARC tests and enforces identifier alignment. Few key points to consider are below:

  • Identifiers are SPF and DKIM records.
  • Authenticated identifiers are checked against mail user agent(MUA) visible “RFC5322.From” domain. Only one authenticated identifier has to align for the email to be considered in alignment.
  • DMARC has a concept of aligned and unaligned emails, which will not be covered in detail in this post. Aligned emails are delivered to the user mailbox and actions are taken on unaligned emails, based upon directive set by the domain authority via DMARC DNS record.

I understand that the working of DMARC can be hard to grasp at first and I would suggest you visit for detailed insight in working on DMARC.

DMARC is set as a TXT record and you can generate the DMARC record using I created the following basic DMARC record.

Type: TXT
Value: v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected] 

The record states the following:

  • As the value of “p” is set to “none”, the sender does not want any action by the receiver on unaligned incoming emails. DMARC is only set to monitoring mode. Other options are either to “quarantine” or “reject” the unaligned emails.
  • Aggregate and forensic reports are to be sent to [email protected]

The record looks like this in the DNS manager:

We have now set up all DNS records which are essential for our email delivery. Let’s jump to the next section now, which includes other necessary conditions that need to be met for successful delivery.

Other Major Considerations


A reverse DNS record (rDNS) identifies a domain associated with an IP address. An SMTP server IP address without a rDNS record will most likely be flagged by the receiver’s anti-spam engine and connections from that SMTP server will be blocked. Thus, passing an rDNS check is must for successful mail delivery.

Setting a PTR record in DigitalOcean is pretty straightforward. You just need to change the name of the droplet to a fully qualified domain name (FQDN). Once changed, the PTR record is set using the name of the droplet.

In my case, once I changed the name of the core SMTP droplet to, the PTR record was updated within seconds.

SMTP Server IP Blacklist Check

The IP address of the SMTP server is one of the key deciding factors whether your email will be delivered or not. IP reputation is checked by the receiver and if found in any known blacklists, the email is blocked on the gateway itself and never sees the light of the user mailbox.

Once you provision a new droplet, check the public IP assigned against known blacklists. You can use MXToolbox’s blacklist check ( for this. If you find your IP address on a blacklist, you can either provision a new droplet or submit your public IP address for delisting. The following snippet shows the blacklist check for (

Validation of configuration

We have successfully configured all the parameters and we are ready to start sending emails and analyze the results. Before you do that, I will suggest that you run diagnostic checks on your domain to ensure that the overall setup is free from any caveats and you have not missed anything. One of the ways you can do this is using MXToolbox’s Domain Health Report (

It will highlight any errors associated with your domain. We are mostly interested in DNS, Mail Server, and Blacklist check results.

Pilot Run

Now that we have the setup ready, let’s send an email and check if the configuration is optimal and if the email lands in the mailbox. You can use RoundCube email client installed during the iRedMail installation. It could be found at https://<>/mail/

To test how well your email scores in terms and if at all it will be delivered in a user’s mailbox, you can use a service such as It evaluates the email headers as well as content on parameters such as IP address reputation, SPM/DKIM/DMARC check results, etc. and generates a SPAM score.

As shown below, an email was sent to Mail Tester and the email got a perfect score of 10/10.

You can also send an email to a genuine user ID, and most likely if the score is 10/10, your email will be delivered in the Inbox.

What’s next

Once the email is sent, irrespective of whether it is delivered or not, it comes under the scanner as soon as it is sent. The email will be scanned and analyzed by email gateways, endpoint solutions, blue teams, etc. Once the email is flagged, the domain as well the originating IP address will be blocked/blacklisted. The blacklist details will then be updated in the reputation lists and anyone using those reputation lists to make decisions on incoming emails will block them.

The following is the header of an email that was sent to an Office365 domain. The original email ID and domain of the recipient have been replaced with random text.

Received: from BM1PR0101MB1107.INDPRD01.PROD.OUTLOOK.COM (2603:1096:b00::24)
 BM1PR01CA0108.INDPRD01.PROD.OUTLOOK.COM; Tue, 28 Apr 2020 06:58:49 +0000
Received: from PN1PR01CA0080.INDPRD01.PROD.OUTLOOK.COM (2603:1096:c00:1::20)
 by BM1PR0101MB1107.INDPRD01.PROD.OUTLOOK.COM (2603:1096:b00:22::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Tue, 28 Apr
 2020 06:58:49 +0000
Received: from
 (2603:1096:c00:1:cafe::e1) by
 (2603:1096:c00:1::20) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend
 Transport; Tue, 28 Apr 2020 06:58:49 +0000
Authentication-Results: spf=pass (sender IP is;; dkim=pass (signature was
 verified);; dmarc=pass action=none;compauth=pass reason=100
Received-SPF: Pass ( domain of designates as permitted sender);
Received: from ( by ( with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.2937.15 via Frontend Transport; Tue, 28 Apr 2020 06:58:48 +0000
Received: from ( [])
	by (Postfix) with ESMTP id 49BCD62F1NzChZN
	for <[email protected]>; Tue, 28 Apr 2020 06:58:46 +0000 (UTC)
Authentication-Results-Original: (amavisd-new);	dkim=pass
 (1024-bit key) reason="pass (just generated, assumed good)"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h=
	:references:in-reply-to:subject:to:from:date:mime-version; s=
	dkim; t=1588057124; x=1590649125; bh=EH2Lk7nEJ4MFxjQukbUATa9TFyl
	lOFrVLWlE8cV0mlY=; b=WBoR4eqxAndlJBIACiozsEE7kJYcCa8koE0YYSz/y1I
X-Virus-Scanned: Debian amavisd-new at
Received: from ([])
	by ( []) (amavisd-new, port 10026)
	with ESMTP id N1QcZSLhMpxu for <[email protected]>;
	Tue, 28 Apr 2020 06:58:44 +0000 (UTC)
Received: from localhost ( [])
	by (Postfix) with ESMTPSA id 49BCD36fZXzChZL
	for <[email protected]>; Tue, 28 Apr 2020 06:58:43 +0000 (UTC)
MIME-Version: 1.0
Date: Tue, 28 Apr 2020 12:28:43 +0530
From: IT Support <[email protected]>
To: [email protected]
Subject: Fwd: Notification from Support team
In-Reply-To: <[email protected]>
References: <[email protected]>
 <[email protected]>
User-Agent: Roundcube Webmail
Message-ID: <[email protected]>
X-Sender: [email protected]
Content-Type: text/plain; charset=US-ASCII;
Content-Transfer-Encoding: quoted-printable
Return-Path: [email protected]
X-MS-Exchange-Organization-ExpirationStartTime: 28 Apr 2020 06:58:48.4968
X-MS-Exchange-Organization-ExpirationStartTimeReason: OriginalSubmit
X-MS-Exchange-Organization-ExpirationInterval: 1:00:00:00.0000000
X-MS-Exchange-Organization-ExpirationIntervalReason: OriginalSubmit
X-EOPAttributedMessage: 0
X-EOPTenantAttributedMessage: 5519d103-66f6-4b0d-979f-35c233b454ed:0
X-MS-Exchange-Organization-MessageDirectionality: Incoming
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: fbf9b832-4876-42c2-d480-08d7eb4199fa
X-MS-TrafficTypeDiagnostic: BM1PR0101MB1107:
X-MS-Oob-TLC-OOBClassifiers: OLM:4941;
X-MS-Exchange-Organization-SCL: 6
X-Microsoft-Antispam: BCL:0;
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Apr 2020 06:58:48.0620
X-MS-Exchange-CrossTenant-Network-Message-Id: fbf9b832-4876-42c2-d480-08d7eb4199fa
X-MS-Exchange-CrossTenant-Id: 5519d103-66f6-4b0d-979f-35c233b454ed
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BM1PR0101MB1107
X-MS-Exchange-Transport-EndToEndLatency: 00:00:01.7107612
X-MS-Exchange-Processed-By-BccFoldering: 15.20.2937.014

The header leaks the droplet’s IP address ( as well the hostname ( The next part of the series will discuss how to mask these details using a redirector.

Thanks for reading.

Be the first to comment

Leave a Reply

Your email address will not be published.


This site uses Akismet to reduce spam. Learn how your comment data is processed.