Why does Gmail mark emails from new domains as spam?
Published 7 Aug 2025
Updated 23 Oct 2026
12 min read
Summarize with
Updated on 23 Oct 2026: We clarified Gmail's bulk-sender rules, current Postmaster Tools checks, and list-quality steps for warming a new domain.
Emails from new domains can land in Gmail's spam folder because the domain has little or no sending history, the sending infrastructure has its own history, authentication is missing or does not match the visible sender, or recipients report the mail as unwanted. A domain that is new to its current owner can also have older abuse history.
Google's own Gmail troubleshooting page tells admins to authenticate mail, mark good mail as not spam, and understand that suspicious messages can still go to spam even with an allowlist. That is the right starting point: fix identity first, then prove consistent wanted sending over time.
For mail to personal Gmail accounts, Google requires SPF or DKIM, valid forward and reverse DNS, TLS, RFC 5322 formatting, and a Postmaster Tools spam rate below 0.30%. Bulk senders must use SPF, DKIM, and DMARC, make the visible From domain match a successful SPF or DKIM identity under DMARC's matching rules, and support one-click unsubscribe for marketing and subscribed mail. Google recommends keeping the spam rate below 0.10% and never reaching 0.30%. See Gmail sender requirements.
Google counts about 5,000 messages or more to personal Gmail accounts within 24 hours across the same primary domain and its subdomains. Bulk-sender status is permanent once assigned. Google increased enforcement in November 2025, including temporary and permanent rejections for noncompliant traffic. See Google's sender guidelines FAQ.
The direct answer
If the sending domain has no history at Gmail, Gmail has little evidence that recipients want the mail. Early sends need consistent authentication and a small audience that expects the messages.
- Registration age alone does not determine placement. Gmail has less evidence when an authenticated domain has little or no sending history.
- A successful SPF or DKIM identity must match the visible From domain under DMARC's relaxed or strict rules.
- The sending IP and domains used in authentication or tracking can have an existing reputation, even on the first send from a new visible From domain.
- Genuine not-spam actions and trusted contact entries can improve placement for that recipient. Low complaint rates support a healthier sending reputation.
Why new domains land in Gmail spam
A newly used sending domain gives Gmail little history to assess. Authentication, infrastructure reputation, and recipient feedback help explain why first messages land in spam. Check these five areas before changing DNS.
- A domain's first Gmail message has no established Gmail sending history.
- A domain that looks new to you can have previous registration history, expired ownership, or old abuse signals.
- Gmail scores more than the visible From domain. IPs, bounce domains, DKIM signers, and URLs matter.
- SPF can pass for a bounce domain, DKIM can pass for another domain, and DMARC can still fail for the visible sender.
- Unwanted mail, misleading sender details, abrupt changes in message format, unsafe URLs, and high bounce rates make a new sender look riskier.
Flowchart of Gmail evaluating a new domain using authentication, infrastructure, content, and recipient signals.
That is why production sends from a newly registered domain should begin with testing and expected low-volume mail instead of an immediate campaign launch. There is no fixed waiting period that creates reputation. Domain warming works by increasing wanted traffic gradually while authentication and complaints stay healthy.
The Gmail reason can be misleading
Gmail's displayed reason is useful, but it is not a complete forensic report. A notice about earlier unwanted mail does not identify every signal behind the decision. Inspect the authenticated domains, sending IP, URLs, and recipient history before assigning a cause.
What the label suggests
Read literally, the label points to direct recipient history with the visible sender.
- The same visible From domain previously sent to the Gmail recipient and was marked unwanted.
- Gmail has a user-level or account-level memory tied to a sender identity.
What else to inspect
The message path contains other identities and reputation signals that can affect placement.
- The message can be signed by a different domain that already has reputation.
- The sending IP or tracking URL can have history with Gmail.
- A contact entry or a previous not-spam action can change placement for one Gmail account without changing domain-wide reputation.
Illustration of Gmail's Show original view with SPF, DKIM, and DMARC results for a new-domain test email.
Header fields to inspecttext
Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=bounces.example.com; dkim=pass header.d=example.com header.s=s1; dmarc=pass header.from=example.com From: Person <person@example.com> Return-Path: <bounces@bounces.example.com>
DMARC passes when at least one successful SPF or DKIM path meets the domain matching rule for the visible From address. With the default relaxed setting, the domains must share an organizational domain. If adkim=s or aspf=s applies, that authentication path requires an exact domain match. When header.d does not match, the message can still pass DMARC through SPF if the Return-Path domain matches under the applicable rule. If neither path matches, DMARC fails even when SPF and DKIM each show pass. See RFC 9989.
What to check first
Start with the actual delivered or filtered message. Send a realistic message to Gmail and open More > Show original. Test the same sending configuration with Suped's email tester.
Use a realistic message as the baseline rather than an empty message or a fake subject. Gmail scores the whole message. A realistic test includes the same sender, envelope path, content type, links, tracking, footer, and sending route that production mail will use.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
After the test, work through the evidence in a fixed order. This keeps the diagnosis grounded and prevents random DNS changes.
- Use the same app, mailbox, routing, and content that will send to customers.
- Confirm Gmail's SPF, DKIM, and DMARC results and the visible From domain. Check the sending IP's forward and reverse DNS separately, and verify TLS in the message or transport logs.
- Check whether a successful DKIM or SPF identity matches the visible sender for DMARC.
- Look at tracking links, redirect domains, and any short links used in the message.
- Look for IP or domain listings with blocklist monitoring (blacklist monitoring), especially on shared systems.
|
|
|
|---|---|---|
Sending history | Gradual, wanted | No history or spike |
DKIM | Passes and matches | Fails or does not match |
SPF | Authorized | Missing or too broad |
PTR/FWD DNS | Forward and reverse agree | Missing or mismatched |
URLs | Expected, trustworthy destinations | Unsafe destinations or deceptive redirects |
User-reported spam rate | Under 0.10% | 0.10%+ needs review; 0.30%+ is high risk |
These are diagnostic clues. A clean public blocklist (blacklist) check cannot confirm Gmail inbox placement.
DNS records to publish before sending
Before sending from a new domain, run a domain health checker and verify the records from DNS, not only the sending app settings. Records should be simple enough to audit and strict enough that Gmail can identify authorized sources.
Example DNS records with placeholdersdns
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com" example.com TXT "v=spf1 include:_spf.sender.example -all" selector1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=PUBLICKEY"
Replace the example domains, reporting mailbox, SPF include, selector, and public key with values for your sending setup. Use the DKIM record supplied by the sending service; some services use CNAME records instead.
Start in observation mode
For a new domain with an incomplete sender inventory, a DMARC policy of p=none is a monitoring starting point, not a final security posture.
- Publish the DMARC record with a working rua address and confirm that reports identify every legitimate sender.
- Move to quarantine only after authentication is clean.
- Move to reject after business-critical mail is passing consistently.
In Suped's product, DMARC monitoring groups aggregate reports by sending source so the team can find unexpected senders and investigate authentication failures before increasing Gmail-bound traffic.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
For mail to personal Gmail accounts, DKIM keys must be at least 1024 bits. Google recommends 2048-bit keys when the DNS host and sending system support them.
PTR, A or AAAA, and TLS checks are separate from the example TXT records. The sending IP needs matching forward and reverse DNS, and delivery to personal Gmail accounts must use TLS.
The practical target is a message that passes authentication for the domain the recipient sees. Check for unexpected signers or relays and broken forwarding paths.
Build reputation with an opted-in email list
Domain warming should use mail recipients expect. Google's email subscription guidelines call for address confirmation before subscription mail, also called double opt-in.
- Use double opt-in to confirm both control of the address and a request to receive your subscription messages.
- Keep purchased or scraped addresses, and contacts without recorded permission, out of the new domain's marketing audience.
- Suppress hard-bouncing addresses and unsubscribe requests promptly. Repeated attempts to invalid recipients add delivery failures without building reputation.
- Review inactive subscribers using more than open rates. Check recent clicks or purchases before deciding who should receive further marketing.
How to warm a new domain for Gmail
Gmail trust is earned through consistent identity and recipient behavior. Registration age alone does not warm a domain. Start with mail people expect, increase volume gradually, and hold or reduce volume when complaints, bounces, or authentication failures rise.
New-domain sending posture
A practical way to think about early Gmail risk.
No sending history
highest risk
Use testing and low-risk personal or transactional mail.
Early sends
careful
Increase wanted mail gradually and watch authentication.
Clean sending history
lower risk
Scale only while complaints and failures remain low.
If the domain is already sending and Gmail placement is poor at low sending volumes, slow down rather than pushing more traffic. More mail gives Gmail more evidence, and bad evidence is hard to unwind.
Use Google Postmaster Tools once volume is high enough to show data. In v2, check Compliance status, spam rate, authentication, and delivery errors. The old domain and IP reputation dashboards are not included in v2; Google has postponed retirement of the legacy web interface. See Google's interface migration notice.
Postmaster Tools data applies to personal Gmail accounts, is not real time, and can be absent on low-volume days. The user-reported spam rate concerns DKIM-authenticated inbox deliveries that recipients mark as spam. Automatic spam filtering can leave a low reported rate even when inbox placement is poor. Gmail does not identify individual spam reporters. Use Google's dashboard guidance alongside delivery logs and real recipient feedback.
- Start each mail stream at low volume with recipients who expect it, including opted-in subscribers.
- Send messages a recipient expects, with clear identity and no URL clutter.
- Use different From addresses for transactional and marketing mail. Subdomains help organize streams, but their volume still counts toward the primary domain's bulk-sender threshold.
- Keep Postmaster Tools spam rate below 0.10% and avoid 0.30% or higher.
- For marketing and subscribed mail, include a visible unsubscribe link. When Gmail's bulk-sender rules apply, implement RFC 8058 one-click unsubscribe with List-Unsubscribe and List-Unsubscribe-Post headers, support HTTPS POST requests, and honor requests within 48 hours. A footer link alone does not meet the header requirement. See Google's unsubscribe requirements.
- A sudden DKIM failure or broken SPF include can teach Gmail the wrong pattern quickly.
- Do not launch at full campaign volume on the day the domain is registered.
Do not manufacture engagement
Buying opens, forcing replies, or sending to friendly seed accounts at scale does not create durable trust. Gmail cares about real recipient behavior over time. Keep the early traffic honest and useful.
Monitor authentication with Suped
Suped's product combines email testing with DMARC reports and blocklist (blacklist) monitoring to investigate authentication failures and sending infrastructure. DMARC reports show authentication results, while Gmail inbox placement needs separate evidence from actual messages and recipients.
Manual diagnosis
- Someone has to inspect every Gmail test and map each result by hand.
- SPF, DKIM, and DMARC changes sit across multiple providers and owners.
- The team has to notice authentication drift before Gmail learns from it.
Suped workflow
- Suped surfaces failing sources, failed matches, and configuration gaps automatically.
- Suped shows the specific DNS or sending-source change needed to repair the issue.
- Suped can notify the team when failure rates or suspicious sources move.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For teams adding new domains regularly, use Suped's reports to confirm each sending source before increasing volume, then investigate authentication failures as they appear. Suped's alerts help the team catch changes between manual tests.
Views from the trenches
Best practices
Build history with low-volume mail that real recipients expect before campaign traffic.
Use the same organizational domain for DKIM and From under DMARC's default relaxed rules.
Inspect message headers before changing DNS, because the failing identity is often elsewhere.
Common pitfalls
Sending first traffic through a shared platform with poor URL reputation hurts new domains.
Treating a Gmail reason label as exact proof hides DKIM, IP, and content signals from review.
Applying p=reject before every sender is tested can block legitimate mail during setup.
Expert tips
Increase each mail stream gradually with recipients who explicitly asked for that mail.
Separate marketing and transactional streams for diagnosis, but keep monitoring both.
Use DMARC reports to find every sender before Gmail learns from inconsistent mail streams.
Marketer view
Marketer from Email Geeks says freshly registered domains need time before serious sending and uses 30 days as a conservative operational buffer, not a Gmail guarantee.
2021-04-08 - Email Geeks
Marketer view
Marketer from Email Geeks says a new visible From domain can inherit risk from an older DKIM signing domain used in the same message.
2021-04-08 - Email Geeks
What to do next
If Gmail sends a new-domain message to spam, do not start by changing every DNS record. Verify the actual message, find the identities Gmail saw, and slow the sending pace until the domain has clean evidence.
- Pause production volume, verify DNS, and send only expected low-volume messages.
- Fix the DKIM signer or SPF bounce identity so at least one successful path matches the visible domain.
- Review content, URLs, infrastructure, and recipient behavior before changing DNS again.
For a deeper remediation path, use a focused fix Gmail spam workflow after the header evidence is clear.
