CoadyTech
Posts Categories Projects About
CoadyTech

SPFcheck.io

1. About

SPFcheck.io is a tool designed to help fellow techs set up, troubleshoot, and support secure email platforms by validating SPF records.

Domain names entered into this site are sent to the AWS cloud, where a Lambda function performs a DNS lookup against Route 53.

Screenshot of spfcheck.io

2. Architecture

The project is built using the AWS Amplify service and consists of the following components:

  • API Gateway: Presents a serverless REST API to the world.
  • AWS Lambda: Performs SPF record checks on-demand. The function is coded with Node.js.
  • AWS S3: Hosts the HTML, CSS, and JS files.

Here’s a high-level overview diagram of the architecture:

Diagram of spfcheck.io server architecture

When a user submits an SPF record check request on spfcheck.io, the client-side web browser sends an HTTP POST request to the API Gateway REST API. This request contains the domain name to be checked in JSON format.

An example of the HTTP POST request might look like this:

1

{"domain":"example.com"}

API Gateway then processes this request and triggers the corresponding AWS Lambda function by invoking it with an event object in JSON format. The Lambda function receives this event object, which contains the domain name and other necessary data to perform a DNS lookup against Route 53.

An example of the JSON event object passed to the Lambda function might look like this:

1
2
3
4
5

{
  "domain": "example.com",
  "request_id": "1234-abcd-5678-efgh",
  "timestamp": "2023-04-02T10:30:00Z"
}

After processing the request and validating the SPF record, the Lambda function returns the results, which are then sent back to the client-side web browser through API Gateway as an HTTP response.

An example HTTP response might look like this:

1
2
3
4
5

{
    "spfEnabled": true,
    "spfOutput": "v=spf1 include:_spf.example.com ~all",
    "domain": "example.com"
}

In the sections below I will delve deeper into the backend services powering the site and my rationale for using them.

2.1 API Gateway

API Gateway provides several benefits for SPFcheck.io:

  • Scalability: API Gateway automatically scales with the number of incoming requests, ensuring that the service can handle varying loads without manual intervention.
  • No patching required: As a managed service, AWS takes care of all maintenance tasks, including security patches and updates, reducing operational overhead.
  • Direct interface to Lambda: API Gateway seamlessly integrates with AWS Lambda, enabling the efficient triggering of Lambda functions in response to API requests.

2.2 AWS Lambda

AWS Lambda offers several advantages for SPFcheck.io:

  • Elasticity: Lambda functions can quickly scale up and down based on demand, allowing the service to handle fluctuating workloads efficiently.
  • No patching required: Similar to API Gateway, AWS Lambda is a managed service that eliminates the need for manual patching and maintenance.
  • Event-driven architecture: Lambda functions are triggered by events, such as incoming API requests, which allows the service to consume resources only when needed, resulting in cost efficiency.

2.3 AWS S3

I chose AWS S3 to host the websites various static HTML, CSS, and JavaScript files due to its serverless nature, scalability, and high availability. As a serverless solution, S3 does away with the need for a web server to be running 24/7, along with the necrssary patching and monitoring that a server would need.

2.4 Other design considerations

One consideration was to use AWS SQS (Simple Queue Service) to decouple the architecture and provide better fault-tolerance. I decided against this for the following reasons:

  • Latency sensitivity: SPFcheck.io is designed to provide fast responses to user requests. Introducing SQS between API Gateway and Lambda would increase latency, impacting user experience.
  • Additional complexity: Using AWS SQS behind API Gateway would necessitate the development of a client-side mechanism to poll for updates, adding complexity to the client-side implementation.

3. More Info

4. Contributing

I welcome contributions to the project. If you’re interested, please check out the GitHub repo for more information on how to get started. Thanks!

Comments