Gmail Message Blocked? How to Fix Error 550-5.7.26 on a Custom Domain

You hit send on an important email from your own domain, and seconds later a bounce lands in your inbox. It says your message was blocked and shows the code 550-5.7.26. It looks technical and scary, but the cause is simple: Gmail does not trust that your domain really sent that email.

This guide explains what the error means, why Gmail blocks unauthenticated mail, and how to fix it step by step with SPF, DKIM, and DMARC records. You only need access to your domain’s DNS settings.

Quick Answer

The 550-5.7.26 error means Gmail blocked your message because your custom domain failed authentication checks for SPF, DKIM, or DMARC. To fix it, publish a correct SPF record, turn on DKIM signing in your email provider, and add a DMARC record for your domain. Once those three records are live and verified, Gmail will normally accept your mail again within a few hours.

What Does Error 550-5.7.26 Actually Mean?

Gmail checks every incoming message to see if the sender is real. Spammers often fake famous domain names, so Gmail asks a simple question: did the owner of this domain allow this server to send mail?

Three systems answer that question. SPF lists the servers allowed to send for your domain. DKIM adds a digital signature to prove the message was not changed. DMARC tells receivers what to do when the first two checks fail.

If none of those systems pass, Gmail treats the message as suspicious. Instead of delivering it to the spam folder, Gmail may reject it completely and return the 550-5.7.26 response to your mail server.

Common Reasons This Error Appears

• Your domain has no SPF record at all.
• Your SPF record exists but does not include your current email provider.
• DKIM signing is turned off in Google Workspace or your hosting panel.
• Your DMARC record is set to reject, but SPF and DKIM are not aligned with your domain.
• You recently moved hosts, changed providers, or started using a new marketing tool that sends as your domain.
• A forwarded message breaks the original SPF or DKIM checks on the way to Gmail.

Before You Start: Gather What You Need

A little preparation makes the fix much faster. You will be editing DNS records, and a small typo there can break your website email completely if you rush.

1. Sign in to the place where your domain DNS is managed, such as your registrar or hosting control panel.
2. Sign in to your email admin console, for example Google Workspace Admin or your host’s email panel.
3. Keep the full bounce message open, because it often names the exact domain and IP address that failed.
4. Note every service that sends mail as your domain, including your website contact form, invoices, and newsletters.

That last point matters a lot. If you forget a legitimate sender, your new records may block that sender instead.

Step 1: Check and Fix Your SPF Record

SPF is a single TXT record in your DNS. It works like an approved sender list that other mail servers can read in public.

How to Check Your Current SPF Record

1. Open a free DNS lookup tool and search for TXT records for your root domain.
2. Look for a record that starts with v=spf1.
3. Check whether it includes your provider, for example include:_spf.google.com for Google Workspace.
4. Confirm there is only one SPF record, because two separate v=spf1 records will both fail.

How to Create or Correct the Record

1. In your DNS panel, add or edit one TXT record for the root domain, often shown as @.
2. For Google Workspace only, use v=spf1 include:_spf.google.com ~all as a starting point.
3. If other services send for you, add each one as its own include, based on that service’s own instructions.
4. Keep the total number of DNS lookups under ten, which is the strict SPF limit.
5. Save the record and wait for DNS to update, which can take from a few minutes to a few hours.

If you need a wider walkthrough first, follow this complete guide to setting up SPF, DKIM and DMARC records for a custom domain before you change live records.

Step 2: Turn On DKIM Signing

SPF checks the sending server. DKIM checks the message itself by adding a private signature that receivers can verify with a public key in your DNS.

Without DKIM, a message can pass SPF through a shared provider but still look weak to Gmail. With DKIM aligned to your own domain, your trust score improves a lot.

Enabling DKIM in Google Workspace

1. Go to the Admin console and open Apps, then Google Workspace, then Gmail.
2. Open Authenticate email and select your domain from the list.
3. Generate a new DKIM record and copy the host name and TXT value it gives you.
4. Add that TXT record in your DNS panel exactly as shown, without extra spaces.
5. Return to the Admin console and choose Start authentication, then wait for the status to show as authenticating.

If you use a different provider, the clicks will differ, but the idea is the same. The provider creates the key, you publish the public part in DNS, and then you switch signing on.

