Interactive Troubleshooter

Published: Sep 6, 2026

Gmail Not Receiving Emails: Greylisting and SPF Fix

Time: 15 mins Level: Beginner

By StepDiag Engineering Team

Reviewed by Ibraheem Taofeeq Opeyemi

An interactive root-cause diagnostic tree to resolve incoming email delivery failures in personal Gmail and Google Workspace accounts. Troubleshoot SPF/DMARC authentication drops, MTA greylisting delays, broken custom domain MX records, and Gmail storage quota blocks.

Full Diagnostic Tree & Step-by-Step Overview

What specific bounce error code, header state, or delivery behavior occurs when sender emails fail to reach Gmail?

Sender receives bounce messages citing authentication failures (550 5.7.26, SPF fail, or unauthenticated mail rejected).
Emails are delayed for hours or retried with temporary SMTP deferral codes (451 4.4.2 or 421 4.7.0 greylisting/rate-limiting).
Emails do not appear in the Inbox but sender receives no bounce error (bypassing Inbox, hidden in Spam/All Mail, or full storage).
Google Workspace custom domain account stops receiving all incoming external emails after a DNS or host migration.

Which email authentication or sender policy restriction matches the sender's rejection log?

SPF record fails authentication, exceeds the 10-DNS-lookup limit, or uses multiple conflicting TXT records.
DMARC policy rejection ('p=reject' or 'p=quarantine') triggered by missing or misaligned DKIM signatures.
Sender IP address lacks a valid Reverse DNS (PTR) record or fails mandatory TLS encryption requirements.

Flatten Domain SPF TXT Records and Resolve DNS Lookup Limits

Solution:

Root Cause: SPF PermError and 10-DNS-Lookup Overflow

Gmail strictly enforces RFC 7208 rules, which limit an SPF (Sender Policy Framework) evaluation to a maximum of 10 direct or nested DNS lookups (mechanisms like include, a, mx, ptr, and exists). When a sending domain uses multiple third-party email providers (e.g., Google Workspace, Salesforce, SendGrid, Zendesk), total nested lookups often exceed 10. This triggers a PermError: SPF PermError: too many DNS lookups, causing Gmail's inbound MTA to issue a 550 5.7.26 Unauthenticated email from domain is not accepted rejection.

Step-by-Step Fix:

1Audit Domain SPF DNS Lookups:

Execute a command-line dig query to inspect active SPF records:

bash
     dig +short TXT example.com | grep "v=spf1"

Count the number of include:, a, and mx statements. Ensure there is strictly one SPF TXT record on the apex domain.

2Flatten SPF Inclusions into Static CIDR IP Blocks:

Replace nested include: directives with direct ip4: or ip6: ranges where possible to eliminate runtime DNS requests.

*Example before:* v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org ~all

*Example after (flattened):* v=spf1 include:_spf.google.com ip4:168.245.0.0/16 ~all

3Consolidate Multiple TXT Records:

Remove duplicate v=spf1 records. Merge separate vendor authorizations into a single string starting with v=spf1 and ending with ~all or -all.

4Verify Propagation:

Test the updated domain record using nslookup:

bash
     nslookup -type=TXT example.com 8.8.8.8

Configure DKIM Domain Keys and Align DMARC Policies

Solution:

Root Cause: DMARC Domain Alignment Failure (`p=reject` Enforcement)

Google enforces strict sender authentication guidelines for all bulk and transactional mail senders. If a sending domain defines a DMARC policy (_dmarc.example.com) set to p=reject or p=quarantine, but the email headers fail Domain Alignment (where the Header From domain does not match the Envelope From or DKIM d= domain), Gmail rejects the incoming message at the SMTP gateway with error 550 5.7.1 Unauthenticated email is not accepted under domain's DMARC policy.

Step-by-Step Fix:

1Verify DKIM CNAME/TXT Records on Sending Domain:

Query the domain's active DKIM selector (e.g., google._domainkey):

bash
     dig +short TXT google._domainkey.example.com

Ensure the selector returns a valid public key starting with v=DKIM1; k=rsa; p=....

2Align Header From and Envelope From Domains:

Ensure third-party email platforms (e.g., Mailchimp, HubSpot) send mail using a custom return-path (mail.example.com) matching your root domain rather than the vendor's default domain.

3Temporarily Adjust DMARC Policy for Testing:

Edit the _dmarc TXT record in your DNS zone to monitoring mode while fixing DKIM signatures:

text
     v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com;

Review Google Workspace Email Sender Guidelines for updated alignment specifications.

Configure Forward/Reverse DNS (PTR) Records and Enforce TLS Encryption

Solution:

Root Cause: Missing Reverse DNS (PTR) or Unencrypted SMTP Transport

