Why Gmail Says Your Emails "Appear Suspicious" (And How to Fix It)

You've set up your Shopify store, connected your email platform, and started sending order confirmations and campaigns. Then a customer sends you a screenshot:

"This message seems dangerous. We can't verify that this email came from the sender, so it might not be safe to respond to it."

A big yellow warning banner. On your legitimate email. The one confirming the order they just placed with their credit card.

Nothing kills customer trust faster. And it's almost always caused by three misconfigured DNS records.

Why Gmail Flags Your Emails

Gmail doesn't just check what your email says — it checks who is actually sending it. Behind every email are two addresses:

• The "From" address your customer sees: [email protected]
• The "Return-Path" address your email service uses behind the scenes: [email protected]

When these two don't match up properly, Gmail can't verify the email is really from you. So it shows that warning banner — even though the email is completely legitimate.

The fix comes down to three DNS records: SPF, DKIM, and DMARC. If any one of them is missing or misconfigured, you're in trouble.

The Three Records You Need to Get Right

SPF — Who's Allowed to Send for You

SPF (Sender Policy Framework) is a DNS record that tells email providers which servers are authorized to send email from your domain. Think of it as a guest list — if a server isn't on the list, it shouldn't be sending emails on your behalf.

Common mistakes:

• Missing your email service from the SPF record. If you send through Segmentflow (which uses Amazon SES) but your SPF record only includes Google Workspace, your campaign emails fail authentication.
• Using -all instead of ~all. The -all flag tells providers to hard-reject anything not on the list. That sounds secure, but it's aggressive — if anything is slightly misconfigured, emails get rejected entirely instead of just flagged. Use ~all (soft fail) instead.
• Forgetting to update after switching providers. Moved from Mailchimp to Segmentflow? Your SPF record still says include:servers.mcsv.net. Old entries don't hurt, but missing the new one does.

What a correct SPF record looks like:

Google Workspace + Segmentflow:

v=spf1 include:_spf.google.com include:amazonses.com ~all

Microsoft 365 + Segmentflow:

v=spf1 include:spf.protection.outlook.com include:amazonses.com ~all

Just Segmentflow:

v=spf1 include:amazonses.com ~all

Your SPF record goes on your root domain as a TXT record. You can only have one SPF record per domain — if you need multiple include: entries, they all go in the same record.

DKIM — Proving the Email Wasn't Tampered With

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every email you send. The receiving server checks this signature against a public key in your DNS to verify two things: the email actually came from your domain, and nobody modified it in transit.

Common mistakes:

• Never setting up DKIM at all. Some email services send without DKIM by default. The emails still arrive, but they're missing a key trust signal.
• Leaving old DKIM keys from previous providers. If you switched from SendGrid to Segmentflow but still have SendGrid's DKIM keys in your DNS, it won't break anything — but it's messy and can cause confusion during debugging.
• Setting up DKIM on a subdomain but not the root domain. If your DMARC policy checks for strict alignment, the DKIM domain must match the From address exactly.

How to set it up:

When you connect your domain in Segmentflow, you'll get DKIM records to add to your DNS. They look something like this:

Type: CNAME
Name: segmentflow._domainkey.yourstore.com
Value: (provided during domain setup)

Add the records your email service gives you, verify them in your provider's dashboard, and you're done. This is a one-time setup.

DMARC — The Policy That Ties It Together

DMARC (Domain-based Message Authentication, Reporting and Conformance) tells email providers what to do when SPF or DKIM checks fail. It also introduces the concept of alignment — whether the domains in your authentication records actually match your From address.

This is where most "suspicious email" problems live.

The critical setting: strict vs. relaxed alignment

DMARC alignment has two modes:

• Strict (s) — the domain must match exactly. If your From address is [email protected] but the Return-Path is [email protected], strict alignment fails. The subdomain mail.yourstore.com doesn't exactly match yourstore.com.
• Relaxed (r) — subdomains are allowed. mail.yourstore.com is considered a match for yourstore.com. This is what you want in almost every case.

