You sent a quote to a customer's Gmail address and got a bounce with "550 5.7.26" in it. That error means Gmail couldn't prove the email really came from your domain, so it refused it. The customer never saw it. The good news: it's a DNS fix, and most businesses can finish it in an afternoon.
What does the Gmail 550 5.7.26 error mean?
The Gmail 550 5.7.26 error means Gmail rejected your message because it failed email authentication. Your domain didn't pass SPF, DKIM, or DMARC, so Gmail treated the message as possibly forged. The "550" part means it's a permanent failure. Gmail won't retry it, and it doesn't land in the customer's spam folder either. Google spells this out in its email sender guidelines: "Messages that aren't authenticated with these methods might be marked as spam or rejected with a 5.7.26 error." Those rules have applied to every sender since February 1, 2024, according to the same Google page. So this isn't a glitch on the customer's end. Gmail wants your domain to prove who it is.
What does the full 5.7.26 bounce message say?
The full 5.7.26 bounce message tells you which check failed, so read the whole line before you change anything. Google's SMTP error reference lists three versions:
- "This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM." Neither record passed. Start with SPF and DKIM.
- "The (E)MAIL FROM domain ... has an SPF record with a hard fail policy (-all) but it fails to pass SPF checks with the ip: ..." You're sending from a server your SPF record doesn't list. Find that server and add it.
- "Unauthenticated email from [your domain] is not accepted due to domain's DMARC policy." This one is the sneaky one. You do have DMARC, it's set to reject, and something sending as you isn't lined up with it.
Google's sender guidelines set the bar at SPF or DKIM for everyone, and both plus DMARC for anyone sending 5,000 or more messages a day. Matching the variant to the record saves a lot of guessing.
Why is Gmail suddenly rejecting my emails?
Gmail is rejecting more email now because Google stepped up enforcement of its sender rules in late 2025. According to Spam Resource's write-up of Google's FAQ update, Google added this line in November 2025: "Messages that fail to meet the email sender requirements will experience disruptions, including temporary and permanent rejections." Before that, a lot of unauthenticated mail just slid into spam. Now more of it bounces. If your quotes or invoices went through fine last year and started bouncing recently, that change is the likely reason. Your setup probably didn't break. The bar moved. A domain getting by on a half-finished SPF record from years ago doesn't get by anymore.
Why do I get 5.7.26 when I already have a DMARC record?
You get 5.7.26 with a DMARC record in place when the record says "reject" and one of your senders isn't aligned with it. DMARC lets you tell receiving servers what to do with mail that fails. Under RFC 7489, the DMARC standard (section 6.3), p=reject means "the Domain Owner wishes for Mail Receivers to reject email that fails the DMARC mechanism check." Gmail does exactly that. The catch is that DMARC needs the From address to match the domain that passed SPF or DKIM. Google's sender guidelines say "the domain in the sender's From: header must be aligned with either the SPF domain or the DKIM domain." A CRM or invoicing app can pass its own checks and still fail yours. If it signs with its own domain instead of yours, alignment fails and Gmail rejects the message. That's how a business can do the right thing, turn on enforcement, and then watch one tool's emails start bouncing.
Which tools usually cause 5.7.26 for a small business?
The tools that usually cause 5.7.26 are the ones that send email as you from somebody else's servers. For a small shop in Battle Creek or Kalamazoo, that's a short list: your main mailbox (Google Workspace or Microsoft 365), your invoicing or accounting app, your CRM or scheduling tool, your website's contact form, and maybe a newsletter tool. Each one needs to be covered by SPF and set up to sign with DKIM for your domain. Google is direct about this: "Make sure the SPF record for your domain includes all email senders for your domain," according to its sender guidelines. Forwarding can trip it too. If a customer forwards your email from one inbox to a Gmail address, the forwarding server isn't in your SPF record. If your DKIM signature survives the trip, the message still passes. If it doesn't, the forwarded copy can bounce.
Why does my website contact form bounce with 5.7.26?
Your website contact form bounces with 5.7.26 when it sends the message "from" the visitor's own email address. Plenty of form plugins do this so you can hit reply. The problem is your web server isn't allowed to send as yahoo.com or aol.com. Both of those domains publish a DMARC policy of p=reject in public DNS. You can look up the TXT record at _dmarc.yahoo.com yourself. So say a customer fills out your form with a Yahoo address. Your server sends a message claiming to be that customer at Yahoo. Gmail checks Yahoo's policy, sees reject, and bounces it. You never see the lead. The fix is simple. Set the form to send from an address on your own domain, and put the visitor's email in the Reply-To field. Then authenticate that sender like any other tool. You can check your own domain's records in about 30 seconds with the free email security check.
How do I fix the 550 5.7.26 error step by step?
You fix the 550 5.7.26 error by making every service that sends as your domain pass SPF or DKIM, lined up with your From address. Here's the order that works, based on Google's sender guidelines, which require SPF or DKIM for all senders and DMARC above 5,000 messages a day.
- Read the bounce. Match it to one of the three variants above. It tells you whether to start with SPF, DKIM, or DMARC alignment.
- List every sender. Write down every tool that emails customers as your domain: mailbox, invoicing, CRM, website form, newsletter.
- Fix SPF. Keep one SPF record and add an include for each sender that needs it. Don't publish a second SPF record, since that breaks both.
- Turn on DKIM for each sender. Most tools have a "custom domain" or "authenticate your domain" setting that gives you a DNS record to add.
- Check alignment. Send a test from each tool to a Gmail address. Open the message, choose "Show original," and look for DMARC: PASS.
- Fix the form. Change your contact form to send from your own domain with Reply-To set to the visitor.
- Resend and watch. Resend the bounced quotes. Then read your DMARC reports for a few weeks to catch any sender you missed.
If you're on Microsoft 365, the DKIM and DMARC steps there have their own quirks. The DMARC setup guide for Microsoft 365 walks through them.
Should I turn off DMARC to stop the 5.7.26 bounces?
No, you shouldn't delete your DMARC record to stop 5.7.26 bounces. Deleting it trades a delivery problem for a bigger one. Google requires DMARC for anyone sending 5,000 or more messages a day, according to its sender guidelines, and without it anyone can send email that looks like it came from you. If a key tool is bouncing and you need mail flowing today, step the policy back to p=none for a short window. RFC 7489 describes p=none as a request that "no specific action be taken regarding delivery of messages." That keeps reports coming in while you fix alignment. Then step back up to quarantine and reject once every sender passes. Treat p=none as a few weeks, not a permanent setting.
Is 550 5.7.26 the same as Microsoft's 550 5.7.515?
No, 550 5.7.26 isn't the same error as 550 5.7.515, but the cause and the fix overlap. The 5.7.26 code comes from Gmail. The 5.7.515 code comes from Microsoft's Outlook.com, Hotmail, and Live servers. Both mean your domain didn't pass authentication. Google's rule is SPF or DKIM for every sender, plus DMARC for anyone over 5,000 messages a day, according to its sender guidelines. Microsoft's rule targets senders of 5,000 or more messages a day. If you're seeing both, fix the records once and both bounces go away. My guide to the 550 5.7.515 error covers the Microsoft side in detail.
How common is this problem for Southwest Michigan businesses?
This problem is common around here because most local domains haven't finished their email authentication. A Parallax Intelligence check of Southwest Michigan businesses found that 79.2% of 847 businesses that email from their own domain (1,527 checked) have no DMARC enforcement, according to the Southwest Michigan Email Security Report. In the same check, 390 of those 847 (46.0%) publish no DMARC record at all. That's a snapshot of public DNS records, not a claim that anyone was breached. It does mean plenty of businesses in Battle Creek, Kalamazoo, Portage, Marshall, and Albion are one Gmail rule change away from a bounce. Cleaning it up before year-end invoices and holiday promos go out is worth an afternoon.
Not sure which variant you have? Paste the bounce into the free reader on the 550 5.7.26 page at postmortem.report. It runs in your browser and names the variant. For other codes, the email rejection error codes guide lists every Microsoft and Gmail code with its own fix page.
When should you get help with a 5.7.26 bounce?
You should get help with a 5.7.26 bounce when you have more than two or three tools sending as your domain, or when the bounce keeps coming back after you've fixed SPF. That's usually an alignment problem, and it can take some digging through headers and DMARC reports. Google's sender guidelines also ask senders to keep their spam complaint rate low, so a messy setup can hurt even after the bounces stop. If you run a business in Battle Creek, Kalamazoo, or anywhere in Southwest Michigan and you'd rather have this handled, the Parallax DMARC audit service covers it: I find every tool that sends as you, set up SPF, DKIM, and DMARC across them, and roll protection out step by step so nothing breaks. Call (269) 460-1772 or use the contact form, and tell me what the bounce says.