Gmail's security controls drop or defer incoming TCP connections from sending Mail Transfer Agents (MTAs) that fail basic RFC infrastructure compliance. Specifically, sending mail servers must have a valid Forward-Confirmed Reverse DNS (FCrDNS) entry—where the sending IP resolves to a hostname via a PTR record, and that hostname resolves back to the same IP. Additionally, Gmail requires TLS v1.2+ encryption on inbound transport; plain text SMTP sessions are rejected.

Step-by-Step Fix:

1Verify Reverse DNS PTR Records:

Run host or dig -x on the sending server's egress IP:

bash
     dig -x 192.0.2.1 +short

Confirm the result returns a FQDN (e.g., mail.example.com).

2Confirm Forward Lookup Matching:

Query the A record of the returned hostname:

bash
     dig +short mail.example.com

Verify that the IP matches the sending egress IP address exactly.

3Enforce Opportunistic TLS on Sending MTA:

Update Postfix (main.cf) configuration to require TLS outbound:

text
     smtp_tls_security_level = may
     smtp_tls_loglevel = 1

Restart Postfix service:

bash
     sudo systemctl restart postfix

Which SMTP deferral error or delivery delay pattern is reported in mail server queues?

Gmail issues temporary 451 4.7.1 or 421 4.7.0 greylisting deferrals on newly deployed sending IPs.
Connections are rate-limited with '421 4.7.28 Speed-Throttling' due to sudden spikes in volume.
Sending IP address is listed on major RBL blacklists (Spamhaus, Barracuda), causing connection blocks.

Configure MTA Queue Retry Parameters to Handle Greylisting Deferrals

Solution:

Root Cause: Anti-Spam Greylisting Deferrals on Unwarmed IPs

Greylisting is an inbound anti-spam technique where Gmail's edge MTAs temporarily reject connection attempts from unfamiliar IP addresses or domain pairings using temporary error codes (451 4.7.1 or 421 4.7.0 Try again later). Legitimate mail servers are expected to retry delivery after a short cooldown interval (typically 5 to 15 minutes). If the sending MTA drops the message immediately instead of queuing it, the email is never delivered.

Step-by-Step Fix:

1Verify Sending MTA Queue Retry Interval:

Inspect Postfix queue lifetime settings in /etc/postfix/main.cf:

text
     maximal_queue_lifetime = 5d
     bounce_queue_lifetime = 5d
     minimal_backoff_time = 300s
     maximal_backoff_time = 4000s

2Monitor Mail Queue Status:

Inspect deferred messages in queue using mailq or postqueue:

bash
     postqueue -p

3Force Immediate Queue Flush After Cooldown:

Manually trigger a retry once the 15-minute greylisting window passes:

bash
     postqueue -f

4Warm Up New Sending IPs Gradually:

Increase daily email volume incrementally (e.g., starting at 500 emails/day) to build sender reputation on Gmail's inbound filters.

Implement Exponential Backoff and Concurrency Limits for Gmail MTAs

Solution:

Root Cause: Inbound SMTP Connection Rate Limiting (`421 4.7.28` Throttling)

When a single sending IP opens excessive parallel SMTP connections or transmits high message bursts to Gmail without an established domain reputation, Google's traffic shapers impose rate limits. The server returns temporary deferrals such as 421 4.7.28 Our system has detected an unusual rate of unsolicited mail. If the sending server ignores these codes and continues opening aggressive sockets, Gmail escalates the deferral to a temporary IP block.

Step-by-Step Fix:

1Restrict Parallel Outbound Connections to Gmail in Postfix:

Define a dedicated transport for Google destinations in /etc/postfix/transport:

text
     gmail.com       smtp:gmail-transport
     googlemail.com  smtp:gmail-transport

Map the transport table:

bash
     sudo postmap /etc/postfix/transport

2Configure Throttling Parameters in /etc/postfix/main.cf:

Add rate-limiting rules for gmail-transport:

text
     gmail-transport_destination_concurrency_limit = 2
     gmail-transport_destination_rate_delay = 1s
     gmail-transport_destination_recipient_limit = 5

3Reload Mail Service:

Apply updated Postfix settings:

bash
     sudo systemctl reload postfix

Remediate RBL Blacklisting and Request Delisting from Spam Feeds

Solution:

Root Cause: IP/Domain Reputation Blacklisting on Real-time Blocklists (RBLs)

Gmail consumes internal spam telemetry as well as external threat intelligence data feeds (e.g., Spamhaus Zen, Barracuda, Spamcop). If your sending IP or domain was previously compromised, sent unauthenticated marketing blasts, or hosted open relays, it gets listed on major blacklists. Gmail drops connection handshakes from listed IPs with 550 5.7.1 Service unavailable; Client host [x.x.x.x] blocked using Zen Spamhaus.

Step-by-Step Fix:

1Query Egress IP Against Major RBLs:

