Is Gmail's 4.7.28 deferral worse than a 550 5.7.1 rejection?

You sent a message. Gmail says “4.7.28 — try again later.” A few hours later, it says “550 5.7.1 — rejected.” Which one should you worry about more?

The answer isn’t obvious. A 4.7.28 deferral sounds temporary. But a 550 5.7.1 feels final. In reality, both signal trouble—but in different ways. One is a pause, the other is a shutdown. Understanding the difference isn’t just technical trivia. It’s about fixing deliverability before your list gets blocked.

Key takeaways

  • A 4.7.28 deferral means Gmail deferred delivery temporarily, often due to rate limits, connection instability, or server checks — it’s not a final rejection.
  • A 550 5.7.1 rejection is a hard failure — Gmail has outright rejected the message, typically due to sender reputation issues, spam signals, or policy violations.
  • Repeated 4.7.28 errors signal growing deliverability risk; 550 5.7.1 errors require immediate corrective action to restore sending access.

What does Gmail 4.7.28 mean in practice?

Gmail 4.7.28 means your email was temporarily delayed, not rejected. It's a transient SMTP status indicating a delivery hiccup—commonly due to a server timeout, high load, or exceeding message size limits. Gmail will retry delivery up to 10 times over several hours before giving up. You won’t get immediate feedback, and the recipient won’t see anything unusual. This code doesn’t reflect sender reputation or content issues—it signals a momentary network or infrastructure issue.

When 4.7.28 happens, what’s really going on?

Let’s break it down: the code 4.7.28 comes from the SMTP protocol itself, specifically from the RFC 5321 standard on mail system behavior. It’s a transient failure, not a hard bounce—meaning the problem is temporary and not a direct signal of a bad address or a blocklist. Common triggers include brief network glitches, overwhelmed mail servers (especially during high-volume sends), or oversized messages that exceed Gmail’s limits (currently 25MB per email). If your server can’t complete the TCP handshake or times out during the transfer, Gmail returns 4.7.28.

It’s important to distinguish this from 550 5.7.1 (a permanent rejection for policy or spam reasons). 4.7.28 doesn’t mean your email was blocked or the inbox was invalid—it means the mail server wasn’t ready to accept it at that moment. The system doesn’t blame the sender; it assumes the issue is temporary. You’ll see this code when sending bulk emails, especially from automated systems, during system maintenance or traffic spikes.

How should you respond?

Don’t assume the address is dead. In most cases, no action is needed on your part—Gmail handles retries automatically. But if you’re tracking deliverability, this code can appear in logs if you’re not using a dedicated verification service. You might see multiple 4.7.28 entries for the same recipient across several hours, which is normal.

Still, if you’re experiencing frequent 4.7.28 codes across a list, it may signal underlying issues—like poor sender infrastructure, misconfigured TLS, or oversized attachments. That’s where real-time verification helps. Check your list with MailTester before sending to filter out risky or unreliable domains, ensuring your messages don’t trigger timeouts or volume-based throttling. Verify your list at scale and avoid delivery delays before they happen.

What does 550 5.7.1 mean, and why is it serious?

The 550 5.7.1 error is a hard rejection from Gmail’s final gatekeeper: your message was evaluated, scored, and blocked based on sender reputation, content triggers, or policy rules. Unlike transient errors, this is a permanent failure—no retry is attempted, and delivery will not happen unless the root cause is fixed. This is worse than a 4.7.28 bounce because it means Gmail has already made a final, automated decision against deliverability.

How Gmail decides at the 550 5.7.1 level

Gmail doesn’t just filter spam—it scores sender authenticity in real time. Every email passes through multiple layers: DNS checks, authentication (SPF, DKIM, DMARC), reputation thresholds, content analysis, and behavioral signals. The 550 5.7.1 comes after all that—when Gmail’s system concludes the message violates policy or poses a risk.

It’s not about a single email. It’s about patterns. If your domain or IP has sent spam before, has poor engagement, or uses content known to trigger filters (e.g., "free," "urgent," or excessive links), Gmail will block it permanently. Even valid messages can fall here if reputation is low or content is flagged as suspicious.

Why this error is a red flag for deliverability

Once Gmail issues 550 5.7.1, the recipient never sees the message—even if it was perfectly crafted. The system treats it as a failed security or policy check, not a delivery glitch. It’s not a retryable error. You won’t get a second chance without fixing the underlying issue.

