Gmail rejected one route, not your whole domain
You send an invoice, a quote or a booking confirmation. A few seconds later, it comes back with a wall of text and one line that matters:
550 5.7.26 This email has been blocked because the sender is unauthenticated.
You check your domain. SPF exists. DKIM exists. DMARC exists. A checker gives you green marks. Yet Gmail has rejected the message.
That feels contradictory, so the usual response is to edit all three records, wait for DNS to update and try again. Sometimes that works. It can also break a sender that was working, create two SPF records, or weaken a DMARC policy that was doing its job.
The contradiction disappears once you stop asking, “Is my domain authenticated?” and ask a narrower question:
“Did this particular message, sent through this particular route, authenticate using the identities Gmail checked?”
A domain does not pass SPF or DKIM once and stay passed. A receiving server evaluates a message. The result belongs to that message, its sending IP, its envelope domain, its DKIM signature and its visible From address.
That is why a green checker and a 550 5.7.26 bounce can both be telling the truth.
You can work out which truth matters without buying a tool. You need the complete bounce, one controlled test message, three DNS lookups and a short map of the services that send as your domain.
The first useful distinction is between an email address and a sending route.
Suppose accounts@example.com sends ordinary replies through Microsoft 365. The same visible address also appears on invoices generated by accounting software, while a website form sends notifications through the web host.
To a customer, all three messages come from the same business. Technically, they may leave from three different networks, use three envelope domains and carry different DKIM signatures.
If the invoice route fails, changing Microsoft 365 may do nothing. If the website route fails, adding the web server to the SPF record for the wrong domain may do nothing. If one route signs with the software provider’s domain, the signature can pass and still fail to align with the address the customer sees.
The 550 response is a permanent failure for that SMTP attempt. It does not mean Gmail has condemned your entire domain forever. It means Gmail refused that message under the conditions it saw at that moment.
Do not keep resending the same message while nothing has changed. Preserve the evidence first. Then test once you have a reason to expect a different result.
The bounce already names the two checks that failed
Google currently lists three versions of 5.7.26 in its Gmail SMTP errors and codes reference. The wording tells you which branch of the investigation to follow.
One version says the sender is unauthenticated and gives results similar to:
DKIM = did not pass
SPF example.com with ip: sender-ip = did not passThat version gives you two important objects: the domain Gmail used for SPF and the sending IP it tested. Write both down exactly. Do not replace the domain with the one you expected to see.
Another version says that the (E)MAIL FROM domain has an SPF record ending in a hard-fail policy, but the sending IP did not pass. That is more specific. The envelope domain made a strong statement about authorised senders, and the observed IP did not satisfy it.
A third version says unauthenticated email from a named domain is not accepted because of that domain’s DMARC policy. This can happen even when someone tells you “SPF passed” or “DKIM passed”. DMARC also asks whether a passing identity belongs with the domain in the visible From address.
Those are different failures. Treating all of them as “add DMARC” throws away the best evidence Gmail has given you.
For the wider meaning of SMTP and enhanced status codes, use the email bounce code guide before deciding whether to retry.
A green DNS checker can still describe the wrong sender
A DNS checker can confirm that a record exists and that its syntax appears readable. It cannot prove that your invoice software used that record, that your website added a valid DKIM signature, or that Gmail saw the IP you expected.
Picture a building with three doors. You inspect the lock on the front door and find it working. The failed delivery went to the loading bay.
The checker is not wrong. You checked the wrong route.
This is the mechanism most quick-fix guides skip. SPF does not simply inspect the domain after @ in the address shown to the recipient. It normally evaluates an identity from the SMTP conversation, commonly the domain in the envelope sender or return-path, against the IP that connected to Gmail. The SPF specification describes SPF as a way for a domain to authorise hosts to use its names in the SMTP MAIL FROM or HELO identities.
DKIM asks a different question. It verifies a cryptographic signature added to the message. The signing domain is stored in the d= tag, and the selector used to find the public key is stored in s=. The DKIM specification is careful about the limit: a verified signature associates the d= domain with the signed content. It does not, by itself, prove that the person named in the visible From address wrote the message.
DMARC joins those results to the address a person sees. That is where alignment enters the picture.
You are not checking whether “the domain” has three badges. You are checking whether one message can connect its visible identity to at least one identity that passed authentication.
Four identities turn one email address into a small investigation
Take a message that appears to come from billing@example.com. Four details may matter:
- The visible From domain is
example.com. This is what the recipient sees in the From header. - The envelope sender might be
bounce.vendor-mail.net. This often appears as the return-path after delivery and is commonly the SPF identity. - The DKIM signing domain might be
example.com,mail.example.comorvendor-mail.net. You find it afterd=in the DKIM signature. - The sending IP is the server address that connected to Gmail. A 5.7.26 bounce often prints it beside the SPF result.
Now the failure becomes concrete.
If the sending IP is authorised by the SPF record for bounce.vendor-mail.net, SPF may pass. But if your visible From domain is example.com, that SPF result may not align for DMARC.
If the vendor signs with d=example.com, and the signature verifies, DKIM can provide the aligned pass instead. If it signs only with d=vendor-mail.net, DKIM may pass as a signature while still failing the relationship DMARC expects.
Google’s current email sender guidelines say that messages must pass SPF or DKIM for all senders to personal Gmail accounts. They also state that bulk senders need SPF, DKIM and DMARC, and that the authenticating domain must match the domain in the From header for DMARC authentication.
This explains a common puzzle: “The vendor says DKIM is working, so why did Gmail reject us?”
The vendor may be proving its own signature. You need to know which domain signed and whether that identity fits the address your recipient saw.
email authentication glossaryStart with the message before you touch DNS
Set aside thirty quiet minutes. Do not log in to your DNS provider yet.
First, save the complete bounce as plain text or a file. Do not keep only the subject line or a screenshot of the first sentence. You want:
- the full 550 5.7.26 wording;
- the domain printed in the SPF result;
- the IP address printed beside it;
- the original recipient domain;
- the time of the attempt;
- the system that created the message;
- any message ID or provider event ID.
Remove recipient names and message content before sharing the evidence outside your organisation. A bounce can contain addresses, internal hostnames and fragments of the original message.
Next, identify the source in ordinary language. Write “Xero invoice”, “WordPress contact form”, “Microsoft 365 mailbox”, “booking reminders” or whatever is true. “Our email” is too broad to diagnose.
If the same source can deliver to another mailbox you control, send one plain, non-sensitive test there. Do not use a customer as your test recipient. Keep the visible From address and sending route the same as the failed message.
Open the delivered test and view the raw message. In Gmail, use the message menu and choose “Show original”. In Outlook, follow Microsoft’s current instructions to view the internet message headers. Interface names change, so check the provider’s help if the wording differs.
Search the raw text for:
Authentication-Results:
Return-Path:
DKIM-Signature:
Received:Under Authentication-Results, copy the SPF, DKIM and DMARC lines. Under DKIM-Signature, copy only the d= and s= values. Do not publish the whole header. It may contain addresses and internal routing details.
If you cannot deliver a control message anywhere, use the sender’s event log or ask its support team for the envelope sender, signing domain, selector and outbound IP used for the failed event. Those are precise questions. “Is our authentication correct?” invites a green reassurance that may describe another route.
Build a sender map you can finish this week
Open a blank spreadsheet. Use one row per sending system, not one row per email address.
Create these columns:
System or service
Message type
Visible From domain
Envelope or return-path domain
DKIM d= domain
DKIM s= selector
Sending IP or provider network
DNS owner
Service owner
Current result
Evidence dateFill the first row with the source that produced the 5.7.26 bounce. Then add your ordinary mailbox provider, website forms, marketing platform, accounting software, booking system, help desk and any application that sends alerts.
You do not need to finish the whole company before fixing one failure. The map stops you from repairing the wrong service and gives you a place to record what you learn.
For example, your failed row might look like this:
System: Accounting platform
Message type: Customer invoices
Visible From: example.com
Envelope domain: bounce.vendor-mail.net
DKIM d=: vendor-mail.net
DKIM s=: mail2026
Sending IP: sender-ip
DNS owner: Operations team
Service owner: Finance team
Current result: SPF fail, DKIM fail, Gmail 5.7.26
Evidence date: date of testThat row exposes the next question. Does the platform support custom DKIM for example.com? Does it expect you to publish records before switching signing on? Is the IP in the bounce part of the provider’s documented network? Does the provider control the envelope domain, which means you cannot repair its SPF yourself?
You have turned a vague domain problem into an ownership conversation.
Test SPF against the IP Gmail actually saw
Take the exact SPF domain and IP from the bounce. If Gmail printed bounce.vendor-mail.net, do not begin by checking example.com.
On macOS or Linux, you can look up a TXT record in Terminal:
dig +short TXT bounce.vendor-mail.netOn Windows, use Command Prompt or PowerShell:
nslookup -type=TXT bounce.vendor-mail.netYou can also use Google Admin Toolbox Dig if you prefer a browser. The aim is the same: retrieve the public TXT record for the exact domain Gmail named.
Find the record beginning v=spf1. If none exists, the domain cannot produce an SPF pass through a published SPF policy. If more than one separate v=spf1 record exists at the same name, stop and ask the DNS owner to correct the SPF publication. The SPF specification treats multiple records as an error rather than combining them for you.
If one record exists, compare it with the sending IP and the provider’s current setup instructions. A simple ip4: or ip6: entry may make the relationship obvious. An include: tells the receiver to evaluate another domain, so reading only the first line is not enough.
Do not paste the IP into your visible domain’s SPF record just because it appears in the bounce. First establish who owns that IP and which envelope domain the sender uses. Shared email services change infrastructure. Their documented include: or other supported setup may be the maintainable route. An unexplained IP copied into DNS can become stale or authorise the wrong system.
If the bounce says the envelope domain has -all and the IP fails, contact whoever controls that envelope domain. If it belongs to your service provider, only that provider may be able to repair the policy or route. If it belongs to you, compare the observed IP with the system that should have sent the message before changing the record.
SPF answers a narrow question: was this IP authorised to use this SMTP identity? Keep it narrow.
To rebuild and test the SPF your route actually needs, follow SPF, DKIM and DMARC setup basics instead of pasting a generic recipe.
Test DKIM where the message was really signed
Use the control message or sender log to find two DKIM values:
d=example.com
s=selector1The public key should be available at:
selector1._domainkey.example.comQuery it with:
dig +short TXT selector1._domainkey.example.comor on Windows:
nslookup -type=TXT selector1._domainkey.example.comA visible public key proves that DNS has a key at that selector. It does not prove that the failed message carried a signature, that the sender used the matching private key, or that the signature survived later changes.
Return to Authentication-Results in the delivered control message.
If it says dkim=none, the message was not signed in a way the receiver reported. Publishing another key will not switch signing on. Enable DKIM in the system that sends the message, following that provider’s current instructions.
If it says dkim=fail, read the reason if one is supplied. A missing key, wrong selector, key mismatch or message changed after signing needs a different fix. Do not rotate records at random.
If it says dkim=pass, note the domain after header.d= or the equivalent field. That is the identity that passed. Compare it with the visible From domain in the next comparison.
This is another place where dashboards mislead. A provider can show “DKIM configured” because it found your public key, while a particular application route is still unsigned or using a different selector.
Use DMARC to compare domains, not to chase another pass badge
DMARC looks at the visible From domain and asks whether at least one passing authentication identity aligns with it.
For your control message, write three lines:
Visible From domain:
SPF domain that passed or failed:
DKIM d= domain that passed or failed:If the visible From domain is example.com, SPF passes for bounce.vendor-mail.net, and DKIM passes for vendor-mail.net, the message may have two technically valid results without either one representing example.com for DMARC.
The practical fix is often to configure the sender’s custom domain authentication so it signs with your domain or an aligned subdomain. Another supported design may use an aligned custom return-path. Which option is available depends on the sending service.
Do not respond by changing your visible From address to the vendor’s domain unless that address is genuinely yours to use and makes sense to the recipient. Do not weaken p=reject to p=none simply to make the bounce disappear. A policy change affects every message claiming to come from the domain, while the fault may belong to one route.
If the bounce specifically says your domain’s DMARC policy caused the rejection, confirm the failed source is legitimate. Then repair its aligned SPF or DKIM path. If you cannot identify the source, tightening or weakening policy is premature. Unknown traffic could be forgotten legitimate mail, forwarding artefacts or unauthorised use. You need more evidence.
DMARC is the comparison, not an extra stamp.
how to read DMARC reportsFix the owner of the broken route, then send one controlled test
Your sender map should now point to one of four owners.
If the mailbox platform sends the message, use its official DKIM and SPF setup. Check that the records are published in the authoritative DNS and that signing is enabled inside the platform.
If a marketing, accounting or booking service sends it, use that service’s custom-domain authentication process. Give the DNS owner the exact records from the service. After publication, return to the service and complete any verification or activation action. DNS publication and sender activation are separate actions on some platforms.
If a website sends it, find out whether the site uses authenticated SMTP, an API or the web server’s local mail function. Route the form through a supported sender that authenticates your domain. Do not repair a website route by weakening domain-wide policy.
If an unknown server sends it, stop. Do not authorise the IP merely to clear the error. Confirm whether it belongs to your organisation or a contracted provider.
Once the change is complete, repeat the same controlled test through the same source. Keep the message plain and non-sensitive. Check the recipient result, then inspect the raw message.
You are looking for four things:
- Gmail accepts the message instead of returning 5.7.26.
- SPF passes for the envelope identity you expected, or DKIM passes with the intended signing domain. Preferably both work.
- DMARC passes because at least one passing identity aligns with the visible From domain.
- The ordinary business route still works, including the correct reply address and message content.
Record the result and date in your sender map. If the test fails, compare the new bounce with the old one. A changed error is new evidence. It is not permission to edit every record again.
Stop if the evidence points outside your control
Some cases need the provider or a mail administrator.
Stop and escalate if the envelope domain belongs to a supplier whose SPF hard-fails the IP it used. Stop if the service will not tell you its signing domain or selector. Stop if you cannot identify who controls authoritative DNS. Stop before deleting a record you do not understand.
You should also stop if a change could interrupt several business systems, if your DMARC reports contain unexplained legitimate volume, or if the failed message carries sensitive customer information that you cannot safely reproduce in a test.
Send support a compact evidence pack:
Time and timezone of failed send
Recipient provider
Complete redacted SMTP response
Message or event ID
Sending feature or product
Visible From domain
SPF domain and IP named by Gmail
DKIM d= and s= values, if available
Relevant DNS answers
Result of one controlled testAsk a route-specific question: “Why did your invoice sender use IP X with envelope domain Y, which Gmail reports as SPF fail, and which custom DKIM setup should sign this route for our From domain Z?”
That is harder to dismiss than “Gmail blocks us”. It also keeps the supplier focused on the message path it controls.
The bounce is resolved when the same route passes, not when a dashboard turns green
You can now answer the questions that made the error look mysterious.
Your checker was green because it inspected published records. Gmail rejected a message because the route it received did not pass the required checks.
The SPF domain may differ from the visible From domain because SPF commonly uses the envelope sender. Adding an IP to the visible domain’s record will not fix a test performed against another domain.
A passing DKIM result may still be unhelpful for DMARC if the signing domain belongs to the vendor rather than aligning with your From domain.
You prove the fix by repeating one controlled message through the same system, confirming acceptance, reading the new authentication results and recording the route in your sender map.
Keep that map. The next time a new booking tool, website plugin or finance platform wants to send as your domain, add its row before publishing anything. The small habit prevents the same failure from returning under a different product name.
Sources and further reading
- Google Workspace: Gmail SMTP errors and codes
- Google: Email sender guidelines
- RFC 7208: Sender Policy Framework
- RFC 6376: DomainKeys Identified Mail
- RFC 9989: Domain-based Message Authentication, Reporting, and Conformance