Why does Gmail say it cannot verify my authenticated email?
Published 26 Jun 2025
Updated 19 Oct 2026
13 min read
Summarize with
Updated on 19 Oct 2026: We clarified Gmail's authentication errors and added Google's upcoming changes to third-party Send as and POP support.
Gmail says it cannot verify an email when its checks cannot establish the sender's identity for that delivered copy. Publishing SPF, DKIM, and DMARC records does not guarantee that every message passes. The actual message can use an unauthorized sending IP, carry a broken DKIM signature, or authenticate a domain that does not match the visible From address. Forwarding can also break SPF or alter DKIM-signed content. This sender warning is separate from Google's account recovery message that it cannot verify an account belongs to you.
Start with Gmail's Show original view, then compare the visible From domain, Return-Path, DKIM signing domain, the Authentication-Results header added by mx.google.com, and any ARC headers. Google's own Gmail authentication page explains where Gmail exposes those results. For evidence across normal traffic, Suped's DMARC monitoring maps sending sources and alignment failures that one header sample cannot show.
Why the warning appears
Direct answer
A question mark beside the sender means Gmail treated that message as unauthenticated. Check the exact delivered copy. A DNS checker can confirm that records exist, but it cannot prove which server sent the message, whether the DKIM signature survived, or whether a passing domain is aligned with the visible From address.
Gmail can authenticate a message with SPF or DKIM, while DMARC adds an alignment test against the visible From domain. A raw spf=pass or dkim=pass result can therefore be misleading when it belongs to another domain. That mismatch can explain DMARC failure, but it does not by itself establish why Gmail displayed the question mark. Reputation affects inbox placement, spam filtering, rate limits, and rejection, but it does not turn an otherwise authenticated message into the question-mark warning.
- SPF identity: SPF can pass for the Return-Path domain while the visible From domain remains unaligned.
- DKIM identity: DKIM can pass for a relay's signing domain without authenticating the visible From domain under DMARC.
- Broken signature: A footer, subject change, re-encoding step, or other modification can invalidate DKIM after sending.
- Forwarding: A forwarder changes the connecting IP, which normally breaks SPF for the original envelope sender.
- ARC result: Gmail can treat forwarded mail as unauthenticated when ARC records an earlier authentication failure.
What Show original should say
Open the warned message in Gmail, choose More (the three-dot menu beside Reply), then Show original, and read the Authentication-Results block written by mx.google.com before changing DNS. Ignore an identically named header added by an earlier relay. To check the published policy, use Suped's DMARC checker. For a broader DNS scan across SPF, DKIM, and DMARC, run a domain health check after inspecting the real Gmail headers.
For a quick check, expand the details beneath the sender's name. Gmail's authentication guidance identifies the "Mailed by" and "Signed by" fields as authentication clues. Compare those domains with the visible From address, then use Show original for the full results. A TLS or encryption indicator describes the connection, not SPF, DKIM, or DMARC success.
Header lines to inspecttext
Authentication-Results: mx.google.com; dkim=pass header.i=@example.com header.s=selector1; 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;
|
|
|
|---|---|---|
spf=pass | Envelope domain passed | Compare domains |
dkim=pass | Signature validated | Check d= domain |
dmarc=pass | An aligned method passed | Confirm exact copy |
arc=fail | ARC chain validation failed | Inspect ARC seals and chain |
Use Gmail's headers to separate a protocol result from aligned authentication.
For direct mail, the server handing the message to Gmail should match the source you intended to use. At least SPF or DKIM must pass Gmail's authentication check. For DMARC to pass, the successful SPF domain or DKIM d= domain must match the visible From domain under DMARC rules. If Gmail's own result says dmarc=pass on the exact warned copy, check the message's security details and ARC chain before assuming a DNS failure.
Under DMARC's alignment rules, relaxed alignment uses the same organizational domain, so a DKIM signature with d=mail.example.com can authenticate a From address at example.com. Strict alignment requires identical domains. Check adkim and aspf in the DMARC policy; both default to relaxed alignment.
When valid DNS records still produce authentication errors
A record that resolves now does not prove Gmail could use it when the message arrived. Inspect the method and error text in Gmail's Authentication-Results header before changing an SPF authorization or replacing a DKIM key. RFC 8601 defines authentication result codes.
|
|
|
|---|---|---|
spf=none | No usable SPF policy for the evaluated domain | Query the smtp.mailfrom domain, which can differ from the visible From domain. |
spf=permerror | Invalid SPF syntax, duplicate SPF records, or excessive DNS lookups | Publish one v=spf1 record per evaluated name and stay within the ten DNS-querying-term limit, including nested includes. |
spf=temperror or dkim=temperror | A temporary verification error, often a DNS timeout or SERVFAIL | Check DNS service health and resend after the error is resolved. |
dkim=none or a missing-key error | No signature, or no usable key at the signed selector | Enable signing if absent. Otherwise query s._domainkey.d using the actual s= and d= values in the signature. |
Match the repair to Gmail's recorded error rather than the current status of an unrelated DNS name.
The SPF specification requires a single SPF record at the evaluated name and limits DNS-querying mechanisms and modifiers. DKIM's key lookup rules use the selector and signing domain together: s=selector1 and d=example.com point to selector1._domainkey.example.com. A valid key at another selector does not validate that signature.
After a DNS change, allow cached answers to expire according to their TTL, then send a new message. Previously delivered messages retain their original Authentication-Results, so reopening an old message does not verify the repair.
Where Gmail Send mail as fails
Gmail Send mail as authentication flow through a third-party SMTP relay.
An existing Gmail Send mail as setup can work for a custom domain when Gmail submits through the address's authenticated SMTP server. The route itself is not the problem. Verification fails when the final relay is absent from SPF, does not add a valid DKIM signature, signs with a non-aligned domain, or changes the message after an earlier DKIM signature was added. Google will end third-party Send as support in January 2027; the configuration steps below apply while that setup remains available.
Authenticated path
Gmail submits to the custom address's SMTP server, and that server authenticates the visible sender.
- Submission: Gmail uses the SMTP host and credentials for the custom address.
- SPF: The final sending IP is authorized for the envelope sender domain.
- DKIM: The final server signs with a domain aligned to the visible From address.
Unauthenticated path
Gmail shows the custom From address, but the final SMTP relay does not authenticate that identity.
- Submission: The configured SMTP host is wrong or uses another sending route.
- SPF: The relay IP is unauthorized or authenticates an unaligned Return-Path.
- DKIM: The relay omits DKIM, breaks the signature, or signs for another domain.
The same address can pass through one client and fail through Gmail Send mail as when the two clients submit to different SMTP hosts or trigger different signing rules. Compare the final Received hop, smtp.mailfrom value, and DKIM d= domain on both test messages. The Message-ID showing Gmail as the composer does not decide SPF, DKIM, or DMARC.
How forwarding and ARC affect verification
Forwarding is the main exception to a simple direct-mail diagnosis. The forwarder becomes the server connecting to Gmail, so SPF for the original envelope sender usually fails. DKIM can preserve authentication across the forward only when the forwarder leaves the signed body and protected headers unchanged. Mailing lists often add subject tags or footers that break DKIM.
- Check ARC: Read ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal together.
- Preserve DKIM: Avoid changing signed headers, MIME boundaries, encoding, subjects, and message bodies.
- Rewrite safely: A forwarder can use the Sender Rewriting Scheme (SRS) to rewrite the envelope sender so its own SPF check passes. That does not restore SPF alignment with the original visible From domain.
- Retest direct: Send the same message without the forwarder to confirm whether forwarding caused the failure.
ARC records the authentication state seen by intermediaries, but ARC does not make a failed message pass automatically. Google states that if a forwarded message passes SPF or DKIM at Gmail while ARC shows that it failed earlier authentication, Gmail treats the message as unauthenticated. Repair the original sender or forwarding chain instead of adding every forwarder to the original domain's SPF record.
How to fix Gmail's verification warning
Fix the result shown on the warned message before changing enforcement. Work through these checks in order so each change addresses a measured failure.
- Reproduce it: Send a fresh message through the affected route and inspect that exact delivered copy.
- Trust Gmail's result: Use the Authentication-Results header added by mx.google.com, not an upstream copy.
- Check alignment: Compare the visible From domain with smtp.mailfrom and the DKIM d= signing domain.
- Repair SPF: Authorize the final sending source and keep the evaluation within SPF's ten DNS-querying-term limit, including nested includes.
- Repair DKIM: Sign on the final outbound server after content changes, with an aligned domain and a valid selector. Do not add the l= body-length tag as a workaround for modified messages.
- Use secure SMTP: Submit with the mailbox's authenticated SMTP settings and TLS. SMTP login authenticates the submitting client; it does not replace SPF or DKIM at Gmail.
- Monitor reports: Collect DMARC aggregate reports to find the same failure across normal traffic.
For mail sent to personal Gmail accounts, Google's sender requirements require SPF or DKIM for all senders. Bulk senders must use SPF, DKIM, and DMARC, with the From domain aligned to SPF or DKIM for direct mail. Gmail requires DKIM keys of at least 1024 bits and recommends 2048-bit keys when supported. Google's bulk sender definition is close to 5,000 messages or more within 24 hours, counted across the same primary domain and its subdomains. Once classified as a bulk sender, that status does not expire.
Do not tighten DMARC first
Moving straight to p=reject does not repair SPF, DKIM, alignment, or forwarding. It requests rejection of messages that still fail DMARC, subject to receiver policy. Suped's Hosted DMARC can stage policy changes without repeated DNS edits.
Monitoring DMARC recordtext
v=DMARC1; p=none; rua=mailto:dmarc@example.com
That example requests aggregate reports while you identify legitimate sources; replace dmarc@example.com with a reporting mailbox you control. It does not fix the warned message by itself. A reporting address at another domain generally needs external reporting authorization. Keep an existing enforcement policy unless a deliberate policy change is warranted. After the affected route passes consistently and reports show stable aligned traffic, assess forwarding and mailing-list use before moving to quarantine or reject.
Tests that isolate the cause
A small test matrix separates the composing client, SMTP server, forwarder, and DNS behavior. Keep the subject and body simple, and send each test to the same Gmail recipient so the headers remain comparable.
Send one message through an existing Gmail Send mail as setup, one through a phone or desktop client using the same SMTP details, and one directly from the domain's webmail. If forwarding is involved, add a direct-to-Gmail test that bypasses it. Compare mx.google.com's Authentication-Results, the last external Received hop, Return-Path, DKIM d= domain, and ARC results.
If the message was fetched into Gmail from another mailbox through POP rather than delivered directly to Gmail, test delivery to an @gmail.com recipient separately. Google's POP transition guidance says new users can no longer configure third-party POP fetching after the first quarter of 2026, while existing users can continue until January 2027. Forwarding is a different route and needs its own authentication test.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
After sending a real message to the tester address, confirm that the final outbound server matches the expected source. If the result shows another IP, a non-aligned DKIM domain, an unexpected envelope sender, or a modified body, fix that sending path before editing the public DMARC policy. Suped's test is a separate delivery, so use the warned Gmail copy to confirm Gmail's verdict.
Check reputation only after the exact message authenticates. A shared outbound IP, weak reverse DNS, or a blocklist (blacklist) listing can affect spam placement and delivery, but those signals do not explain Gmail's unauthenticated question mark when SPF or DKIM has not passed.
Email tester sample report showing total score, email preview, issue summary, and per-section results
Suped's email tester ties the diagnosis to one real message. Suped is our DMARC and email authentication platform, and its aggregate reporting workflow then shows whether the same source, alignment failure, or signing change recurs across normal traffic.
Authentication and placement are separate
SPF, DKIM, and DMARC answer identity questions. Reputation, complaint rates, message content, and sending patterns affect whether authenticated mail reaches the inbox, spam, or a rejection. If Gmail's own header shows aligned authentication passing but the message lands in spam, investigate placement. If Gmail shows the question mark, investigate authentication and ARC first.
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.
Use Suped's aggregate reports to map sending sources, identify recurring alignment failures, and track changes after the single-message test is clean. Server identity and blocklist or blacklist monitoring remain separate delivery checks.
What good looks like
- Authentication: Gmail's own header shows SPF or DKIM passing.
- Alignment: DMARC passes through a domain aligned with the visible From address.
- Route: The final outbound server is the source you intended to use.
- Reports: DMARC aggregate data shows the same source passing across normal mail volume.
Review an existing Gmail Send mail as setup
For an existing custom-domain setup, review the SMTP server, username, and password under Gmail settings, Accounts and Import, then Send mail as. Google's Send as guidance explains the current configuration steps.
Google's third-party account support notice says third-party Send as support ends in January 2027, with new configurations restricted during the transition. Google-hosted Gmail addresses and Google Workspace Send as identities are excluded. If your custom domain is hosted elsewhere, plan to send through that mailbox's own interface or a mail client connected directly to its SMTP server.
Gmail Send mail as settings for authenticated custom-domain SMTP.
- Open settings: Go to Gmail settings, then Accounts and Import.
- Edit sender: Find the custom address under Send mail as and confirm the SMTP host and username.
- Use TLS: Use the provider's authenticated TLS setting, commonly port 587 or 465.
- Send test: Send to Gmail, open Show original, and compare it with a direct SMTP client test.
If the direct client test passes and the Gmail Send mail as test fails, compare the SMTP host, authenticated username, Return-Path, final sending IP, and DKIM signer. Different credentials can select another outbound route or signing rule. Correct that configuration while it remains supported, use the domain mailbox directly, or move the mailbox to Google Workspace.
Frequently asked questions
Not normally on the exact delivered copy. Google says a question mark means Gmail treated the message as unauthenticated. Confirm that you are reading the Authentication-Results header added by mx.google.com, then inspect ARC and Gmail's security details if dmarc=pass appears there. A passing result at another receiver or a successful DNS check does not establish what happened at Gmail.
No. A p=none policy requests no DMARC-specific quarantine or rejection. The message still needs SPF or DKIM authentication, and DMARC still checks whether a passing domain is aligned with the visible From address. Aggregate reporting requires a valid rua address.
An existing Send mail as setup works when the correct SMTP server produces passing, aligned authentication. Google is ending third-party Send as support in January 2027, so plan another sending route for externally hosted domain mail. Google Workspace identities are excluded. Google's support notice explains the scope.
Check the Authentication-Results header added by mx.google.com first. Then compare the visible From domain with smtp.mailfrom and the DKIM d= domain, followed by Received and ARC headers.
No. A dedicated IP can change reputation and placement, but it does not repair missing SPF authorization, a broken DKIM signature, DMARC misalignment, or a failed ARC chain.