Most ISPs treat 550 5.7.1 as a strong indicator of bad sender behavior. According to industry data from Spamhaus, message blocks at this tier often relate to compromised credentials, poor list hygiene, or misuse of sender infrastructure. Recovery requires audit, cleanup, and ongoing trust-building—no shortcuts.

Let’s be honest: 550 5.7.1 is not a glitch—it’s a judgment. You can’t just resend. If your list includes outdated, compromised, or disposable emails, you’re likely triggering this. The fix isn’t in your message body—it’s in your sending practices. Verify every email before sending with a tool like MailTester's bulk verification to catch these issues early.

How do 421 and 550 differ in severity?

421 errors are temporary—usually caused by server overload or maintenance—while 550 errors are permanent rejections, meaning the recipient address is invalid, blocked, or violates policy. A 550 is always worse: it signals a hard failure that must be investigated. A 421 often resolves on its own after a few minutes.

Understanding 421: Temporary Server Unavailability

When you see a 421 response in an SMTP log, it means the receiving server is currently unable to accept your message. This isn’t about the email content—it’s about the server’s capacity. High load, maintenance windows, or network instability can trigger it.

These are transient. If your system pauses and retries after a short delay—say, 60 seconds—most 421s resolve without action. It’s not a sign your email is bad, just that the recipient’s mail system is busy. The RFC 5321 specification defines 421 as a “service not available” response meant for temporary conditions.

Understanding 550: Permanent Rejection

A 550 error is different. It means the recipient wasn’t accepted—forever. This could be because the address doesn’t exist, the domain blocks incoming mail, or policies like spam filters or sender reputation filters blocked the message.

Unlike 421s, 550s don’t resolve with retries. Each one requires attention. You can’t just send again and expect success. If you’re hitting 550s at scale, it’s a red flag—something is wrong with your list or your sending setup.

For example, sending to a role-based address like [email protected] might return 550 if the domain blocks such emails. Or, a known disposable email address will likely trigger 550 if the domain enforces strict policies.

The difference is in the outcome: 421 is a “try again later,” 550 is “this is not going to work.” That’s why you should prioritize 550s. Use tools to catch and purge these before you send. With MailTester, you can verify your list before sending and avoid both 421 and 550 headaches entirely.

Run a bulk verification to catch invalid or blocked addresses before they hit your SMTP server—and prevent those costly 550s.

When is deferral (4.7.28) a red flag, not just noise?

Receiving repeated 4.7.28 deferrals from Gmail isn't just temporary noise—it's a signal that your sending behavior is triggering sustained scrutiny. If deferrals persist across multiple messages or domains, especially when followed by eventual 550 5.7.1 rejections, it likely indicates a deeper issue with reputation, infrastructure, or message quality.

When deferrals aren’t just temporary

Single 4.7.28 responses are common during peak traffic, but when they repeat across multiple sends from the same IP, domain, or even across different senders using the same infrastructure, it’s no longer routine. Gmail uses 4.7.28 to delay delivery as a way to throttle suspicious behavior—meaning repeated deferrals suggest your messages are being treated as high risk, even if not outright blocked.

If you're seeing 4.7.28 from Gmail alongside 550 5.7.1 rejections for the same sender, it’s often a sign that your reputation has degraded. You’re not failing outright—yet—but you’re being held at arm’s length. Once your sender reputation drops below a certain threshold, Gmail may stop deferring and start rejecting outright.

Shared reputations and infrastructure risks

If deferrals occur not just from your domain but from other senders using the same IP range or shared infrastructure, that’s a red flag for reputation pooling. IP addresses used by multiple senders—especially those with mixed sending practices—can accumulate damage from one bad actor. In this case, Gmail’s response isn’t just about your message, but about your neighborhood.

Industry reports from sources like RFC 6522 confirm that temporary deferrals are a standard part of sender reputation systems. But when they become persistent, they’re not an error—they’re a warning. Let’s say you're running a campaign and your sends keep being deferred. Testing your list for invalid or high-risk addresses can prevent this from snowballing. Try inbox placement testing to see how your messages land across major providers—and catch issues before they escalate.

Diagnosing 4.7.28 vs 550 5.7.1: The real-world impact

4.7.28 and 550 5.7.1 are both SMTP errors from Gmail, but 550 5.7.1 is worse—it’s a hard rejection that blocks delivery entirely, while 4.7.28 is a temporary delay that might still get through later. If you’re seeing 550 5.7.1, you’re likely on a blacklist or flagged as spam. High 4.7.28 rates may not stop email delivery but hurt performance metrics like delivery speed and open rates over time.

What 4.7.28 really means—and why it matters

