Why does Gmail say it cannot verify the sender and mark the email as spam?
Published 28 Jun 2025
Updated 6 Oct 2026
14 min read
Summarize with
Updated on 6 Oct 2026: We clarified Gmail's sender warnings and the fixes for authentication failures.
Gmail says it cannot verify the sender when it cannot authenticate the apparent sender. Common causes include missing or broken SPF, absent or invalid DKIM signing, and forwarding that changes the authentication results. A missing DMARC record alone does not mean the message is unauthenticated. Spam placement is a separate decision that also considers reputation and message content, so an unauthenticated message is not automatically spam.
The direct fix is to inspect the original message, confirm SPF, DKIM, and DMARC results, repair the failed DNS records or sending configuration, then send a fresh message directly to Gmail. A forwarded copy is useful for reading the body, but it is often the wrong evidence for authentication because forwarding changes the path Gmail evaluates.
- Fast answer: Fix authentication first. Gmail requires all senders to personal Gmail accounts to use SPF or DKIM. Bulk senders, defined as sending close to 5,000 messages or more within 24 hours, must use SPF, DKIM, and DMARC. Google counts messages across the same primary domain, including subdomains, and bulk sender status is permanent once assigned. DMARC passes when SPF or DKIM succeeds for a domain that meets the visible From domain's alignment requirements.
- Common root causes: A malformed SPF TXT record, an active sender missing from SPF, DKIM that is absent or invalid, or a sending domain that does not match the visible From domain for DMARC.
- Best evidence: Use Gmail Show original on the message as received by the affected mailbox, not a normal forward.
Why Gmail shows this warning
A question mark next to the sender's name means Gmail treated the message as unauthenticated. A gray avatar alone is not enough to diagnose an authentication failure. Google's authentication guidance explains that the question mark means Gmail cannot confirm the apparent sender. The warning does not establish that the sender is malicious or that the message belongs in spam.
Google's spam guidance tells administrators to authenticate sent mail with SPF, DKIM, and DMARC. It also notes that suspicious messages can still be sent to spam even when a sender is trusted. Authentication is not the whole spam filter, but without it the other reputation checks start from a weaker position.
What Gmail can verify
- SPF: The sending IP is allowed by the envelope sender domain.
- DKIM: The message has a valid cryptographic signature for a domain.
- DMARC: At least one passing SPF or DKIM domain matches the visible From domain under the published alignment mode. Relaxed mode accepts the same organizational domain; strict mode requires an exact domain match.
What weakens trust
- Broken DNS: Duplicate SPF or DMARC records, invalid syntax, or a missing DKIM selector record prevent successful checks. Quotes used to display DNS TXT strings are normal; literal stray quotes inside a policy are the problem.
- Forwarding: The forwarding server becomes part of the path and can break SPF.
- Reputation: Spam complaints, abrupt volume changes, or a blocklist (blacklist) listing can push mail toward spam.
For a Google Workspace domain, regular user-to-user mail still depends on domain-level DNS. If Google Workspace sends mail for the domain, SPF should authorize Google. DKIM should be enabled in the Google Admin console. Publish DMARC for the visible From domain, or confirm that an applicable parent-domain policy covers it, including any subdomain policy.
What recipients and Google Workspace admins can do
The sender must repair authentication, but a recipient can correct a false spam classification while that work happens. These actions affect filtering for the recipient or managed Workspace domain. They do not repair SPF, DKIM, or DMARC, and they do not remove the verification warning for everyone else.
- Mark legitimate mail as Not spam: If the message is in the Spam folder, move a message you have independently verified out of spam so Gmail can use that feedback. An authentication warning on a message already in the inbox does not need a Not spam action.
- Add a trusted sender to contacts: This can reduce false spam placement for that recipient, but only after confirming the sender through a known channel.
- Use Workspace spam bypass controls carefully: An admin can allow a validated sender for the managed domain, but Gmail can still reject or filter a message it considers suspicious.
- Send the evidence back to the sender: Share the original authentication results so the sender can fix the failed domain, selector, or delivery path.
Do not use allowlisting as the DNS fix
A contact entry or admin bypass can change placement for a known recipient, but it does not prove sender identity. Until the message authenticates, verify unexpected requests through another known channel before replying, opening links, or downloading attachments.
How to check SPF, DKIM, and DMARC in Gmail
Gmail Show original menu with SPF, DKIM, and DMARC authentication results.
On a computer, open the affected message in Gmail, choose the three-dot menu beside Reply, then choose Show original. Expand the sender details to see the "mailed-by" and "signed-by" domains; Show original provides the full authentication results and headers. In Gmail for Android, open View details, then View security details for a quick authentication check. For a forwarded message, ask the affected recipient for the original as an attachment so you can inspect the original headers, then send a new direct test.
|
|
|
|---|---|---|
SPF fail or softfail | The connecting IP was not authorized by the envelope sender's SPF policy | Check the sending IP, envelope domain, and forwarding path |
DKIM fail | A signature could not be verified | Check the signing key, selector lookup, and changes to signed content |
DMARC fail | No passing SPF or DKIM result met the From domain's alignment requirements | Fix the failed authentication or domain mismatch |
SPF, DKIM, or DMARC none | No applicable policy or signature was found for that check | Check for a missing SPF or DMARC record, or absent DKIM signing |
Permerror or temperror | A configuration problem or temporary lookup error prevented evaluation | Read the error details; repair configuration or resolve the lookup failure |
All pass | The displayed authentication checks succeeded | If a warning remains, inspect ARC and routing; investigate reputation for spam placement |
Read the Gmail original message summary before changing DNS.
The headers also tell you which domain Gmail evaluated for SPF. SPF checks the SMTP MAIL FROM domain, usually shown in Return-Path, rather than the visible From address. Read Gmail's Authentication-Results entries for smtp.mailfrom, header.d, and header.from to compare the SPF domain, DKIM signing domain, and visible From domain. A passing result for an unrelated domain does not satisfy DMARC. Strict SPF alignment requires an exact From-domain match. DKIM can still satisfy DMARC under its separately configured DKIM alignment mode.
Do not debug from a normal forward
A manually forwarded message is a new message with the forwarder's authentication results. Automatic forwarding can preserve the original From address while changing the connecting server and breaking SPF. Use the message as it arrived in the affected mailbox, or attach the original message so its headers stay intact.
Fix the DNS records Gmail checks
Start with the authentication result Gmail reports as failed. If SPF failed, confirm that the exact envelope sender domain has one SPF policy published as a TXT record. It should start with v=spf1, authorize every active sender for that domain, and normally end with a mechanism such as ~all or -all. SPF has a limit of 10 DNS-querying mechanisms and modifiers during evaluation, including nested includes. Exceeding it returns permerror. Check the evaluated policy before adding another sender.
Typical SPF record for Google WorkspaceDNS
Host: @ TXT: v=spf1 include:_spf.google.com ~all
The Google Workspace example applies when Google is the only sender using that envelope domain. If other systems send with the same envelope domain, combine their required authorizations into one SPF policy. Two separate TXT records beginning with v=spf1 at the same name cause permerror. One long TXT record split into adjacent quoted character strings is valid because receivers concatenate those strings; unrelated TXT records at that name are also allowed.
Broken SPF example: duplicate policiesDNS
Host: @ TXT: v=spf1 include:_spf.google.com ~all TXT: v=spf1 ip4:192.0.2.25 -all
After SPF, check DKIM. If Google Workspace sends for your domain, enable DKIM signing in Google Admin and publish the selector TXT record Google gives you. Use the signature's s= selector and d= signing domain to check s._domainkey.d in DNS, replacing s and d with their actual values. Personal Gmail delivery requires a DKIM key of at least 1024 bits, and Google recommends 2048 bits when the domain provider supports it. DKIM can survive forwarding that leaves the signed body and headers unchanged. When SPF breaks during forwarding, a valid DKIM signature for the required domain can still satisfy DMARC.
Then publish DMARC. If you do not have reporting yet, start with p=none while you identify legitimate senders, then move to quarantine or reject after those senders pass DMARC. A monitoring policy requests no DMARC-based enforcement; it does not turn authentication failures into passes. Suped's DMARC monitoring turns aggregate reports into source-level issues so you can identify failing systems and check their DNS or sending configuration. Replace dmarc@example.com in the example with an active reporting mailbox or the reporting address Suped supplies.
Starter DMARC recordDNS
Host: _dmarc TXT: v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Before sending new tests, use Suped's domain health check and confirm the DMARC TXT value with Suped's DMARC checker. These checks catch DNS problems, but a real inbox test is needed to confirm that the sending system uses those records.
Fix sender settings in apps and mailing lists
A website form or mailing app can use a valid business From address while sending with an unrelated bounce address or DKIM signing domain. Editing the business domain's SPF does not fix SPF evaluated for a provider-owned Return-Path. Check the app's envelope sender, also called MAIL FROM or the bounce address, and its DKIM signing domain.
Illustrative header excerpt with a domain mismatchtext
From: notices@example.com Return-Path: <bounces@sender.example.net> Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=sender.example.net; dkim=pass header.d=sender.example.net; dmarc=fail header.from=example.com
In this illustrative example, SPF and DKIM pass for sender.example.net, but neither authenticates example.com for DMARC. Fix the app's configuration through either of these routes, checking the domain's published alignment mode:
- Configure a custom MAIL FROM or bounce domain that meets the From domain's SPF alignment requirements, and publish SPF for that exact bounce domain. SPF does not inherit the parent domain's record.
- Enable DKIM signing for a domain that meets the From domain's DKIM alignment requirements. This supports DMARC even when the provider keeps its own bounce domain.
Do not use an @gmail.com From or bounce address on an external server that is not authorized to send for gmail.com. Use your own authenticated domain or send through the Gmail account. For contact forms, put the visitor's address in Reply-To and use an authenticated business address in From.
How forwarding and internal routing change the result
Email forwarding path showing SPF, DKIM, and DMARC checks before Gmail delivery.
Forwarding is the reason many Gmail warnings feel inconsistent. With automatic forwarding that preserves the original envelope sender, Gmail sees the forwarder's server as the connecting sender. If the original domain did not authorize that server, SPF fails. Sender Rewriting Scheme (SRS) can make SPF pass for the forwarder's domain by rewriting MAIL FROM, but that pass usually does not satisfy DMARC for the original From domain.
DKIM signs the message body and selected headers. If the forwarder does not modify signed parts of the message, DKIM can pass after forwarding. DMARC can then use that valid DKIM result when its signing domain meets the visible From domain's alignment requirements. Mailing lists that add footers or change a signed Subject header can break the original DKIM signature.
ARC records earlier authentication results as a message passes through intermediaries. ARC does not replace DMARC, but Gmail can use a valid ARC chain when assessing a forwarded message. If ARC records an earlier authentication failure, Gmail can still treat the message as unauthenticated even when the forwarding path now passes SPF or DKIM.
Authentication troubleshooting priorities
Use these editorial troubleshooting categories to decide which authentication results to investigate first.
No passing SPF or DKIM
Repair authentication
Both methods are missing, fail, or encounter errors, so there is no successful authentication result.
SPF or DKIM passes, DMARC does not
Check DMARC
Check the From-domain policy and whether a passing authentication domain meets its alignment requirements.
DMARC passes
Retest delivery
At least one passing authentication domain meets DMARC alignment requirements. Spam placement still depends on other signals.
Internal routing can also matter. A message sent between two users at the same company can still pass through rules, aliases, groups, or routing systems before Gmail delivers it. If those systems modify the message or change the envelope sender, the final authentication result can differ from a direct send.
What to ask for
- Original headers: Ask for the original message headers from the mailbox that saw the warning.
- Fresh test: Ask the sender to send a new message directly to the affected Gmail address.
- Route details: Check whether an alias, group, rule, or forwarding mailbox touched the message.
If SPF, DKIM, and DMARC pass but Gmail still shows a verification warning, inspect the complete ARC results and any routing changes. If the message is in spam without an authentication warning, investigate sending practices and reputation, including complaints, abrupt volume increases, and a blocklist (blacklist) listing. Google's sender guidelines require valid forward and reverse DNS, TLS, RFC 5322 formatting, and a user-reported spam rate below 0.3% for all senders to personal Gmail accounts. Aim below 0.1% and avoid reaching 0.3%. Bulk senders must also provide one-click unsubscribe and a visible body unsubscribe link for marketing and subscribed mail. For deeper diagnosis, use the related header checks workflow.
Use Suped to monitor recurring authentication failures
Manual header checks are useful during an incident, but they do not scale well. Suped's DMARC reporting product supports this workflow: identify a failing source, review the authentication issue, and follow the suggested fix steps.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped groups report data into source-level authentication issues and fix steps. Use those reports to identify recurring failures, then confirm the affected message in Gmail. Aggregate reports usually arrive on a daily cycle and do not show whether an individual message reached the inbox or spam folder.
Manual workflow
- Evidence: Collect original headers from each affected Gmail recipient.
- Diagnosis: Compare DNS records, return-path domains, selectors, and message routes by hand.
- Risk: Small DNS mistakes stay hidden until Gmail starts flagging messages.
Suped workflow
- Evidence: DMARC aggregate data shows source-level pass and fail patterns.
- Diagnosis: Issues are grouped with specific fix steps for SPF, DKIM, and DMARC.
- Follow-up: Review alerts when new report data exposes failures, then retest affected sending sources in Gmail.
Common authentication troubleshooting mistakes
Best practices
Always inspect the original Gmail headers before editing SPF, DKIM, or DMARC DNS records.
Keep SPF as one complete TXT policy; adjacent quoted strings inside one record are valid.
Use DKIM with DMARC so unchanged forwarded mail can retain a valid From-domain identity.
Common pitfalls
Debugging a normal forwarded copy can lead teams to fix the wrong sender path entirely.
Publishing two v=spf1 policies at the same DNS name causes SPF permerror during checks.
Skipping DMARC reports hides recurring source-level failures until recipients report problems.
Expert tips
Check the return-path domain because SPF follows the envelope sender, not the visible From.
Retest with a fresh direct message after DNS changes, then compare Gmail original results.
Treat malformed SPF as urgent even when another signal seems to explain the spam folder.
Expert view
Expert from Email Geeks says the warning usually points to authentication, so SPF, DKIM, and DMARC should be checked before content changes.
2024-04-17 - Email Geeks
Marketer view
Marketer from Email Geeks says Gmail Show original is the fastest way to see whether SPF, DKIM, and DMARC passed for the affected message.
2024-04-17 - Email Geeks
Fix the root cause, then retest
Get the affected message's Gmail authentication results, repair the failed SPF source or DKIM signature and any app sender settings, then publish or correct DMARC. Retest with a fresh direct message and the normal production route. A continuing verification warning needs a full header and ARC review; authenticated mail that still goes to spam needs reputation and sending-practice checks.
Shortest path to resolution
- Inspect: Use Gmail Show original on the affected message.
- Repair: Correct the failed SPF policy, DKIM signing, or app sender settings, and ensure DMARC covers the visible From domain.
- Retest: Send a fresh direct message and one through the usual production route, then compare Gmail's authentication results.
- Monitor: Watch DMARC reports for recurring authentication failures, and blocklist or blacklist signals for reputation issues.
Frequently asked questions
No. The question mark means Gmail treated the message as unauthenticated. Missing or failed SPF and DKIM checks, forwarding, and earlier failures recorded in ARC need investigation. Reputation and suspicious content affect spam placement separately. Check Gmail Show original before changing DNS.
Yes. Internal mail can still be filtered when routing rules, aliases, groups, forwarding, or broken domain authentication make the message look uncertain to Gmail.
Automatic forwarding changes the connecting server. SPF can fail when the original envelope domain does not authorize that server. SRS can make SPF pass for the forwarder without satisfying the original From domain's DMARC alignment. DKIM can survive unchanged signed content, while ARC records earlier authentication results; neither guarantees inbox placement.
Fix the result Gmail reports as failed. Check SPF at the actual MAIL FROM domain, DKIM signing and selector lookup, then DMARC alignment for the visible From domain. If an app uses the wrong bounce or signing domain, correct its settings as well as DNS.
Gmail can use corrected records after cached DNS answers expire according to their TTL. Send a new test after the live records resolve correctly; fixing DNS does not change the authentication results already recorded on an old message. Spam placement can take longer to improve because reputation and recipient feedback also affect filtering.