Google explains these sender requirements in its official email sender guidelines for Gmail, which are worth reading if you send in bulk.

Step 3: Add a DMARC Record

DMARC ties SPF and DKIM together. It also tells Gmail what to do when a fake message pretends to be you.

Start gently. A monitoring policy lets you collect reports without risking your real mail on day one.

1. Add a TXT record with the host name _dmarc in your DNS panel.
2. Start with a value like v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com, using your own reporting address.
3. Wait several days and read the reports to confirm all your real senders pass.
4. Move to p=quarantine once you are confident, and later to p=reject for the strongest protection.
5. Check that your SPF and DKIM use your root domain, because DMARC needs that alignment to pass.

Many people skip DMARC because SPF and DKIM already work. That is a mistake in 2026, because Gmail and other large providers now expect DMARC for regular and bulk senders.

Step 4: Test Your Fix Properly

Do not assume the fix worked just because you saved the records. Test like a receiver would test you.

1. Send a fresh email from your custom domain to a personal Gmail address you control.
2. Open the message in Gmail, use the three-dot menu, and choose Show original.
3. Check that SPF, DKIM, and DMARC all show PASS with your own domain name.
4. Send again from any other tool that uses your domain, such as your website form, and repeat the test.
5. Wait and retry after a few hours if DNS still shows as propagating in lookup tools.

If one check still fails, the Show original page usually hints at why. A DKIM fail often means the DNS record was pasted wrong. An SPF fail often means a sender was left off the list.

What If the Error Still Comes Back?

Sometimes the records are correct but Gmail still blocks some mail. In that case, look at the wider sending picture.

Other Causes to Investigate

• Your server IP has a poor reputation because of spam sent by others on a shared host.
• Your messages look like bulk mail but you have no List-Unsubscribe header.
• Recipients marked earlier messages as spam, raising your domain’s complaint rate.
• Your website was hacked and really did send spam without you knowing.
• Your SPF record has grown too complex and passes the ten lookup limit.

Google’s troubleshooting guide for bounced Google Workspace emails helps you read bounce codes and find which side caused the problem.

If your domain was abused, clean it first. Fixing records on a compromised site will not restore trust until the spam source is gone.

Common Mistakes to Avoid

• Publishing two SPF records: Merge everything into one record instead of adding a second one.
• Copying DKIM keys with line breaks: Extra spaces or missing characters will make signing fail silently.
• Jumping straight to p=reject: A strict DMARC policy before testing can block your own invoices and forms.
• Forgetting third-party senders: Billing apps, help desks, and newsletter tools must be in SPF and have their own DKIM.
• Testing too early: DNS changes are not instant worldwide, so a test five minutes later may show old data.
• Using -all too soon: A hard fail SPF ending can cause more rejects if a sender is missing.

Conclusion

The Gmail 550-5.7.26 blocked message error is frustrating, but it is also fixable. Gmail is simply asking your domain to prove who it is, and SPF, DKIM, and DMARC are that proof.

Publish one clean SPF record, switch on DKIM signing, add DMARC in monitoring mode first, and then test with Show original until all three checks pass. Give DNS time to spread, keep a list of every sender that uses your domain, and your mail should reach Gmail inboxes reliably again.

Frequently Asked Questions

How long does the fix take to work?

Most DNS changes start working within one to four hours, although full global propagation can take up to 48 hours. Test again after a few hours before changing records a second time.

Can I fix 550-5.7.26 without access to DNS?

No, not properly. SPF, DKIM, and DMARC all live in DNS, so you or your domain administrator must be able to edit those records to solve the root cause.

Does this error mean my domain is blacklisted?

Not usually. This specific code is about authentication, not a blacklist. A blacklist problem normally produces a different bounce message that mentions reputation or a blocked IP address.

Do I need DMARC if SPF and DKIM already pass?

Yes, you should still add it. DMARC protects your domain from spoofing, gives you useful reports, and is now expected by Gmail for many senders.

Why do only Gmail recipients bounce, not everyone?

Gmail enforces authentication more strictly than many smaller providers. Other receivers may accept the same message or place it in spam, while Gmail chooses to reject it outright.