Fix: “This sender has failed our fraud detection checks”

When opening an inbound message in Gmail, you may encounter an aggressive red or yellow warning banner declaring: “This sender has failed our fraud detection checks and may not be who they appear to be.” This banner signals that Google’s mail transfer agent (MTA) detected a direct contradiction between the sender identity displayed in the message header and the technical verification records of the sending server.

Quick Answer

Gmail shows this warning when an email fails domain authentication checks—specifically SPF hard fails, missing or broken DKIM signatures, or DMARC alignment failures where the “From” address does not match the authenticated sending domain. If you sent the email, verify your SPF, DKIM, and DMARC DNS records. If you received it, treat links and attachments as hostile.

---

What the Warning Means

Every email contains two sender identities:

1. The Envelope Sender (Return-Path or RFC 5321): The address used by mail servers to route delivery notifications and bounces.
2. The Header Sender (From or RFC 5322): The display address visible to the end user in their email client.

The “failed our fraud detection checks” alert triggers when Google’s anti-abuse filter detects that the server delivering the email has no cryptographic or IP-level authority to claim the domain shown in the RFC 5322 From field. Google flags the message as an impersonation attempt (spoofing), an unauthorized relay, or a severe authentication misconfiguration.

---

Technical Causes of the Warning

If this alert appears on legitimate business communications, the breakdown typically stems from one of four technical flaws:

1. DMARC Alignment Failure (p=reject or p=quarantine Missing/Bypassed)

DMARC requires that the domain in the user-visible From header matches the domain authenticated by SPF (Envelope Return-Path) or DKIM (d= domain in the cryptographic signature). If you send through a third-party service (such as Zendesk, Mailchimp, or Shopify) using your own corporate address in the From field, but without delegating DKIM or SPF to that provider, alignment fails.

2. SPF Hardfail (all)

If the sending IP is not explicitly authorized in the domain’s SPF TXT record, and the record terminates with a hard fail mechanism (-all), Google marks the SPF check as fail. When combined with a missing or unaligned DKIM signature, the message immediately triggers the fraud warning banner.

3. Forwarding and Intermediary Alterations

If a message passes through an automated forwarding rule, an on-premises security gateway, or a mailing list, the intermediary server often modifies email headers or alters the message body (such as appending a corporate footer or disclaimer). Alterations invalidate the cryptographic hash inside the DKIM signature (dkim=fail (body hash did not verify)). Because the forwarding server’s IP is not in the original sender’s SPF record, both authentication layers fail simultaneously.

4. Display Name Spoofing and Internal Domain Impersonation

Google applies strict internal heuristic matching for Google Workspace tenants. If an external email arrives with a From display name matching an internal executive or user within your Workspace domain, but originates from an external server (or a public service like @gmail.com), the fraud detection system triggers the red banner to defend against business email compromise (BEC).

---

Diagnostic Triage: Reading the Raw Headers

To isolate why Google flagged the message, analyze the raw email headers:

1. Open the affected message in Gmail.
2. Click the three vertical dots (More) next to the Reply button.
3. Select Show original.
4. In the top summary table, evaluate the initial audit results:

Header Check	Expected Value	Warning-Trigger Value
SPF	PASS with IP...	FAIL or SOFTFAIL
DKIM	PASS with domain...	FAIL or NONE
DMARC	PASS	FAIL (p=NONE/QUARANTINE/REJECT)

Scroll down to the raw text and inspect the Authentication-Results header:

Authentication-Results: mx.google.com;
       dkim=fail header.i=@example.com header.s=google header.b=...;
       spf=fail (google.com: domain of sender@badrelay.com does not designate 198.51.100.24 as permitted sender) smtp.mailfrom=sender@badrelay.com;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=example.com

• If spf=fail, review the sending IP against the domain’s DNS SPF record. For a deep dive on resolving SPF syntax problems, see How to Fix Gmail Error 550 5.7.26: SPF Missing/Invalid.
• If dkim=fail, check whether an outbound gateway, security scanner, or content filter modified the message body during transit.

---

Step-by-Step Resolution

If You Are the Sender

1. Configure Custom DKIM: Never rely solely on SPF. Generate a 2048-bit DKIM key inside your email provider or Google Admin Console and publish the TXT record in your public DNS. Cryptographic signatures survive IP routing changes, preventing forwarding failures.
2. Align Third-Party Sending Services: When using services like Salesforce, HubSpot, or SendGrid, set up a dedicated sub-domain or configure custom reverse DNS (PTR) and DKIM keys within the vendor platform so the d= tag matches your root or subdomain.
3. Verify DMARC Compliance: Ensure your DMARC record at _dmarc.yourdomain.com is publishing a valid policy:
   For step-by-step enforcement strategies, consult How to Resolve DMARC Policy Rejects: Reject vs. Quarantine. v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=100;

If You Are the Workspace Administrator (Inbound Mail)

1. Configuring Inbound Gateways: If your organization routes email through an email gateway (like Mimecast, Proofpoint, or Barracuda) before delivering to Google Workspace, you must define those IP addresses under Admin Console > Apps > Google Workspace > Gmail > Inbound gateway. Failing to define the gateway causes Google to evaluate SPF against the gateway’s IP rather than the original sender’s IP. Learn how to configure these under “Inbound Gateway” SPF Overrides.
2. Review Content Compliance Rules: Ensure that inbound content manipulation rules (such as prepending subject lines with [EXTERNAL]) are handled via Workspace compliance settings rather than third-party boundary appliances that break DKIM body hashes.