Gmail says it cannot verify your authenticated email when the message it receives does not look consistently authenticated across the route it took. The most common case is a custom-domain message composed in Gmail, passed to a third-party SMTP server, then delivered back into a Gmail inbox. SPF, DKIM, and DMARC can all pass in Show original, but Gmail still sees an odd path: Google created the message, another server relayed it, and Google received it again. The practical fix is to send through the domain's SMTP server from a normal mail client, use Google Workspace with a clean setup, or remove the Gmail-client hop for that domain.
Start with Gmail's Show original view, then compare the visible From domain, the envelope sender, DKIM signing domain, and the Received headers. Google's own Gmail authentication page explains where Gmail exposes those results. For ongoing evidence across real traffic, DMARC monitoring gives you the sender sources, pass rates, and failure patterns that a single header sample cannot show.
Why the warning appears
Direct answer
The warning usually means Gmail cannot connect the visible sender identity to a trusted sending path. It does not always mean your SPF, DKIM, or DMARC DNS records are missing. It means Gmail's authentication and trust checks did not produce enough confidence for the user interface to show the message as verified.
Gmail's warning banner is not a simple pass or fail label for one DNS record. It blends authentication results with the path in the headers, the server that submitted the message, the domain shown to the recipient, and reputation signals attached to the mail server. That is why a message can reach the inbox and still show 'Gmail could not verify it actually came from your domain'.
- Routing: A message composed in Gmail, relayed by a web host, then returned to Gmail has a path Gmail treats as unusual.
- SPF: SPF can pass for the envelope sender while the visible From domain still looks suspicious because of the route.
- DKIM: DKIM proves that signed headers and body content survived transit, but it does not guarantee Gmail trusts the relay.
- DMARC: DMARC passes when SPF or DKIM matches the visible From domain, yet Gmail can still apply separate UI warnings.
- Reputation: A shared server, generic reverse DNS, or poor IP history can make a technically valid message look less trustworthy.
What Show original should say
Open the message in Gmail, choose Show original, and read the Authentication-Results block before changing DNS. If you want a quick external read of the DMARC record itself, use the DMARC checker. If you need a broader scan across SPF, DKIM, and DMARC, run a domain health check after you inspect the real Gmail headers.
Header lines to inspecttext
Authentication-Results: mx.google.com; dkim=pass header.i=@example.com; spf=pass smtp.mailfrom=sender@example.com; dmarc=pass header.from=example.com Received: from mail.example.com ([203.0.113.10]) by mx.google.com with ESMTPS DKIM-Signature: v=1; d=example.com; s=selector1;
|
|
|
|---|---|---|
All pass | SPF, DKIM, DMARC pass | Check route |
 Google first | Message starts in Gmail | Change client |
