Gmail “550 5.7.26 This mail has been blocked”: the 30-minute fix

Your bounce queue just filled up with 550 5.7.26 errors and every Gmail user who was supposed to receive your message didn’t get it. This is not a temporary deferral — Google rejected the messages permanently, and resending won’t help until you fix the underlying authentication problem.

Here’s what happened and how to fix it in the next 30 minutes.

What the error means

550 5.7.26 means Google’s servers refused your email because your sending domain failed Google’s bulk sender authentication requirements.

Google introduced these requirements in February 2024 for senders delivering 5,000 or more messages per day to personal Gmail addresses (gmail.com, googlemail.com). Initially, non-compliant senders received temporary 421 deferrals — a warning that would eventually resolve. In November 2025, Google upgraded that to permanent 550 hard rejections. If you’re seeing this now, you’re in the hard enforcement phase: messages are being dropped, not delayed.

The requirements Google enforces:

  1. SPF must pass — your sending IP must be authorized by your domain’s SPF record
  2. DKIM must pass — the message must carry a valid DKIM signature
  3. A DMARC record must exist — at minimum p=none; the record just needs to be there
  4. DMARC alignment must pass — either SPF or DKIM must align to the domain in the From: header
  5. One-click unsubscribe — required for promotional/marketing mail
  6. Spam complaint rate below 0.3% — monitored via Google Postmaster Tools

The most common causes of 550 5.7.26 are a missing DMARC record, DKIM not configured, or an alignment failure. Let’s check yours.

The 30-minute triage checklist

1. Check your DMARC record (2 minutes)

dig TXT _dmarc.yourdomain.com +short

Expected output — something like:

"v=DMARC1; p=none; rua=mailto:reports@yourdomain.com"

If you get nothing back, your DMARC record is missing entirely. That alone triggers 550 5.7.26. Add one before doing anything else.

2. Check your SPF record (3 minutes)

dig TXT yourdomain.com +short | grep "v=spf1"

You should see a record that includes your sending service — something like include:sendgrid.net or include:amazonses.com. If the record is missing or doesn’t include your email provider, SPF is failing.

If you use several sending services, confirm the record has fewer than 10 DNS lookup mechanisms. SPF fails permanently (a permerror) above that limit. If you’re near the edge, this post explains what happens when you add one tool too many.

3. Find your DKIM selector and verify the key (5 minutes)

DKIM requires knowing your selector. The fastest way to find it: send a test email to a Gmail address you control, open the message, and choose “Show original” from the three-dot menu. Look for the DKIM-Signature: header — the s= field is your selector.

Then verify the key exists in DNS:

dig TXT <selector>._domainkey.yourdomain.com +short

If you get "v=DKIM1; k=rsa; p=..." back, the key is published. If you get nothing, DKIM isn’t configured at DNS level — either the key was never published, or you’re using a sending service’s shared domain instead of your own.

4. Check alignment (5 minutes)

Alignment means the domain in your DKIM d= tag (or the domain in your SPF Return-Path) matches your From: domain.

For DKIM alignment: the d= value in your DKIM-Signature header must match your From: domain (or a parent domain for relaxed alignment).

For SPF alignment: the Return-Path domain must match your From: domain.

You only need one of the two to align. Most transactional email providers configure DKIM alignment by default when you set up a custom sending domain. Marketing platforms sometimes don’t — especially if you’re using their shared sending domain rather than your own.

5. Check unsubscribe headers (marketing mail only)

If you’re sending bulk promotional messages, Google requires a List-Unsubscribe-Post: List-Unsubscribe=One-Click header. Check your email platform’s documentation. All major ESPs support one-click unsubscribe; it sometimes needs to be enabled explicitly in settings.

Not sure what state your domain is in right now? The free domain checker shows your DMARC record, SPF setup, and whether your domain can achieve alignment — no account needed.

Fixes by cause

Missing DMARC record:

Add a TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:your-rua-address@yourdomain.com

Start with p=none — it satisfies Google’s minimum requirement and starts collecting reports. Once SPF and DKIM are clean and you’ve read a few weeks of reports, you can move toward enforcement. The full transition process is in moving from DMARC p=none to p=reject without killing legitimate email.

SPF failing:

Add your email provider’s SPF include to your domain’s TXT record at the root:

# Postmark
include:spf.mtasv.net

# SendGrid
include:sendgrid.net

# Amazon SES
include:amazonses.com

# Google Workspace
include:_spf.google.com

# Resend
include:_spf.resend.com

DKIM not configured:

Log into your email provider and follow their DKIM setup guide. Every major provider (Postmark, SendGrid, Amazon SES, Mailchimp, Resend, Google Workspace) has a configuration page that generates a CNAME or TXT record for you to publish in DNS. Setup takes 5–10 minutes; DNS propagation takes another few minutes to an hour.

Alignment failing:

If you’re using a transactional email provider on their default shared sending domain, switch to custom domain sending. Sending From: you@yourdomain.com while the DKIM signature says d=sendgrid.net fails alignment. Most providers let you configure your own domain for signing — it’s a one-time setup and usually documented as “custom domain authentication” or “domain authentication.”

How to verify it worked

After making DNS changes:

  1. Send a test email to a personal Gmail address and open “Show original.” Look for Authentication-Results: in the headers — you want to see dkim=pass, spf=pass, and dmarc=pass.
  2. Check Google Postmaster Tools for your domain — it shows DKIM and SPF pass rates at volume.
  3. Wait 24–48 hours for DMARC aggregate reports. They show per-sender authentication results for every message in your sending window. A clean report — all legitimate senders passing — means the fix held.

One thing to watch going forward

Google’s sender guidelines FAQ states: “it’s likely that DMARC alignment with both SPF and DKIM will eventually be a sender requirement.” If you’re currently passing on only one of the two, configure the other before it becomes mandatory. DKIM is the more robust choice: it survives email forwarding. SPF breaks whenever a message passes through a forwarding server, because the forwarded copy arrives from an unauthorized IP.

The next authentication failure won’t send you a warning — it’ll send your customers a bounce. DMARC Guardian reads your aggregate reports as they arrive and flags which sender broke alignment, so you fix it before users notice their password reset never came.