Reading a Gmail 5.7.26 Bounce When the Customer Only Sends a Screenshot

A customer sends a screenshot of a bounce. It is cropped, there is a line with 550-5.7.26 and half a sentence about authentication, and nothing else. No headers, no timestamp, sometimes not even the recipient. The question is always the same: why did Gmail reject this, and is something wrong on the server? The useful thing about 5.7.26 is that it is narrow. Gmail uses it when a message fails sender authentication, meaning SPF, DKIM, or DMARC did not give Gmail what it needed. Your job is to work out which one, and the screenshot alone rarely settles that.

What the screenshot already tells you

Read what is there before asking for anything. The leading 550 is the SMTP reply code, and any 5xx code is a permanent rejection. The 5.7.26 part is the enhanced status code: the first 5 again means permanent, and the 7 class covers security and policy problems. So retrying will not help. This is not like a 421 deferral that sits in the queue and eventually goes through. Something about the domain or the sending path has to change. Next, look at the wording, because the variant is the most useful clue in the image. One family of messages says the sender is unauthenticated and that Gmail requires senders to authenticate with either SPF or DKIM. Newer versions of that message also list the results Gmail saw, for example that DKIM did not pass and that SPF for a given domain and IP did not pass. The other family says unauthenticated email from the domain is not accepted due to the domain's DMARC policy. Google adjusts this text from time to time, so treat these as patterns rather than exact strings to search for. Then check who generated the bounce. If the customer sent from a mailbox hosted on your server, the bounce usually comes from the server's own mail system, often shown as Mail Delivery System or mailer-daemon at the server hostname, relaying what Gmail answered. Exim bounces typically include a line like 'SMTP error from remote mail server after end of data' and name the Gmail host it talked to. If the bounce came from a newsletter platform, a CRM, or another mail provider, the message never touched your server. In that case your Exim config is irrelevant and the question becomes whether the domain's DNS authorizes that service. This one detail decides whose logs you need.

Ask for the bounce itself, not a better screenshot

Cropping tends to cut exactly the parts you need: the recipient, the time, and the copy of the original message that usually sits below the error. Instead of asking for a bigger screenshot, ask for these:

The bounce forwarded as an attachment, or its raw source. Most mail clients and webmail have an option like 'show original' or 'view source'.
The exact From address that was used, and the recipient address.
Roughly when it was sent, including the timezone.
How it was sent: webmail, a desktop client, a website contact form, a plugin, or an external service.

The fourth item is the one customers skip, and it is often the answer. A contact form that puts the visitor's own address in From, a plugin sending as a gmail.com address through the server's mail function, or a newly connected app that does not sign with DKIM will all produce 5.7.26, even when the domain's records are fine for normal mailbox mail. A raw Exim bounce normally includes a copy of the original message with its headers, which gives you the From, Return-Path, and Message-ID. One caveat: on many setups the DKIM signature is added at the moment of delivery, so the copy in the bounce may not contain a DKIM-Signature header. Its absence there does not prove the message was unsigned.

Find the delivery attempt in the server logs

If the mail went out through your server, the log has everything the screenshot lacks: the message ID, the envelope sender, the Gmail host, and the full rejection text. On a cPanel server running Exim, the main log is usually /var/log/exim_mainlog, and exigrep collects every line belonging to matching messages so you see each delivery as one block:

BASH

exigrep '[email protected]' /var/log/exim_mainlog

If the send happened a few days ago, the entry may be in a rotated or compressed log, depending on how rotation is set up. In the output, the arrival line marked <= shows the envelope sender, which is the address SPF is actually checked against. The line marked ** is the permanent failure and holds Gmail's full response, including the variant wording that the screenshot cut off. On Postfix servers the log is usually /var/log/mail.log or /var/log/maillog depending on the distro, and you follow the queue ID instead. Pay attention to the envelope sender. If it is a cPanel username at the server hostname rather than an address on the customer's domain, SPF might pass for the hostname but still not match the From domain. That matters a lot once DMARC is involved.

Check the records against what Gmail saw

With the sending domain confirmed, query the three records directly rather than trusting what the DNS panel shows:

BASH

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT default._domainkey.example.com

Replace default with the real selector, which is the s= value in the message's DKIM-Signature header. cPanel servers commonly use default, but confirm it rather than assume. If a record was changed recently, also query the domain's authoritative nameserver with @ns1.yourdns.example so caching does not mislead you. If the DKIM record looks saved in the panel but dig returns nothing, the host field is a common culprit, covered in Why a DKIM Record That Looks Saved Still Fails When You Query It with dig. For SPF, there should be exactly one record starting with v=spf1, and it must cover the IP that actually connected to Gmail. Two SPF records on the same name is an error in itself. The outbound IP is not always the website's IP: the server may use a separate mail IP per domain, relay through a smarthost, or deliver over IPv6. That last one surprises people. If the server has working IPv6, it may reach Gmail over IPv6, and an SPF record that lists only the IPv4 address will fail. The bounce variant that prints the SPF result with an IP is very helpful here, because it shows the address Gmail evaluated. For DKIM, the key should exist as a single TXT record, and signing has to be enabled for that domain on the server. A published key does nothing if the mail server is not signing. For DMARC, look at the p= value. With p=none, Gmail will not reject because of the DMARC policy itself, though the unauthenticated variant can still appear if neither SPF nor DKIM passes. With p=reject, Gmail usually rejects failing mail, and p=quarantine usually sends it to spam instead.

Tie the wording back to the cause

If the bounce says the sender is unauthenticated and mentions SPF or DKIM, neither check passed. For low-volume senders Gmail asks for at least one of them. Bulk senders, which Gmail defines as close to 5,000 or more messages per 24 hours to personal Gmail accounts, need SPF, DKIM, and DMARC together, and once a domain crosses that threshold Google keeps treating it as a bulk sender. The practical fix is to get DKIM signing working for the domain and make sure SPF lists the real outbound IP. If the bounce mentions the domain's DMARC policy, the domain publishes an enforcing policy and neither SPF nor DKIM passed in alignment with the From domain. This is where people get confused: SPF can pass for the envelope domain and DKIM can pass for a third-party d= domain, and DMARC still fails because neither matches the From address. Reading the Authentication-Results header shows exactly which identifier is off, and Reading Authentication-Results Headers to Fix DMARC Alignment walks through that. If the From address is not the customer's domain at all, for example a gmail.com or yahoo.com address placed there by a contact form, no DNS change on the customer's side can fix it. Those domains publish their own DMARC policies, and your server is not authorized to send for them. The fix is in the application: send From an address on the customer's domain and put the visitor's address in Reply-To. One more pattern: if the Gmail address is the destination of a forward, SPF usually fails at the forwarding hop because the forwarder's IP is not in the original domain's SPF. DKIM normally survives forwarding as long as the message is not modified, which is another reason DKIM signing matters more than people expect. After a change, send a test through the exact same path to a Gmail account you control. If it arrives, 'Show original' displays the SPF, DKIM, and DMARC results in one place, which confirms the fix better than another round of screenshots. The short version for support: a 5.7.26 bounce is permanent and always about authentication, so do not wait for a retry. Get the raw bounce and the sending method, find the ** line in the log for the full Gmail wording, then check the three records against the IP and envelope sender that actually reached Gmail. Most of the time the answer is one of three things: no DKIM signing, an SPF record that misses the real outbound IP, or a From address the server was never allowed to use.