Does the warning mean my email went to spam?

No. The message is in the inbox, with a band above it. Google is explicit that messages which are not authenticated are not necessarily spam. It is a statement about sender identity, not a spam verdict, although an unauthenticated domain does tend to get filtered harder over time.

I passed SPF but the warning is still there. Why?

Usually alignment. Google's sender guidelines require the organizational domain in the From header to match the organizational domain that SPF or DKIM authenticated. A platform that passes SPF for its own domain while your address shows yours leaves nothing aligned to the visible sender, so add DKIM signing with your own domain at that platform.

Can I stop Gmail showing the warning on mail I receive?

Partly, and only inside your own Google Workspace. The advanced phishing and malware protections in the Admin console control what happens to unauthenticated messages, with keeping them in the inbox with a warning as the default. External recipient warnings are a separate setting, on by default. Neither changes what other organizations see.

Gmail be careful with this message: 4 causes and the fix

Say a 14-person insurance brokerage emails a quote, and the client replies with a screenshot. Above the message, Gmail has placed a warning band: it cannot verify the mail really came from the brokerage. Nothing bounced. The quote arrived. But the client is asking whether the brokerage was hacked, and the broker is asking us whether to change DNS, change mail hosts, or both.

The band is not a spam verdict. It is a statement about identity: Gmail could not prove the message came from the domain shown in the From address. That is narrower than it looks, and for mail you control it is usually fixable the same afternoon.

What the warning is actually telling you

Gmail checks two proofs of identity on an incoming message. SPF asks whether the server that handed over the message is allowed to send for the domain. DKIM checks a cryptographic signature on the message against a public key published in the domain's DNS. If neither passes, Gmail treats the message as unauthenticated, and Google's help page is plain about how that looks: a question mark next to the sender's name means Gmail could not authenticate the message, so it does not know whether the mail really came from the apparent sender.

Two things follow from that. First, unauthenticated is not the same as spam. Google states that messages which are not authenticated are not necessarily spam, and notes that authentication often does not work for real organizations sending to large mailing lists. Second, the warning is about the domain in the From header, not about your subject line, your wording or your attachment. Rewriting the email will not remove it.

What we check first, and it is not DNS

Most people start by pasting their domain into a lookup tool. We start with the message that failed, because it names which check failed and against which domain. A DNS record alone cannot tell you that.

Ask the recipient to open the message in Gmail on a computer and choose Show original from the message menu. That gives the raw message with its headers. The line to read is Authentication-Results. Google's guidance is to look there for spf=pass or dkim=pass; the Gmail apps also show Mailed by and Signed by lines when authentication succeeds, which is quicker when you only need a yes or no.

That one header is worth an hour of guessing, because it names the domain each check ran against. Mismatches between it and the visible From address are where alignment problems live.

Match the header to the cause

With the Authentication-Results line in front of you, the work is mechanical. Find your row, change that one thing, then send another test.

What the headers show	What it means	What to change
`spf=none` and `dkim=none`	The domain publishes nothing Gmail can verify, so all its mail is unauthenticated	Publish an SPF record, then turn on DKIM signing at the service that sends the mail
`spf=fail` or `spf=softfail` with `dkim=none`	Something sends from an address the SPF record does not list, and nothing signs the message	Add that service to the SPF record and enable its DKIM signing
`spf=pass` for a domain that is not yours, `dkim=none`	SPF passed for the sending platform, not your From domain, so nothing aligns to the visible address	Enable DKIM for your domain at that platform and publish the key in your DNS
`dkim=fail` on mail that passed through a forwarder or a list	A signed header or the body was rewritten in transit, breaking the signature	Stop the rewriting, or have the mail delivered without the extra hop
`spf=pass` and `dkim=pass`, warning still shown	Authentication is fine. The band comes from the receiving organization's own Gmail configuration	Nothing in your DNS. The last two sections cover this case

Fix 1: one SPF record that lists everything sending for you

Google's instruction for SPF is short and still gets broken: the record for your domain should include every email sender for your domain. A brokerage usually has more senders than it remembers: Workspace, the policy system, the payment provider, a marketing tool, the contact form on the website. A sender left out of the record is a sender whose mail arrives unauthenticated.

A domain carries one SPF record, not several. Two v=spf1 records on the same name is a configuration error under RFC 7208, and it can make every check fail at once, so merge instead of adding a second line.

Type: TXT
Name: @
Value: v=spf1 include:_spf.google.com ~all

Add one mechanism per service, inside that single record. SPF also has a budget: ten DNS lookups while it is evaluated, and the eleventh turns the result into a permanent error. If your list of services is long, read the SPF lookup limit and how to get back under it before appending more includes.