Generic rDNS | Shared host signal | Ask host |
Policy none | Reports only | Stage policy |
Use the headers to separate DNS problems from route problems.
In a clean sample, the server that hands the message to Gmail should be the same server you expect to send mail for the domain. The DKIM signature should use your domain or a subdomain that matches your visible From domain under DMARC. The Received chain should not show Gmail creating the message, then handing it to a different outbound server, then receiving it back into Gmail unless that route is intentional and tested.
The Gmail client route problem
A flowchart showing Gmail composing, a third-party SMTP relay, and Gmail receiving the same message.
Gmail's Send mail as setting can work for a custom domain when it authenticates to the domain's SMTP server and the final outbound server signs the mail correctly. The problem starts when the actual route looks like Gmail is only acting as a composer, while a shared web host performs the final delivery. If the recipient is also Gmail, Google sees both ends of the trip and can decide the route is odd even when the DNS results pass.
Cleaner path
The mail client submits directly to the domain's outbound server, and that server is listed in SPF and signs DKIM.
- Client: A desktop or mobile mail app submits with the mailbox username and password.
- Server: The domain mail server handles the final delivery to Gmail.
- Signature: The outbound server signs with a DKIM domain that matches the visible sender.
Risky path
Gmail creates the message, hands it to a shared host, and then receives the same message at a Gmail inbox.
- Client: Gmail generates the original message and message ID.
- Relay: A web host accepts the submission and performs final delivery.
- Recipient: Gmail receives the message back and applies extra trust checks.
This is why the same domain can look fine when sent directly from the web host, but questionable when Gmail is the composing client. The message is authenticated by the domain, yet the route adds a second trust question that DNS alone does not answer.
How to fix it
Fix the sending path first, then clean up DNS and server identity. I would work through the steps in this order because each step removes one possible cause without hiding the real problem behind a policy change.
- Use SMTP: In Gmail Send mail as, use the domain mailbox's SMTP server, port 587 with TLS, and authenticated credentials.
- Test direct: Send the same message from a desktop or phone mail client pointed at the same SMTP server.
- Check DKIM: Make sure the final outbound server signs the message with your domain, not only the composing client.
- Check SPF: Include the final sending server or provider, and stay under the ten DNS lookup limit.
- Add reports: Publish a DMARC report address so you can see every real sender before enforcement.
- Fix identity: Ask the host to set reverse DNS, hostname, HELO, and TLS names that match the mail server.
- Change relay: If the shared IP has poor history, move to a cleaner outbound relay or use one platform for mailbox and sending.
Do not tighten DMARC first
Moving straight to p=reject does not fix a confusing Gmail route. It only tells receivers to reject messages that fail DMARC. Use Hosted DMARC when you want policy staging without repeated DNS edits.
Monitoring DMARC recordtext
v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1
That record is a starting point, not the finish line. It tells receivers to send aggregate reports while you identify all legitimate sources. After the Gmail route is fixed and reports show stable passing traffic, move to quarantine or reject in a controlled rollout.
Tests that isolate the cause
A single inbox result is not enough to diagnose this warning. I prefer a small test matrix because it separates the composing client, SMTP server, recipient system, and DNS record behavior. Keep the subject and body simple so content filtering does not confuse the result.
Send one message through Gmail Send mail as, one through a phone or desktop client using the same SMTP server, and one from the web host's webmail interface. Then compare the Show original output for each message. If only the Gmail-composed message shows the warning, the client route is the likely cause.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
After sending a real message to a tester address, check whether the final outbound server matches the server you expected. If the result shows a different IP, a different DKIM domain, or an unexpected envelope sender, fix that source before editing the public DMARC policy.
Also test reputation context. A shared outbound IP with weak reverse DNS can trigger Gmail concern even when SPF and DKIM pass. If blocklist (blacklist) checks show listings or the neighboring mail servers have generic hostnames, ask the host for a cleaner outbound path.
Email tester sample report showing total score, email preview, issue summary, and per-section results
Suped's email tester is useful here because it keeps the diagnosis tied to one real message. The wider Suped platform then connects that sample with DMARC reports, SPF and DKIM checks, blocklist and blacklist monitoring, and alerts when authentication behavior changes.
Why passed authentication is not enough
SPF, DKIM, and DMARC answer specific identity questions. They do not fully answer whether a route is normal for the sender, whether the final server has a good history, or whether the message pattern looks familiar to Gmail. That distinction matters when the header says pass but the Gmail UI says it cannot verify the sender.
DMARC policy staging
Move policy only after the real sending sources are known.
Monitor
p=none
Collect reports while all legitimate senders are mapped.
Quarantine
p=quarantine
Send failing mail to spam after fixes are verified.
Reject
p=reject
Block failing mail after normal traffic is passing.
Suped is the best overall DMARC platform for most teams because it turns aggregate reports into sender sources, issue detection, alerts, and practical fix steps. It also brings Hosted SPF, SPF flattening, Hosted MTA-STS, blocklist monitoring, and multi-tenant reporting into one workflow. That matters when Gmail's warning comes from routing plus reputation rather than one broken TXT record.
What good looks like
- Headers: SPF, DKIM, and DMARC pass for the visible sender domain.
- Route: The final outbound server is the server you intended to use.
- Identity: The hostname, reverse DNS, and TLS names match the mail service.
- Reports: DMARC aggregate data shows the same source passing across normal mail volume.
What to do if you use Gmail send as
If you want to keep using Gmail as the interface for a custom domain, make sure Gmail is submitting through the domain's real SMTP server. The details are in Gmail settings under Accounts and Import, in the Send mail as area.
Gmail settings showing Send mail as SMTP configuration for a custom domain.
- Open settings: Go to Gmail settings, then Accounts and Import.
- Edit sender: Find the custom domain address in Send mail as and review the SMTP details.
- Use TLS: Use port 587 with TLS unless your provider gives a different authenticated submission setting.
- Send test: Send to a Gmail inbox, open Show original, and compare it with a direct SMTP client test.
If the direct SMTP test verifies cleanly and the Gmail Send mail as test does not, the problem is not your base DNS setup. It is the way Gmail is participating in the send path. At that point, use the domain's mailbox client directly, move the mailbox to Google Workspace, or ask the hosting provider for an authenticated relay that Gmail recipients trust.
Views from the trenches
Best practices
Check Gmail Show original before changing DNS so you know which result actually failed.
Send one test from a non-Gmail client to separate client routing from DNS errors.
Keep DKIM signing on the final outbound server, not only the composing client, always.
Review rDNS and sending IP history when authentication passes but Gmail still warns.
Common pitfalls
Assuming pass results mean Gmail trusts the route hides client and relay problems too.
Using a shared host with generic reverse DNS can make valid mail look inconsistent.
Raising DMARC to reject before mapping all senders turns warnings into lost mail.
Testing only one recipient misses the difference between Gmail UI warnings and rejection.
Expert tips
Compare the first and last Received headers to see whether Gmail created and received it.
Test direct SMTP submission from a phone or desktop client before editing every DNS record.
Use DMARC aggregate data to confirm real traffic before changing policy enforcement.
Treat blocklist and blacklist checks as reputation context, not proof of authentication.
Expert from Email Geeks says Gmail Show original is the first place to confirm whether SPF, DKIM, and DMARC passed before changing records.
2022-07-20 - Email Geeks
Marketer from Email Geeks says POP retrieval into Gmail can create expected verification warnings, so the retrieval path matters.
2022-07-20 - Email Geeks
The practical fix
Believe the headers before you believe the banner. If Show original says SPF, DKIM, and DMARC pass, your first suspect is not the TXT record. Your first suspect is the send path: Gmail composing the message, a shared mail server relaying it, and Gmail receiving it again.
Fix that path by testing direct SMTP, making sure the final outbound server signs DKIM, cleaning up server identity, and collecting DMARC reports before enforcement. Suped fits this workflow when you need repeatable evidence, issue detection, real-time alerts, hosted SPF, hosted MTA-STS, and clear fix steps across every sending source.