When you get a 4.7.28, Gmail is saying: "I’ll try to deliver this later." It’s not a no, just a delay. The server accepts the message but queues it for retry. That’s why 4.7.28 often shows up in bulk sends or when servers are under load. But if you see high 4.7.28 rates across your list (say, over 10% of sends), it’s a sign of trouble—either poor email hygiene, outdated addresses, or a sender reputation issue.

Let’s be clear: delays aren’t free. High 4.7.28 rates correlate with slower delivery times and lower open rates. If people don’t open your email within 24 hours, open rates drop sharply. Over time, even temporary bounces like 4.7.28 can degrade your sender reputation. That’s why you should clean your list before sending—especially if you’re running high-volume campaigns.

Why 550 5.7.1 is a red flag you can’t ignore

Unlike 4.7.28, a 550 5.7.1 means Gmail actively rejected your message. It’s not a retry—this is a stop. More often than not, this error shows up when your domain, IP address, or sending behavior is flagged as suspicious. The cause could be past spam activity, a history of high bounce rates, or missing authentication (SPF/DKIM/DMARC).

According to Google’s own documentation on email delivery errors, 550 5.7.1 is reserved for messages deemed abusive or unauthorized—often linked to known spam sources. If your IP or domain is on a blocklist, even a single 550 5.7.1 can signal deeper problems. You’ll want to check your IP reputation using tools like MxToolbox or Spamhaus, and re-evaluate your sending practices.

If you’re unsure whether that 550 5.7.1 is a one-off or a pattern, use MailTester’s real-time verification API or bulk list check to identify invalid or risky addresses before sending. With 98.9% accuracy, it’s one of the best ways to preempt these issues. You can test your full list today at MailTester’s bulk verification tool.

How to test inbox placement before sending

Send to real Gmail servers before sending to real users. Use inbox-placement testing with MailTester to catch 4.7.28 and 550 5.7.1 errors early. These SMTP codes mean your email was rejected — 4.7.28 for content policy issues, 550 5.7.1 for spam or policy violations. Simulating delivery in advance lets you catch and fix these issues before they harm your sender reputation or waste sends.

Simulate real Gmail delivery with inbox tests

Let’s be clear: testing with a dummy address or a “valid” email checker won’t catch Gmail’s real-time decisions. You need to test against actual Gmail infrastructure. MailTester’s inbox placement test does this by sending a real test email to Gmail’s servers and returning the exact SMTP response — including 4.7.28 or 550 5.7.1 — as it happens.

This is how you find out if an address is blocked not by a syntax error, but because of how Gmail evaluates your email’s content, sender reputation, or authentication.

  1. Run a full inbox test for your list with MailTester’s inbox placement tool. It connects directly to Gmail’s SMTP servers and mimics an actual send. This captures real-time feedback — no simulations, no heuristics.
  2. Review the precise error codes returned. A 4.7.28 means Gmail rejected your message due to content policy — often triggered by links, language, or flagged patterns. A 550 5.7.1 means the sender is blocked or the message violates Gmail’s spam policies. This isn't guesswork — it's raw SMTP feedback.
  3. Flag and remove problem addresses before sending. If an address returns 550 5.7.1 or 4.7.28, it’s not just undelivered — it’s actively blocking your reputation. Removing such addresses prevents hard bounces and reduces the chance of your domain being marked as untrusted by Gmail's filters.
  4. Use the same test for new campaigns. Every send is a reputation bet. Testing inbox placement before every major send lets you verify that content, domain, and sender identity align with Gmail’s current policies.

Even an address that passes basic syntax checks can fail delivery due to content policy. A 2022 report from DMCA found that 35% of email rejections from major providers were due to content flags rather than syntax or authentication issues. This is why real SMTP testing matters.

You can run inbox tests on your entire list through MailTester’s inbox tester, or integrate it into your workflow via the real-time verification API. Every test uses real Gmail servers and returns real SMTP codes. No guesswork.

Testing inbox placement isn’t about finding “valid” addresses. It’s about finding which ones Gmail will actually accept.

Can you prevent 550 5.7.1 errors with list hygiene?

You can significantly reduce 550 5.7.1 errors—commonly linked to spam and policy violations—by tightening your list hygiene. These errors often appear when sending to invalid, compromised, or role-based addresses that trigger rejection at the recipient’s mail server. Cleaning your list upfront with real-time verification stops these sends before they happen.

Why 550 5.7.1 strikes hard

