Why Gmail Spams New Domain Email

Gmail has no reason to trust you yet

A brand-new domain can send a clean-looking email and still land in spam. Gmail has no good history for the domain, so it leans on proof.

That proof starts with authentication. Gmail wants to see that the sending server is allowed to send, the message is signed, and the domain in the visible From address lines up with SPF or DKIM under DMARC. After that, mailbox providers look at behavior: who you send to, how fast you send, whether people complain, and whether mail bounces.

• Use a real mailbox on a domain with working MX records so replies can reach you.
• Authenticate every system that sends mail for the domain, including billing, support, marketing, and app alerts.
• Send wanted mail first. A jump from zero history to a large campaign is a common path to throttling or spam placement.

Fix SPF first

SPF is the DNS TXT record that lists which servers may send mail for a domain. Receivers check it to spot forged sender paths.

Your domain should publish one SPF record for the domain used in the envelope sender, also called the return path. The record starts with v=spf1 and includes the mail services you actually use, such as Google Workspace, Microsoft 365, or your email platform. More than one SPF record for the same name can cause SPF to fail.

• Use the include values your provider gives you. Do not guess at IP addresses unless you control the sending server.
• Stay under the SPF 10 DNS lookup limit from RFC 7208. The include, a, mx, ptr, exists, and redirect mechanisms can all count toward it.
• Use ~all while you are still finding senders. Use -all only after every real sender is covered. Do not use +all, which allows any server.

Turn on DKIM signing

DKIM adds a cryptographic signature to a message. The receiver checks that signature against a public key in DNS.

Most providers give you one or more selectors, such as google._domainkey or selector1._domainkey. Publish the TXT or CNAME records they provide, then enable signing in that provider. If the message is unsigned, or the selector points to the wrong key, the receiver loses a major signal that the message is legitimate.

• Send a real test message and inspect the headers for dkim=pass.
• Check the d= value in the DKIM result. For DMARC, it should align with the visible From domain or its organizational domain.
• Rotate DKIM keys through your provider instead of editing the key by hand.

Add DMARC and read the reports

DMARC connects SPF, DKIM, and the visible From domain. It also gives you reports that show who is sending as your domain.

Publish DMARC at _dmarc.yourdomain. A safe starter record often uses p=none with a rua address so you can monitor before you enforce. DMARC passes when SPF or DKIM passes and aligns with the visible From domain. The original DMARC spec is RFC 7489. The current 2026 update splits DMARC across RFC 9989 for policy, RFC 9990 for aggregate reports, and RFC 9991 for failure reports. The common policy values remain p=none, p=quarantine, and p=reject.

• Start with p=none if you do not yet know every sender. It reports without asking receivers to quarantine or reject failing mail.
• Use rua aggregate reports to find unknown senders before enforcement. The free DMARC report reader can turn XML reports into a sender list.
• Move toward quarantine or reject after your real mail passes. Enforcement helps receivers reject spoofed mail, but it does not guarantee inbox placement.

Warm up the domain slowly

A new domain has little reputation. Gmail and Outlook watch what recipients do with your mail, so technical setup is only the start.

Send to people who expect your email. Keep early volume low and steady. Avoid old lists, scraped contacts, purchased lists, and role accounts like info@ or sales@. Complaints, hard bounces, fast deletes, and no engagement can push a new sender toward spam.

• Increase volume in small steps instead of sending a large campaign overnight.
• Remove hard bounces right away and stop mailing people who do not engage.
• For bulk mail, follow current Google and Microsoft sender guidelines. They cover authentication, alignment, unsubscribe handling, and complaint rates.

Check blocklists and content after DNS

Blocklists and copy can matter, but check them after SPF, DKIM, DMARC, and MX. Bad DNS can make good copy look suspicious.

Look up the sending IP and domain on major blocklists, especially if the domain was owned before or a mailbox was compromised. Then inspect the message. Image-only emails, misleading subjects, link shorteners, broken unsubscribe links, and attachments from a new sender can all raise risk.

• Use a clear From name and a reply address that works.
• Keep links on domains people can recognize. Avoid hiding destinations behind shorteners.
• Send useful plain text and HTML. Do not send one large image with the whole message baked into it.

Make the linked site readable too

AI search visibility will not decide Gmail spam placement. It can affect whether answer engines can read the site your email points to.

The crawlers that decide whether you appear in AI answers are OAI-SearchBot for ChatGPT search, Claude-SearchBot for Claude, PerplexityBot for Perplexity, Googlebot for Google AI Overviews through the normal Search index, and Applebot for Apple Intelligence. Disallowing these in robots.txt removes you from that engine.

GPTBot, ClaudeBot, CCBot, Google-Extended, and Applebot-Extended are training or opt-out controls. Blocking them does not remove you from live AI-search visibility. Google-Extended and Applebot-Extended are robots-only control tokens with no separate crawl user-agent.

Robots.txt is a stated site policy, not proof of crawler behavior. Perplexity-User and Bytespider have been reported to ignore it, so do not claim a bot obeyed or ignored robots.txt without logs and vendor documentation. Only Googlebot documents JavaScript rendering. If key content is client-side-only, other AI crawlers may miss it, but that is an undocumented risk. Put the main text in HTML when it matters, and use the free AI visibility checker to see what is reachable.

Debug in this order

Change one layer at a time. Start with proof, then work on reputation.

• Run a domain check. The free InboxRadar scorecard checks SPF, DKIM, DMARC, and MX in one place.
• Send one test email to Gmail and read the headers for spf=pass, dkim=pass, and dmarc=pass.
• Confirm DMARC alignment. SPF can pass on a vendor return path and still fail DMARC if it does not align with the From domain.
• Pause cold or bulk sends until authentication failures are fixed.
• Restart with a smaller, cleaner list. Watch bounces, complaints, opens, replies, and unsubscribes.

If the records pass and Gmail still filters you, the likely cause is reputation. Slow down, send to warmer contacts, and remove people who did not ask for the mail. Technical trust gets the message evaluated. Recipient behavior decides whether the domain earns the inbox.

For deeper setup help, see the related email deliverability guides.