Why does Gmail say "Be careful with this message"?

Which setup method should I use?

Use the repair that matches the message evidence.

• If a marketing, CRM, billing, or transactional service sent the message, use that service's current domain-authentication workflow. It may supply account-generated DKIM records, a custom return-path domain, or SPF instructions.
• If the affected path is mailbox-hosted Google Workspace mail, inspect the Workspace authentication configuration and any outbound gateway.
• If direct mail passes but forwarded or relayed mail fails, investigate the forwarding service or gateway before changing the original sender's DNS.
• If Gmail warns that the message is a scam or appears to come from a compromised contact, follow Google's guidance for suspicious messages and verify the request outside the message.

How do I configure SPF and DKIM for Gmail deliveries?

1. Record the complete Gmail warning

Copy the sentence beneath the banner. Record the visible From address, Reply-To address, delivery time, recipient mailbox, and whether Gmail placed the message in Inbox or Spam.

If you are a recipient rather than the sending-domain operator, do not reply, open links, or download attachments while investigating a warning that indicates risk. Confirm sensitive requests through a known phone number, portal, or separate conversation.

2. Open Gmail's original-message view and collect the evidence

In Gmail on the web, open the affected message, select More beside Reply, then choose Show original. Google's instructions for viewing full message headers document this path.

Find the Authentication-Results field added by the receiving system you trust. RFC 8601 defines Authentication-Results syntax and its trust boundary. A sender can add similar-looking fields, so a sender-supplied line is not evidence of what Gmail evaluated.

Keep the warning text separate from the sending evidence.

• Gmail warning text: The complete sentence beneath the banner. It classifies the visible risk signal but does not identify a failed DNS record by itself.
• Visible From domain: The domain in the address the recipient sees, such as yourdomain.com.
• Trusted receiver Authentication-Results: The spf=, dkim=, and dmarc= results from Gmail or another receiver you trust.
• DKIM d= domain: The signing domain in DKIM-Signature.
• Return-path domain: The envelope-sender identity, often shown in Return-Path and as smtp.mailfrom=.
• Sending application: The mailbox platform, email service, CRM, billing system, or application that created the message.

Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=bounce.mailer.yourdomain.com;
  dkim=pass header.d=yourdomain.com header.s=selector1;
  dmarc=pass header.from=yourdomain.com

A passing SPF or DKIM result does not prove that the visible From domain passed DMARC, that every sender uses this path, or that Gmail will remove the warning from future messages. Read Palisade's guide to Gmail Authentication-Results before changing DNS based on one message.

3. Classify the authentication results

Compare each result with the identity it names.

• spf= with smtp.mailfrom= identifies the SPF result and envelope-sender domain.
• dkim= with header.d= identifies the DKIM result and signing domain.
• dmarc= with header.from= identifies Gmail's DMARC result for the visible From domain.
• arc= can add context when a forwarder or mailing list handled the message.

Treat the diagram as a routing aid, not as a substitute for the complete header. RFC 9989 defines DMARC alignment. An SPF pass for a provider-owned return-path domain can still leave DMARC failing when that domain does not align with header.from.

4. Publish records for the actual sending identity

For SPF failures, inspect the exact smtp.mailfrom identity. RFC 7208 defines SPF as authorization for the MAIL FROM identity or, in some cases, the HELO identity. Publish one SPF TXT policy at that domain and merge legitimate services into the existing policy. Do not add a second v=spf1 record.

Record type: TXT

Host (illustrative only):

mail.yourdomain.com

Value (illustrative only):

v=spf1 include:spf.example-sender.invalid -all

Do not publish this example. Copy the full SPF mechanisms from the service that sent the affected message. DNS providers that append the zone name can create mail.yourdomain.com.yourdomain.com when a full name is pasted into a host field.

For a DKIM failure or missing signature, open the sending service that produced the message and retrieve its current domain-authentication records. RFC 6376 defines DKIM selectors and public-key records. The vendor generates the real selector, CNAME target, or TXT value for its account. Do not copy one from another tenant or an online example.

5. Verify in the sending service and send a new message

Return to the service that sent the warning-triggering message and wait for its domain-authentication status to show the published records are accepted. Then send a new message through the same production application, return path, gateway, and visible From domain.

A green vendor indicator proves that the service accepted its current DNS configuration. It does not prove Gmail's treatment of a delivered message, that another application is configured, or that the next message will have the same route.