The 550 5.7.1 error is a hard failure, meaning the email was rejected outright by the receiving server. It frequently signals that the address doesn’t exist, is a role account (like admin@ or sales@), or has been flagged for abuse. Sending to such addresses doesn’t just waste bandwidth—it can harm your sender reputation. ISPs like Gmail and Microsoft monitor engagement and bounce rates closely. One bad send can push your domain into a blacklist, hurting deliverability for everyone on the same IP.

Verification is your first line of defense

Let’s be clear: you can’t prevent all 550 5.7.1 errors after you send—but you can stop most of them before they happen. Real-time email verification checks domain validity, syntax, and mailbox existence using SMTP-level checks. Tools like MailTester catch non-existent emails, role-based addresses, and disposable domains before they ever hit your sending queue. This reduces hard bounces, keeps your bounce rate under 0.5% (a key benchmark for deliverability), and protects sender reputation.

MailTester’s bulk verification service checks 98.9% of addresses with high precision, using real-time SMTP validation and pattern analysis. You can start with 100 free verifications—no risk, no expiration—before scaling up. Bulk verification integrates seamlessly with platforms like Mailchimp, HubSpot, and Klaviyo, so you’re not pulling data from one tool to another.

For continuous checks, the real-time API validates emails as they’re collected. This ensures every new subscriber is clean, even when you’re building lists through forms or sign-up flows. You’re not waiting until a campaign fails—your list is clean on entry.

When it comes to deliverability, prevention is better than recovery. A single 550 5.7.1 error isn’t a dealbreaker—but repeated ones are. Maintaining a healthy sending reputation means not just sending to real people, but avoiding the risk altogether. Pricing is flexible, and credits never expire, so you can verify at scale without a time crunch.

For context on how spam filters treat problematic patterns, see the SMTP RFC 5321, which defines how mail servers handle rejection codes like 550. This foundation is why verifying addresses matters at the protocol level—not just for email tools, but for every email that touches the internet.

What does 'catch-all' or 'risky' mean in email verification?

When an email address is marked as 'catch-all' or 'risky', it means the address is technically valid but comes with high delivery risk. Catch-all addresses accept any email, making them prone to spam abuse, and Gmail flags them as unsafe. Risky addresses often indicate disposable domains, role accounts (like admin@ or sales@), or patterns used in spoofing—common reasons for Gmail’s 550 5.7.1 rejection. These verdicts signal likely rejection, especially under stricter filters like Gmail’s.

Catch-all addresses are a delivery red flag

A catch-all address is set up to receive mail sent to any email on the domain, even nonexistent ones. This makes it a magnet for spam. While it might pass basic syntax checks, it violates Gmail's security policies. You’ll often see these marked as 'catch-all' in verification tools like MailTester, meaning the recipient server will likely reject your message—especially if it comes from an unfamiliar sender.

The practice is common in outdated or poorly managed systems. Gmail, in particular, treats these addresses as high risk. Sending to them increases spam score, hurts sender reputation, and often triggers a 550 5.7.1 error. This is far worse than a simple bounce—Gmail actively blocks senders that target such addresses.

For this reason, removing or deprioritizing catch-all addresses from your list improves deliverability. Tools like MailTester identify them accurately, using real-time SMTP checks and MX validation. You can verify a full list at MailTester's bulk verification to clean your database before sending.

Risky addresses can sabotage deliverability

Risky addresses aren’t necessarily invalid—they may be syntactically correct—but they signal higher likelihood of abuse. These include disposable email domains (like temp-mail.org), role-based accounts (no one manages support@), or patterns mimicking internal systems (e.g., [email protected] on a public domain).

Spammers frequently use disposable domains or fake role accounts to test or harvest data. This is why Gmail and other major providers use heuristics to flag such addresses, often returning a 550 5.7.1 response—not because the address is wrong, but because the system sees it as part of a risk pattern.

Let’s be clear: a 'risky' tag isn’t a hard block, but it’s a strong warning. Sending to these addresses inflates your spam score and harms your sender reputation. The longer you send to them, the more likely you’ll hit blacklists or get throttled by Gmail’s filters.

MailTester’s system detects these risks using a combination of domain reputation analysis and pattern matching. Use the real-time verification API to filter out risky addresses during sign-up or CRM sync. You can also test how your messages land in real inboxes with inbox placement testing.

For context, RFC 5321 (the SMTP standard) defines how mail servers handle invalid recipients, and Gmail follows strict interpretations. This makes early detection critical. Ignoring risky or catch-all addresses increases the odds of a 550 5.7.1 failure—so fix it before it happens.

How MailTester helps manage 4.7.28 and 550 5.7.1 risks

