Unspam Your AWS Service: Conquer Pristine Inbox Delivery

Problem

Was Completely frustated with emails landing in spam...
How? So I was meticulously setting up AWS SES to send emails from my movie booking application hosted on ECS and routed through Route53 domain, but rather reaching the eager customers, mails were getting unceremoniously dumped into spam folders.

But you relax, because I have figured out cause & effective solution. Just follow along !!!

Cause

So culprit here is email spoofing.
Have you ever opened an email claiming to be from a bank, only to find a suspicious offer or a phishing link? This could be the work of email spoofing, a deceptive technique where bad actors impersonate legitimate senders to deceive recipients.

Think of it like this: imagine someone forging your signature on a letter and sending it out under your name. Spoofing does the same thing in the digital world, manipulating email headers to make it appear as if the message originates from someone else.

Motto of email spoofing includes phishing, spamming and fraud etc. Thankfully, email servers and services today employ various authentication protocols to unmask spoofing attempts. These protocols act like digital gatekeepers, verifying the sender's identity before letting the email pass through.

Catching our problem here, that we too need to prove these gatekeepers the authenticity of our service.

Solution

Building a Fortress of Trust: The SPF, DKIM, and DMARC Trifecta

In the bustling world of email, trust is a precious commodity. To ensure that only legitimate emails reach their intended inboxes, a trio of authentication protocols stands guard: SPF, DKIM, and DMARC.

Here's how they work in coordination to create a dependable verification system:

1. SPF (Sender Policy Framework):

The Gatekeeper: SPF establishes a clear list of authorized mail servers for a domain.
Think of it as a VIP guest list: Only those with their names on it (i.e., approved IP addresses) can send emails on behalf of the domain.
How it works: Receiving servers check incoming emails against the SPF record in the domain's DNS. If the sender's IP doesn't match, the email may be flagged as suspicious.

2. DKIM (DomainKeys Identified Mail):

The Seal of Authenticity: DKIM adds a digital signature to emails, guaranteeing their integrity and sender verification.
Imagine a tamper-proof seal: It ensures the email hasn't been altered in transit and originates from the rightful sender.
How it works: The signature is generated using a private key known only to the domain owner. Receiving servers use the corresponding public key to verify the signature's authenticity.

3. DMARC (Domain-based Message Authentication, Reporting & Conformance):

The Orchestrator: DMARC builds upon SPF and DKIM, providing policy enforcement and reporting capabilities.
Think of it as a watchful manager: It instructs receiving servers on what actions to take when emails fail authentication checks.
How it works: Domain owners set DMARC policies to specify how to handle unauthenticated emails (e.g., quarantine or reject). They also receive reports on authentication results, aiding in identifying and addressing potential spoofing attempts.

Now as we know, lets implement above mechanism !!!

Implementation

Lets do it then, follow me:

SPF

Create a record set in the sender domain, as follows:
Value

"v={spf version} {mechanisms}{directive} {qualifier}all"

Type
TXT

So for me, all mails from SES are authorized to get soft pass(all servers except SES, will be considered as spam).

include:amazonses.com ensures authorizing SES
~all instructs soft pass

Done TADA... Lets go to, DKIM signatures.

DKIM

Follow along please:

1. Go to verified identities in SES

2. Get your domain verified

3. Enabling DKIM signature on domain, you will get public keys

4. Create the generated record sets in Route 53

Now, there will be in total 5 records to add,
3 will be having public key matching for reciever to read,
publicKey1._domainkey.yourhosteddomain
publicKey2._domainkey.yourhosteddomain
publicKey3._domainkey.yourhosteddomain

2 record sets for configuring MAIL FROM,
Value:subdomain.yourhosteddomain Type:MX
Value:subdomain.yourhosteddomain Type:TXT

Done! Done! Done! Be ready for last & least DMARC

DMARC

Set up a DMARC record set, with
Type: TXT
Value:

"v:DMARC1;p=reject;pct=100;rua=mailto:[e-mail]:fo=1;adkim=s;aspf=s;"

That's it! Now your domain is fully authorized to act as email sender...