The most common cause of the Gmail warning: Your DMARC record has adkim=s (strict DKIM alignment) or aspf=s (strict SPF alignment) when it should be adkim=r and aspf=r.

What a correct DMARC record looks like:

Start with monitoring mode while you verify everything works:

v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r

Once you've confirmed emails are passing authentication, tighten the policy:

v=DMARC1; p=quarantine; rua=mailto:[email protected]; adkim=r; aspf=r; pct=100

Key parameters:

| Parameter | What it does | Recommended value | |-----------|-------------|-------------------| | p | Policy for failures | none (testing) → quarantine (production) | | adkim | DKIM alignment mode | r (relaxed) | | aspf | SPF alignment mode | r (relaxed) | | rua | Where to send reports | Your email for DMARC reports | | pct | Percentage of emails to apply policy to | 100 |

Your DMARC record goes on _dmarc.yourstore.com as a TXT record. You can only have one DMARC record — having two will cause both to be ignored.

How to Check If You're Affected Right Now

You don't need to wait for customer complaints. Here's how to diagnose the issue in five minutes.

Step 1: Send Yourself a Test Email

Send a test campaign or transactional email to your personal Gmail account through your email platform. Don't use "send as" from Gmail — the email needs to go through your actual sending infrastructure.

Step 2: Check the Email Headers

In Gmail, open the email, click the three dots in the top right, and select "Show original." You'll see a page with three key results:

SPF:    PASS
DKIM:   PASS
DMARC:  PASS

If any of these say FAIL or SOFTFAIL, that's your problem. The header details below will tell you exactly which domain was checked and why it failed.

Step 3: Verify Your DNS Records

Use a tool like MXToolbox to check each record:

• SPF check: Enter your domain and verify your email service is listed
• DKIM check: Look up your DKIM selector (e.g., segmentflow._domainkey.yourstore.com)
• DMARC check: Verify you have exactly one DMARC record with relaxed alignment

Step 4: Review DMARC Reports

If you have rua=mailto: set in your DMARC record, you'll receive XML reports from email providers. These reports show exactly which emails passed and failed authentication, and why. Services like DMARC Analyzer can make these reports human-readable.

The Three Changes That Fix 90% of Cases

If you're seeing the "suspicious" warning, make these changes to your DNS:

1. Set DMARC alignment to relaxed

Change adkim=s; aspf=s to adkim=r; aspf=r in your DMARC record. If your DMARC record doesn't specify adkim or aspf, add them — the default behavior varies by provider.

2. Add your email service to your SPF record

Make sure your SPF record includes the include: directive for every service that sends email on your behalf. For Segmentflow, that means include:amazonses.com.

3. Change SPF hard fail to soft fail

Replace -all with ~all at the end of your SPF record. This prevents legitimate emails from being outright rejected due to minor configuration issues.

After making these changes, wait 24-48 hours for DNS propagation, then send another test email and re-check the headers.

Quick Checklist

Before you close this tab, verify:

• [ ] Your email service is included in your root domain's SPF record
• [ ] Your SPF record ends with ~all, not -all
• [ ] DKIM keys from your current email service are in your DNS
• [ ] You have exactly one DMARC record (not zero, not two)
• [ ] Your DMARC record uses relaxed alignment (adkim=r; aspf=r)
• [ ] A test email shows SPF, DKIM, and DMARC all passing in Gmail headers

Why This Matters More in 2026

Gmail and Yahoo rolled out stricter authentication requirements in 2024, and enforcement has only tightened since. Configurations that worked fine for years — missing DMARC records, implicit alignment settings, no DKIM — now trigger warnings or land emails directly in spam.

For e-commerce stores, this is especially high-stakes. Your transactional emails — order confirmations, shipping updates, password resets — are the emails customers need to receive. A "suspicious" warning on a password reset email doesn't just hurt trust. It makes your customer think their account was compromised.

Get your authentication right once, check it quarterly, and you won't have to think about it again.

---

Segmentflow walks you through domain authentication during setup — SPF, DKIM, and DMARC configured correctly from day one. Get started for free with 5,000 emails per month, no credit card required.