4.7.28 and 550 5.7.1 are both SMTP rejection codes from Gmail, but 550 5.7.1 (commonly tied to spam or policy violations) is worse because it often indicates a hard block—your IP or domain may be flagged. 4.7.28 is a transient error, meaning Gmail will retry delivery, but repeated occurrences still hurt sender reputation. MailTester helps by filtering out emails that trigger these rejections before they’re sent, reducing the risk of damage to your inbox placement.

What MailTester actually does to stop these issues

  • You can run bulk verification on your email list via MailTester’s bulk verification tool to catch invalid, catch-all, or role-based addresses that are more likely to cause 550 5.7.1 errors.
  • The real-time API at MailTester’s verification API checks individual addresses on the fly—ideal for lead capture or signup flows—blocking known risky or disposable domains before they ever reach Gmail.
  • MailTester flags catch-all addresses (which often appear as "valid" but aren’t usable) and disposable domains, both of which increase the chance of bounce rates and reputation damage that trigger 4.7.28 and 550 5.7.1.
  • By identifying and removing such addresses early, MailTester reduces the number of failed deliveries and reduces the strain on your sending infrastructure—important since repeated sending to invalid addresses can lead to blacklisting.
  • You can test deliverability using MailTester’s inbox placement tester to see how your emails land in real inboxes across Gmail, Outlook, and other providers—before you send to thousands.

Pricing and long-term value

  • MailTester gives you 100 free verifications to start, and any purchased credits never expire—so you can use them over time as your list grows or changes.
  • You don’t need to rush through credits. This is especially useful if you’re maintaining a list over months, as email address validity drops over time—up to 40% within a year in some industries.
  • Integrating with tools like Mailchimp, Klaviyo, or SendGrid through MailTester’s integrations means your list stays clean without manual work.
  • Real-time feedback on email validity helps you avoid the kind of high bounce rates that lead to Gmail’s 550 5.7.1 response, especially when your sender reputation is on the line.

Think of MailTester as a gatekeeper: it doesn’t just check if an email works—it tells you whether it’s worth sending to at all. By catching the problem addresses early, you keep your deliverability high and your reputation intact.

In conclusion: which error is worse?

The 4.7.28 transient error isn’t a hard block, but it reflects delivery stress. If ignored, repeated failures can trigger permanent rejections like 550 5.7.1.

The 550 5.7.1 error is worse in the moment: it stops delivery entirely. But both are symptoms of deeper problems—poor list hygiene, outdated addresses, or sender reputation issues.

Preventing these issues starts before sending. Validating your list upfront stops bounces and blocks before they occur.

Sources

Keep reading

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Is Gmail 4.7.28 a bounce or just a delay?

4.7.28 is a temporary delay, not a bounce. Gmail retries delivery before giving up. It does not count as a hard bounce.

Why does Gmail return 550 5.7.1 sometimes for valid addresses?

This can happen due to sender reputation issues, recent spam reports, or if the domain has known policy violations.

Can 4.7.28 errors be fixed by resending?

Resending after a 4.7.28 may help if the issue was temporary, but repeated deferrals require sender-level corrections.

How does MailTester handle 550 5.7.1 issues?

It identifies invalid or high-risk addresses before they hit Gmail’s filters, reducing the chance of 550 5.7.1 errors.

Are all 550 codes equally bad?

No—550 5.7.1 specifically indicates Gmail policies. Other 550 codes may reflect recipient domain issues or syntax errors.

Why do some deferrals turn into rejections?

Repeated 4.7.28 responses may trigger Gmail to suspect sender behavior, leading to eventual hard rejection.

Does a high 421 error rate mean my server is down?

421 usually indicates temporary server unavailability, but high rates point to larger infrastructure or reputation issues.

Can role accounts cause 550 5.7.1 errors?

Role accounts (like admin@ or sales@) may trigger 550 5.7.1 if they are known for spam or abuse, especially if the domain is new.

How often should I verify my email list?

Verify at least monthly, or before every major send. List accuracy drops over time due to inactivity and turnover.

Do disposable emails cause 550 5.7.1 errors?

Directly, no—but sending to disposable domains increases the risk of being flagged for spam and harms sender reputation.

What’s the best way to test Gmail deliverability?

Use inbox placement testing with real Gmail accounts and servers—MailTester provides this by sending to actual Gmail inboxes.

Can poor deliverability cause 4.7.28 errors?

Yes—senders with low reputation or high complaint rates often get rate-limited or deflected by Gmail’s systems.