One number, three different problems
Say a nine-person design studio sends proposals from its own domain. On a Monday morning nothing reaches the clients who use Gmail, and the office manager forwards a returned message with 550 in it. That number on its own tells you very little. It means Gmail refused the message permanently and will not try again. The useful part is the enhanced status code that follows it, and the sentence attached to that code.
Three of those codes account for almost every Gmail rejection we get called about. 5.7.1 is a reputation verdict. 5.7.26 is an authentication verdict. 5.7.25 is a verdict about the machine that opened the connection, not about your domain. In a mail client they look like the same red box, and they lead to completely different work. So the first thing we do on any of these tickets is read the bounce properly, before anyone opens the DNS panel.
Read the bounce: the three lines that matter
Ask for the whole returned message, not a screenshot of the first line. In Gmail the full text sits behind the error details link on the bounce, or in Show original. In Outlook it is inside the delivery report. Three things decide everything that follows.
- The enhanced status code. The digits right after
550:5.7.1,5.7.26or5.7.25. Gmail wraps long explanations, so you will usually see the code repeated at the start of every line as550-5.7.26. The hyphen means the line continues, not that the code is different. - The sentence Gmail attached to it. Two rejections can share a code and still need different repairs. That is exactly the case with 5.7.26. Copy the sentence out word for word before anyone paraphrases it.
- What the sentence names. A domain, an IP address, or both. "The sending domain" and "the sending IP address" point at different owners, and often at different companies.
A 5.7.26 bounce of the first kind reads close to this:
550-5.7.26 This mail is unauthenticated, which poses a security risk to
550-5.7.26 the sender and Gmail users, and has been blocked. The sender
550-5.7.26 must authenticate with at least one of SPF or DKIM.A 5.7.1 reads close to this instead:
550-5.7.1 Gmail has detected that this message is likely suspicious
550-5.7.1 due to the very low reputation of the sending domain.Same three digits at the front, two unrelated projects behind them.
5.7.1 is reputation, 5.7.26 is authentication, 5.7.25 is the sending host
5.7.26, authentication. Gmail could not tie the message to the domain in the visible From address. Either nothing passed, or something passed under a different domain than the one your recipients see. This is a configuration and DNS problem, and it is the fastest of the three to close.5.7.1, reputation. Gmail did evaluate the message and did not like the sender's history. Read the wording carefully. "Very low reputation of the sending domain" is about your domain. "Very low reputation of the sending IP address" is about the machine or the shared pool you send through, which on cheap hosting is shared with strangers. Neither is fixed by editing a record.5.7.25, the sending host's DNS. The public IP that connected has no usable reverse DNS. Google's sender guidelines require the sending IP to have a PTR record that resolves to a hostname, and that hostname to have an A or AAAA record resolving back to the same IP. Only the owner of the IP can publish that, and the owner of the IP is rarely you.
The two wordings that share the 5.7.26 code are worth separating now, because they send you to different places. The one quoted above, "must authenticate with at least one of SPF or DKIM", means nothing passed at all. The other one, "Unauthenticated email from example.com is not accepted due to domain's DMARC policy", means your own published policy told Gmail to reject the message, because the authentication that did pass was not aligned with the From domain. We see the second version most often in companies that moved to p=reject before the list of systems sending as their domain was finished.
If yours is 5.7.26: authenticate first, then align
Work in this order. Each step is checkable, which matters when several people are guessing at once.
- Name the system that actually sent the message. Not "our email". The mail server, the CRM, the invoicing app, the website contact form, the scanner in the corridor. Every one of them authenticates on its own, and the one that broke is usually the one nobody remembers turning on.
- Check what that system is allowed to send as. If it relays through your mail provider with a real mailbox and a password, it is usually covered already. If it connects to Gmail from its own servers, it needs either an SPF include that names those servers or its own DKIM key published on your domain.
- Get alignment, not just a pass. For messages sent straight to personal Gmail accounts, Google asks that the organizational domain in the From header match either the SPF domain or the DKIM domain. One of the two is enough. A vendor that signs with its own domain and passes SPF on its own return path can still produce 5.7.26 on your From address, and its support desk will tell you authentication is fine, because from where they sit it is.
- Send one real message and read the headers. A lookup tool tells you what your record says today. The headers of a message Gmail accepted tell you what Gmail did with it. That is the check that closes the ticket.
The full walk-through, including the DMARC policy wording, is in our 5.7.26 guide. One warning before you add an include: SPF is capped at ten DNS lookups by RFC 7208, and one more vendor can tip a long record into a PermError, which fails authentication for every message at once. Count the lookups first.
If yours is 5.7.1: reputation, and no record edit will clear it
This is the slower one. People lose weeks treating it as a DNS problem, publishing a new record every day and watching nothing change. Reputation is a running average of how Gmail users react to your mail, so it moves on Gmail's schedule.
- Decide whether it is the domain or the IP. The bounce says which. If it names the IP and you send through shared hosting, you are carrying someone else's behaviour, and the real fix is to stop sending from that pool.
- Verify the domain in Postmaster Tools and read it. The dashboards show domain and IP reputation along with authentication and delivery error rates for the domain you verified. It is the only view of what Gmail thinks that is not guesswork. Our setup guide covers what each dashboard is worth.
- Get authentication perfect anyway. Reputation recovery on a domain that still fails SPF or DKIM does not start. Authentication is the floor, not the fix.
- Stop whatever caused it. A volume jump, a bought list, a form with no confirmation step, a compromised mailbox sending overnight. Google tells senders to keep the spam rate reported in Postmaster Tools below 0.1 percent and never to reach 0.30 percent, guidance we checked on 23 September 2026. Complaints at that level do not average away quickly.
- Then rebuild slowly. Small volumes to people who reply, held steady for weeks. There is no button, and anyone offering one is selling something.
The 5.7.1 guide has the order we follow on a live reputation case, including what to do when the IP is not yours.
If yours is 5.7.25: someone else owns the fix
Reverse DNS is published by whoever owns the IP address, so a registrar panel is the wrong place to look. If you send through Google Workspace, Microsoft 365 or a normal email platform, their addresses already have PTR records, and a 5.7.25 usually means something else is relaying: an old office server, a VPS running a website's contact form, an appliance with an SMTP setting from a previous decade. Find the IP in the bounce, work out who runs it, and ask them to set a PTR that resolves to a hostname whose A or AAAA record points back to the same address. On a VPS that is a support ticket. On a box under a desk it is often a reason to stop sending directly and relay through the mail provider instead.
What to do while the fix propagates
The hours after the change are where good work gets undone.
- Do not release the stuck queue in bulk. A few hundred retries against a provider that just rejected you reads as exactly what it looks like.
- Let the record's TTL pass before testing. If the TTL was four hours, the answer you get in five minutes is the old one.
- Test with one message to a Gmail address you control, then read its headers. Delivery to your own inbox is not proof on its own.
- Call the people waiting on something urgent. A short phone call beats a proposal sitting in a queue.
- Do not register a new domain to escape the problem. A fresh domain has no reputation at all, a look-alike domain attracts more suspicion, and both leave the original broken.
How Guanacos Tech helps
Most of these cases arrive as one sentence: our email is bouncing. An hour later it is usually three separate things, one of which has been quietly failing for months. We read the bounce, name every system that sends as the domain, fix authentication one sender at a time, verify with real messages rather than lookup tools, and stay on the DMARC reports long enough to know it held. If you have a bounce in hand, our email deliverability consulting for small business starts there. Bring the returned message to a 30-minute call and you will leave knowing which of these three problems you have and what clearing it will take.