DEV Community: Dev May Cry

Why Gmail blocks your email: a short lesson on sender rules

Dev May Cry — Thu, 05 Nov 2026 17:21:32 +0000

Why does Gmail block an email? A short lesson on the Gmail and Yahoo sender rules.

Think of a building with a gatekeeper. Before someone enters, the gatekeeper checks who they are. Gmail and Yahoo do the same with every email.

Let's follow Lia. She wants to send a sale email from loja.com to 10,000 people on Gmail.

Is she a bulk sender? A bulk sender sends email in large volume. On Gmail, this means about 5,000 emails a day to personal accounts. Gmail counts the domain and its subdomains together: 3,000 from mercado.com + 2,500 from promo.mercado.com. If you reach it once, the status does not expire.

All senders need SPF or DKIM, TLS, PTR, and a spam rate below 0.3%. Bulk senders have extra rules.

Rule 1: show your ID
SPF is the list of servers that can send for a domain. DKIM is the email signature. DMARC is the rule that checks both. Bulk senders need SPF, DKIM, and DMARC. The minimum policy is p=none, which only observes.
Rule 2: the names must match
This is alignment. The From domain, which people see, must match the SPF or DKIM domain. Only one of them must match.
From: loja.com + dkim=pass (envios.com) = it passed, but it is not aligned.
If SPF is for loja.com, alignment is correct.
Rule 3: use a safe entrance
TLS encrypts the connection, like a sealed bag. PTR is reverse DNS: it links the sending IP to a name. Both rules are for all senders.
Rule 4: don't annoy the residents
Gmail asks for less than 0.1% spam, and it must never reach 0.3%. In 10,000 emails, 10 complaints are 0.1% and 30 are 0.3%. At 0.2% you are still under the limit, but it is time to review your list.
Rule 5: offer an easy exit
Bulk marketing email needs one-click unsubscribe, with the List-Unsubscribe and List-Unsubscribe-Post headers, plus a visible link. A link only in the email body is not enough. Transactional email, like a password reset, does not need one-click.
What does the error say?
Gmail can reply with 421 4.7.x, a temporary limit. Examples:
421 4.7.30: DKIM did not pass.
421 4.7.29: TLS is missing.
421 4.7.32: From is not aligned.
Retrying without a fix will not help.
Are Gmail and Yahoo the same?
The logic is the same, but some details change. Gmail requires an HTTPS URL for unsubscribe and asks you to honor requests in 48 hours. Yahoo accepts mailto, recommends POST, asks for 2 days, and does not publish a number for bulk senders.

Now be the gatekeeper and test what you learned:
https://thallesaguiar.github.io/email-gatekeeper/en/

email #backend #smtp #programming

How to warm up an IP: a step-by-step lesson

Dev May Cry — Wed, 04 Nov 2026 17:07:43 +0000

The problem

Ana opened a store with a new domain and a new IP (the address of the sending server). She wants to send 50,000 emails today.

Here is what happens:

The IP is new and has no history.
The volume is high all at once.
Gmail and Outlook get suspicious.
Delivery is limited or blocked.

Let's see how Ana avoids this.

Step 1: Understand reputation

A provider is who receives the email, like Gmail or Outlook. Providers give each sender a score, called reputation. Three things count: volume, bounces (returned emails) and spam.

Step 2: Know the two reputations

Which one counts, domain or IP? Both. Domain reputation follows your brand. IP reputation stays with the server address. Ana starts from zero on both.

Step 3: Choose your IP

On a shared IP, you split it with other customers, so you risk noisy neighbors. A dedicated IP is only yours, but it needs constant volume and a warmup. Ana chose dedicated.

Step 4: Warm up in steps

Warmup means sending more in steps to avoid spikes that scare providers. Think of a new credit card:

Credit card	IP
New card, low limit	New IP, sends little
Good history, limit goes up	Good history, volume goes up

Example from the Resend guide for a new domain:

Day	Emails
1	150
3	400
5	1,000
7	2,000

Step 5: Start with active contacts

Ana first emails the people who open the most. That keeps complaints low as volume grows. The rest come later.

How long does it take? For a dedicated IP, AWS says 2 to 6 weeks.

Warm up again when you change domain, IP or provider, or when volume grows a lot.

Step 6: Watch your numbers

Resend's guide uses these references:

Bounces: below 4%
Spam: below 0.08%

If they rise, follow this order:

Brake: slow down.
Investigate: find the cause.
Resume: continue only after you fix it.

The result

Without warmup	With warmup
Volume spike	Volume in steps
Providers distrust you	No scary spike
May get limited or blocked	Problems show early, and you can fix them

In the end, Ana reaches 50,000 emails in steps, with no spike.

Try it yourself

Calculate the bounce rate of your last send:

bounce% = bounced / sent * 100

Example: 30 bounced out of 1,000 sent is 3%, which is below the 4% reference.

Checklist:

[ ] Did I raise volume slowly?
[ ] Did I start with the people who open the most?
[ ] Do I track bounces and spam?

Test what you learned: https://thallesaguiar.github.io/ip-warmup-quiz/en/

Sources: Resend Warm-up Guide and AWS SES documentation

Hard vs Soft Bounce: when to retry an email and when to stop

Dev May Cry — Tue, 03 Nov 2026 17:20:05 +0000

Your app sent 3 emails. All 3 came back. Should you send them again?

It depends on why they came back. A bounce means the receiving server refused the email, but not every refusal is the same.

Soft bounce: not now
The refusal is temporary. The mailbox may be full, or the email may be too large. It can still be delivered later, so you can try again after the cause goes away.

Deferral: still trying
The MTA (Mail Transfer Agent, the server that delivers your email) received a 4xx reply and keeps trying. If it works, the email is delivered. If the MTA gives up, it becomes a bounce.

Hard bounce: stop
The refusal is permanent. A reply like 550 5.1.1 means the mailbox does not exist. Sending again will not fix it and can hurt your reputation.

What to do in your app

Add hard bounces and spam complaints to a suppression list, a list of addresses your system skips before sending.
Listen to webhooks so your app knows what happened. Without them, it never learns that the email came back.
Watch your bounce rate. The Resend guide suggests keeping it below 4%.

Not every bounce deserves a second try. Does your app handle bounces today?

Source: Resend Docs, Email Bounces

SMTP Codes: What the Mail Server Is Telling You

Dev May Cry — Mon, 02 Nov 2026 17:25:10 +0000

Every SMTP command gets a reply with 3 digits. Your MTA (Mail Transfer Agent) reads that code to decide what to do next. The first digit tells you almost everything:

2xx: success. Move to the next step.
3xx: accepted, but something is missing. After DATA, a 354 means "send the message body".
4xx: temporary failure. Keep the email in the queue and try again later.
5xx: permanent failure. Do not repeat the same request.

The classic confusion is 3xx vs 4xx. A 3xx means the conversation is moving forward. A 4xx means "not now".

Many servers also send an extended code, like 550 5.1.1:

5: permanent failure
.1: address problem
.1: the mailbox does not exist

One more detail: a 250 does not prove the email reached the inbox. It means the server accepted the message. It can still land in spam.

Which SMTP code has given you the most trouble?

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