DEV Community: Dev May Cry

Anyone can write “From: bank.com” in an email. Here’s how Gmail catches the fake.

Dev May Cry — Fri, 30 Oct 2026 16:15:47 +0000

TL;DR: SMTP was born in 1982 with no sender check. Today Gmail runs 3 checks before an email reaches your inbox: SPF, DKIM and DMARC. SPF and DKIM alone are not enough. DMARC is what stops the scam.

Let's follow one fake email from "bank.com" to João, step by step.

1. Every email has two senders

Think of a real letter. The envelope is what the mail carrier reads. The letter inside has the "From:" that you read. Email works the same way:

MAIL FROM: (the envelope) is only read by servers
From: (the letter) is what you see in your inbox

A scammer can put a different name in each one.

2. SPF (Sender Policy Framework): who is allowed to send?

It's a list in DNS with the servers that can send email for a domain.

$ dig TXT bank.com
v=spf1 include:amazonses.com -all

The scammer's server is not on the list, so SPF fails. Note: SPF only checks the envelope.

3. DKIM (DomainKeys Identified Mail): was the email signed?

The sending server signs the email with a private key. Gmail gets the public key from DNS and checks the signature. If anyone changes the text, the signature breaks. The d= tag shows who signed it.

4. The trick: the scammer uses his own domain

MAIL FROM:<x@scam.com>   spf=pass  (scam.com)
DKIM d=scam.com          dkim=pass (scam.com)
From: support@bank.com   <- João sees this

Both checks pass, but for the wrong domain.

5. DMARC: do the names match?

DMARC = Domain-based Message Authentication, Reporting and Conformance.

It asks whether the domain in From: is the same domain that passed SPF or DKIM. This is called alignment. Here scam.com ≠ bank.com, so DMARC fails.

6. The domain owner decides what happens

_dmarc.bank.com  TXT  "v=DMARC1; p=reject"

p=none → only watch
p=quarantine → send to spam
p=reject → refuse the email

The bank also gets reports about who is trying to use its name.

Without DMARC

Gmail has no rule to apply, and the fake email can land in João's inbox. That's why Gmail and Yahoo have required DMARC since 2024 for anyone who sends more than 5,000 emails per day.

Test your domain

dig TXT _dmarc.yourdomain.com

Sources: RFC 7208 (SPF), RFC 6376 (DKIM), RFC 7489 (DMARC)

Does your domain already have DMARC?

send() returned true. The email never arrived. Following one email from your app to the inbox

Dev May Cry — Thu, 29 Oct 2026 17:09:47 +0000

Most apps treat send() === true as “delivered”. It isn’t. It only means your email provider accepted the message. The real trip starts after that, and that’s where most failures happen.

I followed one email through the whole route: a sign-up confirmation with a typo in the address.

The route

Stop 1 · App → provider (port 587): your app logs in, starts TLS and submits the message. send() returns true here.
Stop 2 · DNS: the provider’s MTA looks up the MX record of gmail.com to find which server receives mail for that domain.
Stop 3 · The SMTP conversation (port 25): EHLO, MAIL FROM, RCPT TO, DATA. The envelope decides delivery, not the To: header you see.
Stop 4 · The response code: 2xx accepted · 4xx temporary (defer and retry with backoff) · 5xx permanent (bounce, don’t retry).

What happened to our email
RCPT TO:joao.silvaa@gmail.com → 550 5.1.1 user unknown.
The provider records a bounce and suppresses the address. Your app still thinks everything worked, unless it listens to bounce notifications (webhooks, SNS, etc.).

Takeaways

“Accepted” and “delivered” are different states. Store them separately.
Keep delivery events per message: delivered, deferred, bounced.
Never retry a 5xx. Retry a 4xx with backoff. RFC 5321 suggests at least 30 minutes between retries and giving up after 4–5 days.

Dual write: the bug hiding between your database and your message broker

Dev May Cry — Thu, 29 Oct 2026 12:01:51 +0000

You save an order to the database and then publish an order.created event. Two lines of code. What could go wrong?

DB::transaction(function () use ($order) {
    $order->save();
});

Kafka::publish('order.created', $order); // what if this fails?

This is a dual write: one operation writing to two different systems (database + broker, database + cache, database + search index) with no transaction covering both.

Why it breaks:

Partial failure: the order is committed, but the publish fails (network blip, broker down, process killed mid-request). The order exists, and no downstream service ever hears about it.
Swapping the order doesn't help: publish first and you can end up with an event for an order that was never saved.
Race conditions: two concurrent requests can write in a different order to each system, leaving them out of sync.

It even hides in familiar patterns. Dispatching a queued job with afterCommit() in Laravel is still a dual write: if the process dies between the commit and the push to Redis, the job is gone.

The fix: Transactional Outbox

Write the event to an outbox table inside the same database transaction:

DB::transaction(function () use ($order) {
    $order->save();

    OutboxMessage::create([
        'topic'   => 'order.created',
        'payload' => $order->toJson(),
    ]);
});

A separate worker reads pending outbox rows, publishes them, and marks them as sent. Now it's atomic: either both the order and the event are saved, or neither is.

One catch: the relay can publish a message and crash before marking it as sent, so delivery is at-least-once. Your consumers need to be idempotent.

Other options:

Change Data Capture (CDC): tools like Debezium read the database's transaction log and turn changes into events. The database stays the single source of truth.
Event sourcing: the event log is the source of truth, and everything else is a projection.
Two-phase commit: works in theory, but it's heavy, couples your services, and most brokers don't support it.

Ever been bitten by a dual write in production? How did you handle it?

Game build with REA

Dev May Cry — Mon, 26 Oct 2026 19:28:49 +0000

An idea I had, my favorite game of all time, and my desire to learn by doing. I used REA to turn this combination into From the Cross to Glory, a pixel art experience inspired by Castlevania: Symphony of the Night. The idea was to use the game mechanics to tell a story: Jesus arrives wounded, with limited movements. After receiving the Father’s message, He takes His glorified form to face Death. It was a great opportunity to learn about sprite adaptation, programming, dialogue, visual effects, and how to create a playable version directly in the browser.

🎮 Play here: https://thalles-aguiar.itch.io/da-cruz-a-gloria

The game lasts 5 minutes.

Fan project developed for learning purposes only, with no commercial goals. Credit goes to Konami for Castlevania: Symphony of the Night and the original characters, graphics, music, and other elements used. This is an unofficial project and is not connected to Konami.

REA #GameDev #DesenvolvimentoDeJogos #PixelArt #AprendizadoNaPrática