How does this setup affect DMARC?

DMARC passes when SPF or DKIM passes and aligns with the visible From domain. SPF alignment compares the authenticated envelope sender with the From domain. DKIM alignment compares the d= signing domain with the From domain. A valid signature for an unrelated provider domain can still fail DMARC alignment.

Use Palisade's DMARC checker to inspect the published DMARC policy before changing enforcement. A public record check cannot show which application sent the affected message, Gmail's private safety decision, or future message placement.

If the message comes from a third-party sender, ask whether it supports a custom return path or DKIM signing with your domain. If it does not, its mail may pass SPF or DKIM for its own domain while failing alignment with your visible From domain. Palisade's Gmail authentication setup guide covers the wider sender requirements and deployment sequence.

How do I validate the setup?

Check public DNS

Query the exact SPF, DKIM selector, or DMARC owner identified by the message. Compare the authoritative DNS answer with at least one public resolver.

dig +short TXT yourdomain.com
dig +short TXT selector1._domainkey.yourdomain.com
dig +short TXT _dmarc.yourdomain.com

Keep the exact owner names from the affected path. A DNS provider's host-field suffix behavior can create duplicated names even when the entry appears plausible in its console.

Check the vendor or sending-service state

Confirm that the sending service accepts the configured domain, DKIM selector, and any required return-path setup. Record the selected account and domain. This is the vendor-side check for the path that created the message.

Inspect a newly delivered Gmail message

Open Show original for a new message sent after the repair. Confirm the expected smtp.mailfrom, header.d, selector, and header.from values. Check that the required SPF or DKIM result passes and aligns with the visible From domain when it is expected to satisfy DMARC.

Verify Gmail's warning state

Send another fresh production message to a Gmail mailbox and compare its banner text with the original warning. Gmail does not document a public rule that guarantees a particular banner disappears after an authentication repair. The comparison can show whether Gmail still presents the same sender-verification warning on the repaired path. It does not prove Gmail's future classification decisions.

Review DMARC aggregate data

After reports accumulate, review whether the repaired sending source passes SPF or DKIM and aligns with the From domain. Palisade can analyze DMARC aggregate-report data, identify sending sources and authentication or alignment issues, and create prioritized remediation tickets. A human reviews the evidence and applies any DNS or DMARC policy change.

Troubleshooting

Gmail shows no SPF or DKIM pass

Check which identity failed before editing DNS. SPF must authorize the smtp.mailfrom or relevant HELO identity. DKIM requires a valid signature and the public key at the selector's DNS owner. Confirm that the sending service is actually using the domain whose records you changed.

SPF passes but DMARC fails

Compare smtp.mailfrom with header.from. The SPF domain may belong to the sender's shared infrastructure rather than your visible From domain. Configure an aligned custom return path if the sender supports it, or use aligned DKIM signing.

DKIM passes but DMARC fails

Compare header.d with header.from. A DKIM pass from an unrelated domain does not meet DMARC alignment. Configure the service to sign with an aligned domain or investigate why the intended signing domain is absent.

Direct mail passes but forwarded mail shows the warning

Google's forwarding guidance explains that forwarding can affect SPF and recommends preserving authentication evidence. Compare a direct message with the forwarded message. Check the forwarding service's ARC handling and its configuration before modifying the original sender's DNS.

Gmail's warning describes phishing or a compromised contact

Do not treat this as an SPF or DKIM repair. Google's guidance tells recipients to avoid responding to suspicious messages and to verify a request outside the message. If account compromise is confirmed, follow Google's account security recovery steps for the affected account.

Only one application triggers the warning

Inventory the sender that created the message. A domain can have working Google Workspace authentication while a marketing platform, CRM, billing tool, or application uses a different return path or DKIM domain. Repair and retest the one application before assuming the whole domain is fixed.

Keep the sender inventory after the one-message repair

Use Palisade's email security score to inspect the domain's public authentication posture after you correct the affected sender. Compare that result with the new message headers and the sending service's status.

A public check cannot prove why Gmail warned on one message, monitor all production sending paths, or control Gmail's safety banners. For the ongoing gap after a single repair, Palisade is agentic DMARC software that analyzes aggregate-report data, identifies sending sources and alignment issues, and proposes the next policy step for human review.

Start with Palisade