Fix 2: DKIM at every service, not only at Workspace

SPF breaks easily in transit, so DKIM is the one worth getting right, and Google names it as the preferred way to authenticate. Each sending service generates a key, you publish the public half as a TXT record under a selector, and the service signs with the private half.

Type: TXT
Name: <selector>._domainkey
Value: v=DKIM1; k=rsa; p=<public key from the sending service>

Two details from Google's DKIM troubleshooting that we correct on client projects more often than we would like. Use a key of at least 1024 bits, with 2048 recommended, since 1024 is the floor Google states for mail to personal Gmail accounts. And do not use the DKIM length tag l=, since it leaves the message easier to spoof. The record format is defined in RFC 6376.

The usual gap is a platform signing with its own domain instead of yours: a valid DKIM signature that does nothing for the address your client sees. The rule in the Workspace SPF, DKIM and DMARC setup applies to third-party tools too, since the signature has to carry your domain.

Fix 3: DMARC, so the handling is your decision

SPF and DKIM let a receiver verify you. DMARC is how you tell receivers what to do when verification fails. Google describes it as publishing a policy that tells Gmail and other participating providers how to handle unauthenticated messages sent from your domain, and recommends moving from monitoring to quarantine to reject as confidence in the setup grows.

Type: TXT
Name: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Order matters. Google's setup guidance is to turn on SPF or DKIM first, allow 48 hours, and only then publish the DMARC record. Publishing a policy before authentication works turns a warning band into rejected mail.

DMARC also brings in alignment, the quiet reason many messages that pass SPF still look unauthenticated. Google's sender guidelines require the organizational domain in the From header to match the organizational domain that SPF or DKIM authenticated. Different domains mean a pass on paper and a failure in practice. Reports show this across every sender at once, and the staged rollout from p=none to p=reject is the safe way to act on them.

For volume senders the requirement is firmer. Google's guidelines ask every sender for SPF or DKIM, and ask bulk senders, meaning close to 5,000 messages or more to personal Gmail accounts in 24 hours, for all three, although the DMARC policy may be set to none.

When the warning is not your fault

Forwarding is the common case. Google's forwarding guidance says forwarded messages often fail SPF, because the check runs against the forwarding server, not the original. DKIM survives forwarding only if nothing changes the signed parts: Google lists modifying the subject and other protected headers, and software that modifies or re-encodes the body. Mailing lists that add a footer or a subject tag do exactly that.

There is a subtler one. Gmail uses ARC to read the authentication status a message had before it was forwarded. If a forwarded message passes SPF or DKIM on arrival but ARC shows it had already failed earlier in the path, Google says Gmail treats it as unauthenticated. A clean pass at the last hop is not the end of the story. Google also notes that DMARC alignment is not required for forwarded and mailing list messages, which it calls indirect mail. What forwarding does to SPF covers the options when the forwarding is yours to change.

When the warning comes from the recipient's own Workspace

This is the case nobody expects, and it ends a lot of pointless DNS work. A receiving organization can configure Gmail to add warnings itself. In the Admin console, under Apps, Google Workspace, Gmail, Safety, the advanced phishing and malware protections include an option for any unauthenticated message, and the administrator chooses whether to keep such a message in the inbox with a warning, which is the default, move it to spam, or quarantine it. Those banners appear in Gmail on the web.

A second, separate feature produces a band that looks similar. External recipient warnings, under Apps, Google Workspace, Gmail, End User Access, are on by default and add a warning plus colored markers next to addresses outside the organization, with contacts and directory members exempt. That one has nothing to do with authentication. If the headers show both checks passing, no DNS change removes the band; the answer is a conversation with the recipient's administrator.

What we watch for the two weeks after

Give DNS changes time, then test rather than assume. Send to a personal Gmail address, open Show original, and confirm the pass lines are there and name your domain. Watch the authentication and spam rate panels in Postmaster Tools, which is where a half-fixed sender shows up: one service aligned, another still unsigned. Google's guidelines also tell bulk senders to keep the user-reported spam rate low and never let it reach 0.3%. Setting up Postmaster Tools and reading it takes about ten minutes.

Then write down every service that sends as your domain, with its SPF mechanism and its DKIM selector. This warning comes back a year later because somebody connected a new tool without touching DNS.

How Guanacos Tech helps

Most of this work is reading, not configuration. The change is usually two DNS records, but knowing which two means reading the failed message, checking what each service really signs with, and separating your problem from the recipient's settings. We do that as email deliverability consulting for small business, for Workspace and Microsoft 365 domains alike. Book a 30-minute call and bring one message with full headers from someone who saw the warning; that is normally enough for us to name the failing check and the service behind it.

Gmail says be careful with this message: which check failed, and how to clear the warning