How to troubleshoot DKIM setup issues when getting 550 5.7.26 unauthenticated sender error in Google Workspace?
Published 17 Apr 2025
Updated 20 Oct 2026
14 min read
Summarize with
Updated on 20 Oct 2026: We clarified Google Workspace DKIM activation, DNS publication errors, and the authentication checks behind Gmail 550 5.7.26 rejections.
The short answer: troubleshoot 550 5.7.26 in Google Workspace by saving the exact rejection text, proving the sending path, and checking whether that specific message passed SPF or DKIM. Gmail uses this code for several authentication failures, including missing authentication, SPF hard fail, and DMARC policy rejection. A domain can have correct DKIM DNS, clean DMARC aggregate reports, and still trigger this Gmail rejection if the bounced message did not leave through the expected Google Workspace route or lacked the authentication result required by the rejection.
Treat this error as an authentication failure for the specific message. DMARC reports are useful, but they are delayed summaries. They do not prove that a single bounced message had a passing DKIM signature, a passing SPF result, or a From-domain match at the moment Gmail rejected it.
Fast diagnosis
- Rejection: Save the full 550 5.7.26 response and its SPF, DKIM, or DMARC wording.
- Route: Confirm the actual sending server, including any app or alias using the same From domain.
- Sample: Get the bounce, Google Admin email log entry, and one accepted test message with full headers.
- DNS: Validate the Google DKIM selector TXT record, the SPF record, and the DMARC record currently published.
- Escalation: Contact Google support if a direct Workspace test still fails the check named in the bounce after DNS and DKIM activation are verified.
Why Gmail returns 550 5.7.26
Gmail returns 550 5.7.26 for more than one permanent authentication failure. Read the complete response before changing DNS. One version means neither SPF nor DKIM passed, another identifies an SPF hard fail, and another says the message was rejected under the From domain's DMARC policy.
Typical Gmail rejection
550 5.7.26 This mail has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM.
That does not always mean the DKIM DNS record is wrong. The common trap is checking the record for the domain, seeing it looks correct, and stopping there. DKIM is only useful if the mail system that sent the message added a signature using the matching selector and private key. SPF is only useful if the connecting server is authorized by the SPF record for the envelope sender domain.
What the sender sees
- Bounce: Gmail says the sender is unauthenticated.
- Domain: DKIM and DMARC DNS records appear to exist.
- Reports: Aggregate DMARC data can look clean up to that point.
What actually matters
- Message: The failed message needs its own authentication evidence.
- Path: The sender must confirm whether Google actually handled the outbound mail.
- Headers: SPF, DKIM, and DMARC results in headers settle most disputes.
Flowchart showing the troubleshooting order for a Google Workspace 550 5.7.26 error.
Match the exact 5.7.26 response
The enhanced status code points to authentication, but the rest of the bounce identifies the failing layer. Match the wording before deciding whether to change DKIM, SPF, or the sending route. Save the SPF domain and connecting IP shown in the rejection. Google's SMTP error reference documents the different 5.7.26 responses.
|
|
|
|---|---|---|
Sender unauthenticated | Neither SPF nor DKIM passed | Verify route and message headers |
SPF hard fail (-all) | MAIL FROM domain denied the connecting IP | Authorize the source or correct its route |
DMARC policy | No SPF or DKIM pass with DMARC alignment | Fix SPF or DKIM so DMARC alignment passes |
Use the complete Gmail response to choose the next check.
For mail to personal Gmail accounts (@gmail.com and @googlemail.com), all senders must use SPF or DKIM. Bulk senders need SPF and DKIM, plus DMARC with at least p=none. For direct mail, the visible From domain must satisfy DMARC alignment with either the authenticated SPF domain or the DKIM signing domain. See Google's email sender guidelines. Google counts close to 5,000 or more messages within 24 hours across the same primary domain and its subdomains; bulk sender status is permanent once assigned, as explained in Google's sender guidelines FAQ.
Do not weaken DMARC to clear the bounce
Changing p=reject to p=none can stop policy rejection without fixing the legitimate sender. Keep the intended policy and authenticate the source with SPF or DKIM that passes DMARC alignment. Use a temporary policy change only as a controlled rollback with a plan to restore enforcement.
Prove the sending path first
Before editing DNS, answer one plain question: did the message really leave through Google Workspace? The answer has to come from evidence, not memory. A user can send from Gmail in a browser, Apple Mail, a mobile app, a website form, an automation script, or a third-party mail platform while using the same visible From address.
Google Admin console email log search screen for checking a bounced message route.
Google Admin Email Log Search helps verify the route for a Workspace tenant. Search by sender, recipient, time, and message ID. If no entry appears, check the search scope and trace the message starting with the sender; a different sending source is one explanation. Google's Email Log Search guidance explains how to evaluate missing results.
- Gmail web: Mail composed in Gmail should normally carry a signature for your domain once its DKIM setup is active.
- SMTP client: A desktop client can use Gmail SMTP or a non-Google server, so the account settings matter.
- Send as: Gmail Send mail as can route through another SMTP server depending on how the alias was added.
- Website mail: A form, CRM, billing system, or booking tool must be authenticated as its own sending source.
- Gateway: An outbound gateway can change content after signing and create a DKIM body hash failure.
Forwarding changes the connecting IP and can break SPF even when the original sender is configured correctly. Preserve the original DKIM signature by avoiding changes to signed content. Do not add an unrelated forwarding server to your domain's SPF record to repair mail it forwards. Google's SPF troubleshooting guidance covers forwarding failures.
|
|
|
|---|---|---|
Message ID | Bounce | Search logs |
Route | Admin log | Confirm source |
Headers | Test inbox | Read auth |
DNS | Provider | Compare values |
Evidence to collect before changing DNS.
Do not fix MX first
MX controls inbound delivery for the domain. A 550 5.7.26 rejection points to outbound authentication. MX can be relevant to the overall Workspace setup, but it rarely explains why Gmail rejected an outbound message as unauthenticated.
Validate DKIM before changing DNS
Next, verify that Google Workspace has a valid DKIM key and that public DNS has the exact TXT value Google expects. Run the selector through the DKIM checker if you want a quick DNS-level validation before testing a real message.
Google Workspace DKIM TXT record structure
google._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=PASTE_GOOGLE_PUBLIC_KEY_HERE"
In Google Admin, open Apps > Google Workspace > Gmail > Authenticate email and select the sending domain. A newly enabled Gmail service can require 24-72 hours before key generation is available. Publish the matching TXT record, click Start authentication, and confirm the status says "Authenticating email with DKIM". After adding the key, allow up to 48 hours for authentication to work. Publishing DNS alone does not activate signing with your domain's key. Prefer a 2048-bit key; Gmail requires at least 1024 bits. Follow Google's DKIM setup instructions for the activation sequence.
- Selector: Google often uses google, but use the selector shown in Admin. Configure each sending domain separately, including secondary domains and aliases.
- Host: The TXT host must be selector, dot _domainkey, dot the sending domain.
- Value: Copy Google's complete TXT value, including the full p= public key. Do not truncate it or add spaces inside the key.
- Key length: Prefer 2048 bits; use 1024 bits only when the DNS provider cannot support the longer key.
- Activation: Start authentication in Admin to enable new messages to use your domain's DKIM key.
- Testing: Send a fresh email to a different recipient mailbox after activation and inspect its received headers.
When DNS is correct but DKIM still fails
If the DKIM record checks out but mail is unsigned, check the sender route and Google Admin activation state. If a signature is present but fails with "body hash did not verify", check whether an outbound gateway added a footer or changed signed content after signing.
Fix DKIM TXT record publication errors
Check the public record at the DNS host used by the domain's authoritative nameservers.
- If the host automatically appends your domain, enter google._domainkey as the name. Entering the full name there creates a duplicated suffix such as google._domainkey.example.com.example.com.
- Publish Google's key as TXT at the exact selector. Keep one DKIM key record per selector; other sending services should use different selectors.
- For a 2048-bit key, use multiple quoted strings within one TXT record if the DNS editor requires it. Each string is limited to 255 octets. Receivers concatenate the strings in order; separate TXT records do not combine into one key.
- Compare the complete returned p= value with Admin. Check for truncation or pasted whitespace inside the key before generating a replacement.
Look up nameservers and the DKIM TXT recordBASH
dig +short NS example.com dig +short TXT google._domainkey.example.com
Replace the example domain and selector with your own. If the answer differs, query the authoritative nameserver directly and check cached DNS against the record's TTL. See Google's DKIM troubleshooting instructions and DKIM DNS key rules.
Check SPF and DMARC together
Do not troubleshoot DKIM in isolation. The baseline Gmail rule for all senders is an SPF or DKIM pass. For a 5.7.26 response that names the sending domain's DMARC policy, the passing method must also satisfy DMARC alignment with the visible From domain. If neither method passes with alignment for the bounced message, Gmail applies the domain's published DMARC policy. With relaxed DMARC settings, the authenticated domain and From domain can share an organizational domain. The adkim=s and aspf=s tags require exact domain matches for DKIM and SPF respectively. See DMARC domain matching rules.
Google Workspace SPF and DMARC examples
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all" _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:d@example.com"
The SPF example assumes Google Workspace is the only sender using that envelope domain. Merge other authorized sources into its existing SPF record. The DMARC example assumes the reporting mailbox exists; retain an existing enforcement policy instead of replacing it with p=none.
A domain health check helps catch record-level problems across DKIM, SPF, and DMARC. Ongoing DMARC monitoring then shows whether the same sending source keeps passing after the immediate bounce is fixed.
Authentication status levels
Use these bands to decide whether to keep troubleshooting locally or escalate.
Healthy
Pass
The tested message passes the check named in the bounce; DMARC policy errors require a From-domain match.
Warning
Mismatch
DNS looks correct, but the current sending stream is unsigned or uses another source.
Critical
Fail
The bounced message has no SPF pass and no DKIM pass.
Escalate
Support
A direct Workspace test still fails the required check after DNS and DKIM activation are verified.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
For SPF, check the envelope sender (Return-Path) domain: publish one SPF TXT record and authorize Google plus any other source using that domain. SPF permits at most 10 DNS-querying mechanisms and modifiers during evaluation, including nested includes. Exceeding that limit produces permerror. See SPF evaluation limits. For DMARC, confirm the record is published at the _dmarc host and that reports are arriving from the mailbox providers you care about.
Use logs when reports look clean
Clean DMARC aggregate reports are a good sign, but they are not a complete answer for a single rejection. A rejected message might not appear in the same reporting window, might be a low-volume source, or might be sent through an alias path that the normal report view hides.
|
|
|
|---|---|---|
Bounce | Exact reject | Few headers |
Email log | Route | Tenant only |
Test inbox | Auth result | New sample |
DMARC XML | Pattern | Delayed |
Use message-level evidence before changing policy.
Send a fresh message through the same route to a different recipient mailbox. In Gmail, open the received message and choose More > Show original. Read the receiving server's Authentication-Results, then compare d= (signing domain) and s= (selector) in DKIM-Signature with selector._domainkey.signing-domain in DNS. A missing DKIM result alone is inconclusive: inspect the signature header itself. A pass for an unrelated signing domain does not satisfy DMARC for your From domain. A missing signature points to signing or removal; a failing signature requires checking the key and any changes after signing. See Google's DKIM troubleshooting instructions and DKIM signature and key rules.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Collect this before support
- Bounce: Save the full error text, sending time, sender, recipient, and message ID.
- Headers: Capture Authentication-Results from an accepted test message sent the same way.
- Route: Note whether the user sent via Gmail web, mobile app, SMTP relay, alias, or automation.
- DNS: Save the current DKIM, SPF, and DMARC records before making changes.
Monitor authentication failures with Suped
Suped is our DMARC reporting and email authentication platform. Suped brings DMARC aggregate data and authentication diagnostics into one workflow, with alerts for new failures and issue pages that map record or sender problems to practical checks.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For a 550 5.7.26 case, use Suped alongside the bounce and message headers to review observed sending sources, reported SPF or DKIM failures, and DNS issues that need attention.
Manual triage
- Evidence: Logs, DNS lookups, copied headers, and screenshots live in separate places.
- Risk: A one-off source can be missed if aggregate reports look healthy.
- Fixes: The person troubleshooting must translate raw records into next steps.
Suped workflow
- Evidence: DMARC, SPF, DKIM, and source status are reviewed in one dashboard.
- Alerts: Notifications flag reported failures after incoming DMARC reports are processed.
- Fixes: Issue pages give clear steps to fix DNS and sender configuration problems.
Match the DKIM or SPF fix to evidence
Once the route and authentication result are known, the fix should be narrow. Avoid rewriting all DNS records at once. Change the one thing that explains the evidence, send a fresh test, and keep the previous record values in case a rollback is needed.
|
|
|
|---|---|---|
Different sending server | Message used another route | Authenticate that sender or correct the route |
Domain DKIM inactive | No signature for the intended domain | Start authentication for that domain in Admin |
Wrong selector or key | Header selector or key differs from DNS | Publish the matching public key |
SPF authorization gap | Connecting IP fails SPF for the envelope domain | Authorize the actual sender in that domain's SPF record |
Gateway changes | DKIM body hash did not verify | Stop changing signed content or sign after processing |
Match the fix to the evidence.
Do not trust averages
A domain can show a high DMARC pass rate while one important mailbox, alias, or app fails. Troubleshoot the exact stream that produced the bounce, then use aggregate reporting to confirm the fix holds over time.
If the evidence proves the user sent directly through Google Workspace, the DKIM TXT record is correct, Google Admin shows DKIM started, SPF includes Google, and a new Google-to-Gmail test still fails the authentication check named in the bounce, the next step is Google Workspace support. At that point, bring the message ID, log entry, DNS records, and test headers.
Views from the trenches
Best practices
Confirm the sending path before changing DNS, since From domains can hide the real source.
Test a fresh message at a different recipient mailbox, then inspect Authentication-Results.
Keep Google DKIM, SPF, and DMARC checks together so one failed stream is not missed.
Common pitfalls
Assuming clean DMARC reports cover every rejected message can hide one-off failures.
Publishing DKIM without Start authentication leaves custom-domain signing inactive in Admin.
Checking MX records first wastes time when the error points to outbound authentication.
Expert tips
Use Email Log Search to prove the sender, route, and rejection time before editing records.
Compare the selector in the header with DNS; a selector mismatch explains many failures.
Escalate when a direct Workspace test still fails the required check after DNS verification.
Marketer view
Marketer from Email Geeks says the first check is whether the message really left Google Workspace or another source using the same visible domain.
2024-02-14 - Email Geeks
Marketer view
Marketer from Email Geeks says that without headers, the practical path is to verify how the email was sent and recheck SPF and DKIM.
2024-02-14 - Email Geeks
Verify the fix before resending
Once a fresh test passes the check named in the original bounce, resend the rejected message. A 550 response is a permanent rejection, so do not assume that message is still queued for automatic delivery. See SMTP reply handling rules. Passing authentication does not guarantee inbox placement.
Final checklist
- Response: Match the full error wording to authentication, SPF hard fail, or DMARC alignment.
- Path: Verify the actual route in Google Admin logs or the sending server's logs.
- DKIM: Confirm the selector, TXT value, key length, and Admin activation state.
- SPF: Confirm the actual server is authorized by one valid SPF record at the envelope sender domain.
- Headers: Confirm a fresh test has the authentication and alignment result the bounce requires.
Frequently asked questions
No. Gmail uses 550 5.7.26 for several permanent authentication failures. The cause can be missing SPF and DKIM passes, SPF hard fail, DMARC alignment failure, a non-Google sending path, an inactive Google DKIM key, or message changes after signing.
DMARC aggregate reports are delayed summaries. They do not prove the authentication result for one bounced message. A low-volume app, alias, or SMTP route can fail while the main Google Workspace stream keeps passing.
Check Email Log Search for the failed message, then open Apps > Google Workspace > Gmail > Authenticate email. Select the sending domain, confirm its TXT record matches, and look for "Authenticating email with DKIM".
An SPF pass with DMARC alignment can resolve an unauthenticated-sender or DMARC-policy rejection for a direct message when DKIM does not pass. An SPF hard-fail rejection requires correcting authorization for the actual sending IP and envelope domain. Bulk senders to personal Gmail accounts must configure both SPF and DKIM, plus DMARC, even if SPF resolves one bounce.
Contact Google support after a direct Google Workspace send still fails and you have confirmed DKIM DNS, Admin activation, SPF, message route, and fresh test headers. Include the bounce and message ID.