Perform a DNS lookup against Spamhaus Zen using your reversed IP address (e.g., for 192.0.2.1 -> 1.2.0.192):

bash
     host 1.2.0.192.zen.spamhaus.org

If an answer 127.0.0.x is returned, the IP is actively listed.

2Fix Internal Mail Server Security Leaks:

Secure open SMTP relays and check mail logs (/var/log/maillog) for compromised user credentials sending outbound spam.

3Submit Delisting Requests:

Request removal directly through official lookup portals (e.g., Spamhaus Blocklist Removal Center).

4Register Domain in Google Postmaster Tools:

Monitor internal spam rate metrics and IP reputation directly via Google Postmaster Tools.

Which Gmail account setting, filter rule, or quota issue applies to your inbox?

Google account storage is 100% full (Drive/Gmail quota reached, bouncing with 552 5.2.2).
Inbound emails bypass Inbox due to search filter rules ('Skip the Inbox') or forwarding addresses.
Third-party email client (Outlook/Apple Mail) fails to sync over IMAP/POP3 despite webmail working.

Clear Google Cloud Storage Quota and Restore Inbound Mail Flow

Solution:

Root Cause: Storage Quota Exhaustion Across Google One Ecosystem

Personal Gmail accounts (15GB free tier) and Google Workspace mailboxes share a unified cloud storage quota across Gmail, Google Drive, and Google Photos. When total usage hits 100%, Google's inbound mail gateway immediately rejects incoming messages with error code 552 5.2.2 The email account that you tried to reach is over quota. Sender emails bounce permanently and cannot be recovered retroactively.

Step-by-Step Fix:

1Audit Storage Breakdown:

Open Google One Storage Management to identify which service (Drive, Photos, or Gmail) is exhausting memory.

2Purge Large Gmail Attachments:

In the Gmail search bar, enter the following operator to isolate emails with attachments larger than 10MB:

has:attachment larger:10M

Select unwanted messages, move them to Trash, and empty the Trash folder (messages in Trash continue to count against quota until purged).

3Clean Up Google Drive and Photos Trash:

Open Google Drive -> Trash -> Click Empty trash.

Open Google Photos -> Trash -> Click Empty trash.

4Verify Quota Recovery:

Confirm total storage drops below 99%. Incoming mail delivery will resume automatically within 15 to 30 minutes.

Audit Gmail Search Filters, Automated Forwarding, and Blocked Addresses

Solution:

Root Cause: Aggressive Inbox Search Filters or Unchecked Auto-Forwarding Rules

When incoming emails arrive at Gmail's internal router, user-defined rules process before messages hit the primary Inbox. Misconfigured filters containing broad search terms (e.g., matching a sender's root domain or subject keywords) set to 'Skip the Inbox (Archive it)', 'Delete it', or 'Mark as read' silently divert mail to 'All Mail', Trash, or Spam without triggering user notifications. Similarly, active POP3/IMAP forwarding rules can archive messages upon transfer.

Step-by-Step Fix:

1Inspect Active Gmail Filters:

Open Gmail in desktop browser -> Click Settings (gear icon) > See all settings.

Select the Filters and Blocked Addresses tab.

Review all rules. Look for filters specifying Do this: Skip the Inbox or Delete it. Delete or edit conflicting filters.

2Verify Forwarding Settings:

Select the Forwarding and POP/IMAP tab.

Ensure Forward a copy of incoming mail is either disabled or set to keep Gmail's copy in the Inbox.

3Search Internal System Folders:

Search for missing messages across all mail repositories using global search operators:

in:anywhere from:sender@example.com

Reconfigure IMAP/POP3 Protocol Settings and OAuth2 App Passwords

Solution:

Root Cause: Local IMAP Sync Stalls and Deprecated Basic Authentication

If emails appear in the Gmail web interface (mail.google.com) but do not sync to desktop or mobile clients (e.g., Microsoft Outlook, Apple Mail, Thunderbird), the failure is isolated to the IMAP/POP3 retrieval protocol. Google enforces strict OAuth2 authentication and disabled legacy 'Less Secure Apps' access. Outdated desktop mail configurations fail to refresh OAuth tokens, causing local inbox sync stalls.

Step-by-Step Fix:

1Enable IMAP Access in Gmail Web Settings:

Open Gmail Settings -> Forwarding and POP/IMAP.

Under *IMAP access*, select Enable IMAP -> Click Save Changes.

2Update IMAP/SMTP Client Server Settings:

Incoming IMAP Server: imap.gmail.com | Port: 993 | Security: SSL/TLS

Outgoing SMTP Server: smtp.gmail.com | Port: 465 (SSL) or 587 (STARTTLS)

3Generate an App Password (For Non-OAuth Clients):

If your client lacks native OAuth2 login support, open Google Account Security.

Enable 2-Step Verification.

Search for App passwords, create a new 16-character token, and use it as your password in the local mail client.

