What causes the Gmail authentication alert and how to resolve it?
Updated on 16 Oct 2026: We added Google security alert verification steps and clarified Gmail authentication fixes and bulk sender requirements.
A question mark beside the sender means Gmail treats the message as unauthenticated. Check SPF and DKIM, plus ARC history for forwarded mail. A message can also pass SPF or DKIM for an unrelated domain and then fail DMARC because the authenticated domain lacks alignment with the domain shown in the visible From address.
The fastest resolution is to inspect Gmail's Show original view and read the Authentication-Results header. Fix a basic SPF or DKIM failure first. If a mechanism passes but DMARC fails, compare its authenticated domain with the visible From domain and then check whether strict adkim=s or aspf=s requires an exact match. For example, a DKIM signature from mail.example.com does not provide strict DKIM alignment for a From domain of example.com. DMARC still passes if SPF provides a separate passing and aligned result.
- Start with the indicator: A Gmail question mark means Gmail treats the message as unauthenticated. Forwarded mail also needs an ARC history check.
- Check DMARC separately: A passing SPF or DKIM result only supports DMARC when its domain aligns with the visible From domain.
- Use header evidence: The answer for a delivered message is in Authentication-Results, not in a generic DNS check alone.
- Apply the narrow fix: Repair the failing mechanism, configure an aligned DKIM or return-path domain, or change strict alignment only when the policy is causing the failure.
Sender verification and account access are separate
Gmail sender-verification warnings and authentication-related delivery errors concern the sending domain. Google Account login alerts, recovery notices, and two-factor prompts require account security checks.
Identify the Gmail warning before changing DNS
The phrase Gmail authentication alert can describe several unrelated events. Match the visible warning or bounce code before troubleshooting. SPF, DKIM, and DMARC changes address domain authentication; sign-in alerts require account security checks.
|
|
|
|---|---|---|
Question mark by sender | Gmail treats the message as unauthenticated | Inspect SPF, DKIM, and forwarding history in Show original |
Phishing or dangerous-message banner | Gmail detected risky identity, content, or links | Do not interact; review authentication and message signals |
New-device or suspicious sign-in alert | Google detected account activity | Review the Google Account security event |
SMTP 5.7.26 rejection | SPF/DKIM authentication failed, SPF hard fail applied, or DMARC policy blocked the message | Read the full bounce and test a fresh message |
The exact alert determines whether to inspect message headers, content, account activity, or a delivery bounce.
If you received the message and do not control its sending domain, contact the sender through a known channel and ask them to investigate. An unauthenticated message is not automatically spam, but verify the sender before replying, opening attachments, or following links.
Treat account alerts as account security events
If the alert names a device, location, sign-in, password change, or recovery action, review the event inside the Google Account security area. If the activity was not yours, secure the account and change the password. Editing DMARC does not resolve that alert.
How to verify a Google security alert
A "critical security alert" or new-device notification concerns your Google Account. Verify it by opening your Google Account directly through Gmail or a trusted browser bookmark. Do not rely on the sender name or follow links in a suspicious alert email.
- Open Security & sign-in and review Recent security events. Match the device, time, and location to your activity, and check that you selected the correct Google Account.
- If the activity was yours, confirm it inside your account. A new browser or private browsing session creates a separate session; an approximate location alone does not prove unauthorized access.
- If you do not recognize the activity, follow Google's account recovery or security steps, change your password, and sign out unfamiliar devices. Review recovery details, third-party access, and unexpected Gmail forwarding rules.
- Enable 2-Step Verification or use a passkey to protect future sign-ins. Never share passwords or verification codes in response to an email or phone request.
For repeated alerts, review Your devices before assuming each entry is a different device. Multiple sessions on one device are normal, and background syncing affects the displayed activity time. Keep security alerts enabled and investigate unfamiliar activity.
Why Gmail can distrust mail after SPF or DKIM passes
An SPF or DKIM pass does not automatically produce a DMARC pass. DMARC checks whether the domain authenticated by SPF or DKIM aligns with the domain in the message's visible From header. If neither passing mechanism has an aligned domain, DMARC fails. Depending on the sender's policy and Gmail's assessment, the message can be rejected, sent to spam, or shown with a warning.
This distinction explains why a sender can confirm that SPF or DKIM passed while Gmail still distrusts the identity shown to the recipient. The mechanism authenticated one domain, but DMARC did not validate the visible From domain.
What a mechanism pass proves
- SPF pass: The sending IP is allowed by the envelope sender domain.
- DKIM pass: The signature validates for the DKIM signing domain.
- Scope of a pass: The result applies to the domain and message evaluated, not every sender using your From address.
What Gmail also evaluates
- From alignment: At least one passing mechanism must have a domain aligned with the visible From domain for DMARC.
- Alignment mode: Strict tags require identical domains, while relaxed mode compares Organizational Domains.
- Forwarding history: ARC can preserve authentication context, but a chain showing an earlier authentication failure can still leave the message unauthenticated.
Authentication-Results exampletext
Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=bounce.vendor.net; dkim=pass header.d=vendor.net; dmarc=fail header.from=example.com
In that example, SPF passed for bounce.vendor.net and DKIM passed for vendor.net, but the From domain is example.com. Neither passing mechanism aligns with the domain the recipient sees, so DMARC fails.
Gmail authentication flowchart connecting the From domain, SPF and DKIM results, DMARC matching, and an alert.
When strict DMARC alignment causes the failure
Strict DMARC matching is one hidden cause in subdomain sending setups. The adkim tag controls DKIM alignment and aspf controls SPF alignment. A value of s requires the authenticated domain for that mechanism to be identical to the From domain.
RFC 9989 is the current DMARC specification. It keeps relaxed alignment as the default for both adkim and aspf. Relaxed alignment accepts domains with the same Organizational Domain, while strict alignment requires identical domains.
Use a DMARC checker to confirm the published policy, but treat Gmail's original headers as the final evidence for that individual message.
|
|
|
|
|---|---|---|---|
DKIM (adkim) | Same Organizational Domain | Identical domain | Unrelated signing domain or strict subdomain mismatch |
SPF (aspf) | Same Organizational Domain | Identical domain | Unrelated return path or strict subdomain mismatch |
Relaxed mode handles common subdomain setups. Strict mode requires deliberate sender configuration.
Strict DMARC record, wrapped for readabilitydns
_dmarc.example.com. TXT ( "v=DMARC1; p=none; rua=mailto:dmarc@example.com;" "adkim=s; aspf=s" )
Relaxed DMARC record, wrapped for readabilitydns
_dmarc.example.com. TXT ( "v=DMARC1; p=none; rua=mailto:dmarc@example.com;" "adkim=r; aspf=r" )
Keep alignment mode separate from enforcement
DMARC needs only one passing and aligned mechanism. With strict DKIM alignment, the signing domain must exactly match the From domain. With strict SPF alignment, the envelope sender domain must exactly match the From domain. Both sample records use p=none for monitoring. Keep your existing p= policy when changing alignment settings; lowering enforcement does not repair authentication.
If you want strict mode, stage it after confirming every legitimate source. Suped's Hosted DMARC workflow helps manage that policy change without repeated DNS edits.
How to check Gmail authentication results
Start with the delivered message or complete bounce, not the domain's public DNS alone. A DNS record can be valid while a specific message fails because it used a different envelope sender, a different DKIM selector, or a third-party signing domain.
- Open original: In Gmail on a computer, open the message, click the three-dot More menu beside Reply, and select Show original.
- Find results: Review the SPF, DKIM, and DMARC summary and Google's receiving Authentication-Results header, normally identified by mx.google.com. Do not substitute an upstream server's results.
- Compare domains: Compare smtp.mailfrom, header.d, and header.from.
- Check policy: Read the sender's DMARC record and note adkim, aspf, p, and sp.
- Send again: After changing DNS or sender settings, allow cached records to expire according to their TTL, then send a fresh message. Old Gmail headers will not update.
For a quick check in Gmail on a computer, expand the sender details and look for "Mailed by" and "Signed by". In the Android app, open View details, then View security details. Use Show original on a computer for the full DMARC diagnosis.
Gmail Show original view with SPF, DKIM, and DMARC authentication results.
After checking the message headers, validate the domain's published records. Suped's DMARC checker helps identify syntax errors, duplicate DMARC records, and policy tags that are easy to overlook. A missing rua reporting address prevents aggregate reports from being requested through that record, but does not itself cause authentication failure.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Connect the DNS result to the message result. If a mechanism requires strict alignment, a subdomain mismatch prevents that mechanism from supporting DMARC. DMARC still passes if the other mechanism passes with the required alignment. If SPF and DKIM both fail, fix those mechanisms before changing alignment mode.
How to fix Gmail sender authentication
Fix the cause shown in the headers or bounce. Changing unrelated DNS records can make the problem harder to reproduce, especially when multiple platforms send mail for the same domain.
|
|
|
|---|---|---|
DKIM pass, DMARC fail | Unaligned signer | Configure DKIM for an aligned domain |
SPF pass, DMARC fail | Unaligned return path | Use a custom bounce domain |
DMARC fail | No passing aligned mechanism | Fix DKIM or SPF authentication and alignment |
Strict mode with a domain mismatch | Exact match required | Configure exact domains or use relaxed mode |
DKIM fail | Bad selector, key, or modified message | Repair signing and retest |
SPF fail or permerror | Unauthorized IP, duplicate SPF records, or excess DNS lookups | Correct SPF for the envelope sender domain and retest |
Use the header evidence to pick the smallest useful fix.
For most sending setups, DKIM is the cleaner DMARC path because a valid signature can survive forwarding when the signed message content and headers remain unchanged. Configure each sending platform to sign with the From domain or an aligned domain. If the platform only signs with its own unrelated domain, enable custom DKIM for your domain. Gmail requires DKIM RSA keys of at least 1024 bits and recommends 2048 bits when supported. Avoid the DKIM body-length tag (l=).
SPF can also satisfy DMARC, but it depends on the envelope sender domain and usually breaks when mail is forwarded. Many platforms use their own bounce domain unless you configure a custom return path. If Gmail shows smtp.mailfrom as an unrelated domain, SPF does not provide DMARC alignment for your visible From domain. For SPF errors, keep one SPF record per domain and check the 10 DNS-lookup limit, including nested includes.
Check Gmail's sender requirements
- All senders: Mail to personal Gmail accounts must authenticate with SPF or DKIM.
- Bulk senders: Google classifies senders reaching roughly 5,000 messages in 24 hours to personal Gmail accounts as bulk senders, counting the same primary domain and its subdomains together. Bulk sender status is permanent. SPF and DKIM are required, plus DMARC with at least p=none.
- Direct bulk mail: The visible From domain must match the SPF domain or DKIM domain under DMARC alignment rules.
- Other requirements: Gmail also applies DNS, TLS, spam-rate, message-format, and applicable unsubscribe requirements. Marketing and subscribed bulk mail must support one-click unsubscribe and include a visible unsubscribe link in the message body.
A practical fix order
- Restore authentication: If SPF or DKIM fails, repair the sender's authorization or signing before testing DMARC.
- Fix DKIM alignment: Make the platform sign with a domain that aligns with the visible From domain under your DMARC mode.
- Fix SPF alignment when needed: Use a custom return path if SPF needs to satisfy DMARC for that mail stream.
- Review strict mode: Change adkim or aspf to relaxed only after confirming the mismatch caused the failure and exact matching is not an intentional control.
- Monitor reports: Use aggregate DMARC data to confirm the corrected source has an aligned pass across Gmail traffic. Aggregate reports do not show the banner displayed to an individual recipient.
Suped's DMARC monitoring groups aggregate results by sending source, shows whether SPF or DKIM produced an aligned pass, and keeps the evidence available while a policy change is tested. That workflow helps separate a one-message Gmail warning from a recurring sender configuration problem.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
When DMARC passes but Gmail still warns
Authentication is the first measurable check, but a DMARC pass does not guarantee inbox placement or remove every Gmail warning. After DMARC passes, use the exact banner text and message details to isolate the remaining signal.
- Lookalike domains: A domain that visually resembles another brand can trigger warnings even with valid authentication.
- Link mismatch: Login links, tracking domains, and redirect chains can look inconsistent with the sender identity.
- Limited sender history: A new domain or IP has little sending history. Review domain and IP reputation alongside recipient complaints.
- Forwarding path: SPF can fail after forwarding and DKIM can fail if signed content changes. If DMARC passes through another signature, Gmail still evaluates the remaining signals. A valid ARC chain is not a delivery guarantee.
If Gmail still shows a warning after DMARC passes, compare the case with Gmail phishing warnings. The next investigation then covers visible sender identity, link destinations, complaint patterns, and message consistency.
Infographic listing DMARC fail, strict match, broken DKIM, and risky links as Gmail alert causes.
Views from the trenches
Best practices
Check Gmail Show original before changing DNS so the fix matches the failed message.
Treat strict adkim and aspf as planned controls, not default settings for all senders.
Keep sender inventory current so each platform has a known DKIM and return path setup.
Common pitfalls
Assuming an SPF pass alone authenticates the visible From domain without DMARC alignment.
Publishing strict DMARC before vendors have custom DKIM on the exact sending domain.
Testing with public DNS only and missing the actual domains used by the sent message.
Expert tips
Use relaxed mode while onboarding senders, then tighten only after report data is clean.
Prefer an aligned DKIM signature when forwarding or mailing lists break SPF authentication.
Retest with a new message after DNS changes because old Gmail headers will not update.
Marketer view
Marketer from Email Geeks says an authenticated message can still trigger Gmail when the authenticated domain does not match the visible From domain for DMARC.
2024-08-09 - Email Geeks
Marketer view
Marketer from Email Geeks says the Authentication-Results header is the right evidence because it shows SPF, DKIM, and DMARC for the delivered message.
2024-08-09 - Email Geeks
Frequently asked questions
Yes. SPF and DKIM can pass for domains unrelated to the visible From domain, so DMARC fails. For forwarded mail, Gmail can also treat the message as unauthenticated when ARC records an earlier authentication failure. A DMARC pass still does not guarantee that Gmail removes every warning.
They enable strict alignment for their respective mechanisms. adkim=s requires the DKIM signing domain to exactly match the From domain. aspf=s does the same for the SPF envelope sender domain.
Use relaxed mode unless exact-domain alignment is an intentional control supported by every affected sender. Before changing strict mode, confirm that it caused the failure and that no aligned mechanism already passes.
On a computer, open the delivered message in Gmail, click the three-dot More menu beside Reply, and choose Show original. Review the authentication summary and Google's Authentication-Results header for the domains and results Gmail evaluated.
Yes. DMARC passes when DKIM passes and its signing domain has the required alignment with the visible From domain. SPF does not also need to pass. Gmail separately requires SPF authentication for direct bulk mail, even when DKIM satisfies DMARC.
No. A new-device, suspicious sign-in, password, or recovery alert concerns access to the Google Account. Open the account directly, review Recent security events, and secure it if the activity was not yours. SPF, DKIM, and DMARC changes do not secure a compromised account.