Which custom domain DNS routing or Google Workspace MX state matches your issue?

Google Workspace domain MX records are missing, invalid, or pointing to legacy web host servers.
Dual MX records exist on the DNS zone, causing split routing and dropped inbound connections.
DNSSEC validation errors or expired RRSIG records cause public resolvers to block MX resolution.

Configure Primary Google Workspace MX Records in Domain DNS Zone

Solution:

Root Cause: Missing or Misdirected MX (Mail Exchange) DNS Records

When third-party servers transmit email to a custom Google Workspace domain (@yourdomain.com), they execute a DNS lookup for the domain's MX records. If domain MX records point to old web hosting servers (e.g., cPanel, Namecheap, Bluehost) or were erased during a DNS manager migration (e.g., moving to Cloudflare), sending servers cannot locate Google's inbound mail gateways, resulting in immediate delivery failures (550 5.1.1 Host or domain name not found).

Step-by-Step Fix:

1Inspect Current MX Records via Terminal:

Run dig to list active Mail Exchange servers:

bash
     dig +short MX example.com

2Purge Legacy Host MX Records:

Log into your DNS provider (Cloudflare, GoDaddy, Namecheap) and delete any existing MX records pointing to local hosting servers (e.g., mail.example.com or smtp.secureserver.net).

3Add Google Workspace MX Records:

Add the single simplified Google Workspace record (recommended for modern setups):

Type: MX | Name: @ | Target: SMTP.GOOGLE.COM. | Priority: 1

*Or add legacy Google Workspace records if required:*

ASPMX.L.GOOGLE.COM. (Priority 1)

ALT1.ASPMX.L.GOOGLE.COM. (Priority 5)

ALT2.ASPMX.L.GOOGLE.COM. (Priority 5)

4Verify TTL and Propagation:

Confirm resolution via Google Public DNS:

bash
     nslookup -type=MX example.com 8.8.8.8

Eliminate Dual MX Record Conflict and Fix Split Domain Routing

Solution:

Root Cause: Conflicting Multi-Vendor MX Priorities and Split Routing

Maintaining MX records pointing to two different email providers simultaneously (for example, combining Google Workspace's SMTP.GOOGLE.COM with a local web host's mail.example.com at equal or lower priorities) breaks RFC mail delivery guarantees. Sending MTAs will randomly pick target servers based on round-robin responses or cached priority values. Messages delivered to local server mailboxes bypass Google Workspace entirely and appear 'lost'.

Step-by-Step Fix:

1List All Active MX Hosts in DNS Zone:

Execute a query to view all configured priorities:

bash
     dig MX example.com +noall +answer

2Remove Non-Google Target Hosts:

Delete any entry that does not belong to Google infrastructure.

3Configure Catch-All or Split Delivery in Google Workspace Admin:

If you intentionally route some mailboxes to a secondary server, do not use dual DNS MX records. Instead, log into Google Admin Console (admin.google.com).

Go to Apps > Google Workspace > Gmail > Routing.

Configure an Inbound Route or Catch-all rule to relay specific recipient addresses to your external host securely via Smart Host settings.

Fix DNSSEC Security Chain Validation and Expired RRSIG Records

Solution:

Root Cause: Broken DNSSEC Chain of Trust on Domain Zone

If Domain Name System Security Extensions (DNSSEC) is enabled at your domain registrar but the DS (Delegation Signer) keys do not match the RRSIG records served by your DNS host (common after transferring DNS management between Cloudflare, Route53, or Registrar DNS), validating resolvers evaluate all MX lookups for your domain as SERVFAIL. Sending MTAs enforcing DNSSEC (including Gmail) refuse to deliver messages to unvalidated targets.

Step-by-Step Fix:

1Audit DNSSEC Security Chain:

Perform a DNSSEC validation lookup using dig:

bash
     dig MX example.com +dnssec +multi

Inspect output for SERVFAIL status or missing ad (Authenticated Data) flags.

2Re-Sync DS Records at Registrar:

Log into your domain registrar dashboard.

Copy the public key, algorithm type, and digest hash from your DNS provider's DNSSEC management page.

Update the DS record fields at the registrar to establish a valid signature chain.

3Disable and Re-enable DNSSEC (Emergency Flush):

If signing keys are corrupted, temporarily turn off DNSSEC at both the registrar and DNS host to allow immediate global record resolution, then regenerate keys after 24 hours.

Related Diagnostic Guides

Windows Update Error 0x80070002 Missing Files Diagnostic Guide

System Restore Failed 0x80070005 Antivirus Conflict Tree

Windows Photo Viewer Not Showing Thumbnails: Codec Diagnostic

Safe Mode Password Not Working With Microsoft Account Fix

Clipboard History Not Working Windows 11: Sync Service Tree

Subscribe to StepDiag

Embed Guide on Your Website