How to Fix Hard Bounces: A Developer’s Troubleshooting Guide

Hard bounces are permanent delivery failures—but knowing how to fix hard bounces means separating bad recipient data from correctable DNS, authentication, policy, and application problems. The SMTP response, enhanced status code, and point of rejection tell you which action to take.

What a hard bounce actually means

A bounce is a delivery status notification (DSN) or provider event indicating that a receiving mail system did not accept a message. In everyday email operations, a hard bounce usually means the sender should not retry the same recipient automatically because the failure is considered permanent.

The word “hard” is useful operational shorthand, but it is not a formal SMTP protocol category. SMTP itself distinguishes between temporary and permanent failures using the first digit of its reply code:

• 4xx responses mean a temporary failure. The recipient server may accept the message later, so the sending server should retry according to its queue policy.
• 5xx responses mean a permanent failure for that delivery attempt. The sender should not blindly keep retrying.

A response such as 550 5.1.1 User unknown is the classic hard bounce: the mailbox does not exist, is no longer provisioned, or the recipient system cannot resolve that address. But not every 5xx response means “delete this customer forever.” A 550 5.7.1 policy rejection, for example, may be caused by an SPF, DKIM, DMARC, reputation, content, or sender-identity issue that you can fix.

The practical rule is:

Suppress an address immediately when the receiving system confirms that the mailbox or destination domain is invalid. Investigate and correct sender-side problems before suppressing otherwise valid recipients.

That distinction prevents two costly mistakes: repeatedly mailing nonexistent inboxes and incorrectly blocking real customers because your own authentication or sending configuration was broken.

Start with the complete SMTP diagnostic

Do not troubleshoot from a dashboard label alone. Labels such as “hard bounce,” “rejected,” or “failed” are convenient summaries, but the original SMTP response is the evidence you need.

Capture as much of the following as your provider exposes through events, webhooks, message logs, SMTP relay logs, or REST API responses:

1. The three-digit SMTP code, such as 550, 551, 553, or 554.
2. The enhanced status code, such as 5.1.1, 5.2.1, 5.4.1, or 5.7.1.
3. The receiving server’s human-readable text.
4. The recipient domain and MX host that issued the response.
5. The stage of the SMTP transaction where the failure occurred.
6. The envelope sender (MAIL FROM) and visible From: domain.
7. The message ID, event timestamp, IP address or sending pool, and authentication results when available.

A raw relay transcript might look like this:

C: MAIL FROM:<bounces@bounce.example.com>
S: 250 2.1.0 OK
C: RCPT TO:<alex@customer-example.net>
S: 550 5.1.1 <alex@customer-example.net>: Recipient address rejected: User unknown

This is a recipient-specific hard bounce. The server rejected the address during RCPT TO, before it accepted the message body. Suppress that exact address after recording the reason.

Compare it with a rejection after the content is transmitted:

C: RCPT TO:<alex@customer-example.net>
S: 250 2.1.5 OK
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: [message content]
C: .
S: 554 5.7.1 Message rejected due to unauthenticated sender

The recipient was accepted, but the final message was rejected due to sender authentication. This may be classified as a hard bounce by your provider, yet the recipient address is not necessarily bad. Fix the sender configuration first; do not automatically treat every recipient who received this error as invalid.

Read the code in layers

The three-digit SMTP code provides the broad outcome. The enhanced code gives better detail.

• The first enhanced digit is the class: 2 success, 4 temporary failure, 5 permanent failure.
• The second digit identifies the subject area, such as address status (1), mailbox status (2), mail system status (3), network or routing status (4), protocol status (5), and security or policy status (7).
• The third digit narrows the cause.

For example, 5.1.1 is typically “bad destination mailbox address,” while 5.7.1 is a security or policy rejection. The text around a code is not perfectly standardized across receiving systems, so use the code, stage, domain pattern, and text together.

Classify the hard bounce before acting

A useful bounce policy has categories, not one catch-all “failed” bucket. Create a classifier that stores the raw response and maps it to an action. This makes suppression reliable, keeps your metrics honest, and avoids losing valid recipients when a domain-wide configuration issue occurs.

Category 1: Invalid mailbox or recipient

Common examples include:

550 5.1.1 User unknown
550 5.1.1 Recipient address rejected
550 5.1.10 Recipient not found
553 5.1.3 Bad destination mailbox address syntax

Typical causes are a typo, an employee leaving a company, an account closure, an invalid alias, a stale CRM record, or a customer entering an address incorrectly.

Action: Suppress the exact normalized recipient address. Do not send future transactional or campaign messages to it until the user supplies and verifies a replacement address.

Be careful with aliases and catch-all domains. A recipient domain might accept any local part during SMTP and discard or route messages later. Conversely, an address can be real but temporarily unavailable due to a recipient organization’s directory or migration problem. If a specific address has historically received mail and suddenly returns a recipient-not-found response, retain the history and consider asking the user to update their address through another verified channel.

Category 2: Invalid or non-mail-enabled domain

Examples include:

550 5.1.2 Bad destination system address
550 5.4.4 Unable to route
554 5.4.4 No valid MX records

The domain may be misspelled, expired, nonexistent, or configured not to accept mail. A destination can also publish a null MX record—an MX record with priority 0 and target .—to explicitly state that it does not receive email.

Action: Suppress the address if the domain is genuinely nonexistent or explicitly does not accept mail. Before doing so, check whether the user simply mistyped a common domain, such as gmial.com instead of gmail.com, but never silently rewrite the address and send to the guessed destination without user confirmation.

Category 3: Sender authentication failure

Examples include:

550 5.7.1 SPF fail
550 5.7.1 DKIM signature did not verify
550 5.7.1 DMARC policy rejection
554 5.7.1 Message rejected due to sender policy

These are often reported as permanent failures because the recipient server will continue rejecting similar messages until something changes. The recipient address may still be completely valid.

Action: Pause or reduce affected traffic, verify DNS and domain alignment, send controlled test messages, then retry only messages that remain relevant. Do not suppress every recipient that encountered the rejection.

Category 4: Reputation, abuse, or content policy rejection

Examples include:

550 5.7.1 Message rejected as spam
554 5.7.1 IP address blocked
550 5.7.1 Sending domain has poor reputation

These failures can result from sudden volume changes, high complaint rates, poor list quality, compromised credentials, malware-like links, deceptive message content, missing unsubscribe mechanisms for marketing mail, or a shared IP pool with a poor reputation.

Action: Treat this as a sending-program incident, not a recipient-data issue. Stop repeatedly retrying rejected traffic, inspect recent changes, check authentication, examine complaint and bounce trends, and contact the receiving-domain postmaster channel or your email provider if the problem is persistent and evidence supports a false positive.

Category 5: Address syntax and application bugs

Examples include:

553 5.1.3 Mailbox name not allowed
501 5.1.7 Bad sender address syntax
550 5.1.0 Invalid sender address

Your application may be generating malformed addresses, accepting display names where an address is required, inserting whitespace or commas incorrectly, using an invalid internationalized domain representation, or passing an empty merge field into a recipient list.

Action: Fix validation at form submission and immediately before send. Do not let one malformed database value trigger repeated send attempts from a job queue.

Fix invalid recipients at the data-source level

Suppressing a bad address in an email platform stops the immediate damage. It does not solve the system that created the bad data. If the same bad addresses re-enter through imports, signup forms, sales tools, support tickets, or application events, your bounce rate will climb again.

Normalize before you validate

At minimum, trim leading and trailing whitespace, reject control characters, require one @ separator, and split the address into local part and domain for basic checks. Preserve the original value for audit purposes, but use a normalized value for deduplication and suppression matching.

Do not apply simplistic transformations that alter mailbox meaning. The local part—the section before @—can be case-sensitive in theory and can use provider-specific conventions. Avoid removing plus tags, dots, or characters from a user’s address unless you have an explicit product reason and understand the consequences.

A minimal application-level check might reject clearly invalid inputs such as:

jane
jane@
@company.com
jane @company.com
jane@@company.com

But syntax validation alone cannot establish that jane@company.com exists. A syntactically valid address can still have no mailbox, no MX record, or a recipient-side policy that rejects it.

Verify at the right time

For account creation, high-value leads, password reset destinations, and invitation workflows, send a confirmation link and mark the address verified only after the recipient completes the action. This is the most reliable proof that the inbox can receive mail and that the user controls it.

For list imports, use layered checks:

• Validate syntax and domain spelling before import.
• Check DNS and MX availability.
• Flag role addresses such as admin@, support@, or sales@ according to your organization’s rules.
• Compare against your existing suppression list before queuing sends.
• Use a reputable verification service when the business case justifies it, while recognizing that mailbox-level probing can be inconclusive or intentionally blocked.

A free address check can be useful as an early filter; for example, use an email verification tool before adding a newly collected address to a high-volume workflow. Treat any verifier result as a signal, not a guarantee: only a recipient’s successful confirmation conclusively proves control of the mailbox.

Keep a durable suppression list

Store suppressions centrally, not only inside a single campaign tool. A durable record should include the normalized address, raw address, event time, SMTP code, enhanced status code, response text, provider message ID, source system, and whether the suppression is recipient-specific or domain-wide.

A practical policy looks like this:

Use a stable identifier for the recipient record as well as the email address. That lets your product prompt the user to update an email address without silently reactivating an address that previously hard bounced.

Repair SPF, DKIM, and DMARC failures

Authentication-related hard bounces are among the most fixable causes of “permanent” failures. They also affect more than a single delivery: a broken record can cause broad rejection across many recipient domains.

SPF: authorize every legitimate sender

SPF is a DNS TXT policy for the envelope sender domain. It tells receiving servers which hosts are allowed to send mail using that domain in the SMTP MAIL FROM command.

A generic SPF record for a domain using an authorized sending service might look like this:

example.com. IN TXT "v=spf1 include:spf.your-email-provider.example -all"

The include: value must be the exact hostname published by your email provider. Do not copy an example hostname into production. If you also send through Google Workspace, Microsoft 365, an application server, or another platform, combine their authorized mechanisms into one SPF TXT record rather than publishing multiple v=spf1 records.

For example, the structural pattern is:

example.com. IN TXT "v=spf1 include:provider-one.example include:provider-two.example ip4:203.0.113.25 -all"

Only include IP addresses that you operate and that are stable. An incorrect ip4 mechanism can authorize an unrelated system; an obsolete include: can add DNS lookups and complexity without helping delivery.

SPF evaluation has a DNS-lookup limit of 10. Nested include:, redirect=, a, mx, exists, and ptr mechanisms can consume that budget. If the evaluation exceeds the limit, receivers can return an SPF permanent error. Use an SPF lookup checker, simplify unused services, and test the fully expanded policy rather than counting only the mechanisms in your top-level record.

DKIM: publish the exact selector record

DKIM signs a message with a private key and lets recipients retrieve the public key from DNS. The sending service adds a header containing values such as d= for the signing domain and s= for the selector.

If the message header says:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; ...

the verifier looks up this DNS name:

s1._domainkey.example.com

A TXT-based DKIM public key record has a form similar to:

s1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Many providers instead ask you to publish CNAME records that point to provider-managed DKIM records. Both approaches can be valid. Use the exact record type, host, and value supplied by the system that signs your mail; changing a TXT record into a CNAME, removing quote handling, pasting an incomplete public key, or publishing the selector under the wrong domain will break verification.

Check a received test message rather than DNS alone. Inspect the Authentication-Results header and confirm that dkim=pass, that the signing domain is expected, and that the selector resolves. A key can exist in DNS while the message is signed with a different selector or domain.

DMARC: make authentication align with From

DMARC evaluates whether SPF or DKIM passes and aligns with the visible RFC 5322 From: domain. This is why “SPF passes” by itself may not prevent a DMARC rejection when your visible From domain differs from the envelope sender domain.

A starting DMARC record can be:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100"

p=none requests monitoring rather than enforcement. It is a sensible first step when you need to discover every service that sends on behalf of your domain. Review aggregate reports, fix unauthorized or misconfigured senders, then consider moving toward p=quarantine or p=reject based on your risk tolerance and operational readiness.

If you send application mail through a REST API or SMTP relay, make sure the platform is configured to sign with your domain or an aligned subdomain. A common safe pattern is to use a dedicated subdomain for transactional mail, such as notify.example.com, while keeping visible From addresses consistent with the domain strategy you have authenticated.

Google’s sender requirements make authentication especially important: all senders to personal Gmail accounts need SPF or DKIM, and higher-volume senders must meet SPF, DKIM, and DMARC requirements. Authentication should therefore be treated as baseline infrastructure, not as a late-stage deliverability optimization.

Verify DNS and message authentication independently

DNS changes can be correct in the control panel but wrong on the public internet because of an incorrect zone, delegated nameserver, typo, cached record, or conflicting record. Verify what resolvers actually return.

Useful command-line checks

On macOS or Linux, use dig:

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT s1._domainkey.example.com
dig +short MX customer-example.net

On Windows PowerShell, use:

Resolve-DnsName -Type TXT example.com
Resolve-DnsName -Type TXT _dmarc.example.com
Resolve-DnsName -Type MX customer-example.net

For a destination domain, check that MX hosts exist and resolve to A or AAAA records. Do not confuse your own sending-domain authentication records with the recipient’s MX records: SPF, DKIM, and DMARC publish who may send as your domain, while MX records tell other systems where to deliver inbound mail for a domain.

Use external diagnostic tools

MXToolbox can help inspect MX, SPF, DKIM, DMARC, and blacklist signals. mail-tester.com can provide a practical test report for a message you send to its generated address, including authentication, content, and common configuration observations.

These tools are helpful, but they do not replace real delivery evidence. A message can score well in a generic test and still be rejected by a particular enterprise domain because that organization has its own policy, blocklist, directory, or inbound gateway configuration.

When validating a fix, send controlled messages to test accounts at multiple mailbox providers. Inspect the full headers at each destination. Record the envelope sender, visible From domain, DKIM d= value, selector, SPF result, DMARC result, and final SMTP disposition.

Diagnose domain-wide and provider-specific rejection patterns

One hard bounce is often a data-quality issue. Hundreds of hard bounces appearing within minutes are usually a configuration, reputation, or application incident.

Group failures by recipient domain, enhanced status code, raw response text, sending domain, campaign or message type, and time window. The pattern matters.

Patterns that point to recipient data

You likely have a list-quality problem when:

• Errors are dispersed across many unrelated recipient domains.
• Most responses are 550 5.1.1, 5.1.10, or malformed-recipient errors.
• The bounced records come from an old import, purchased list, manual CSV, abandoned signup flow, or stale CRM segment.
• Your own test recipients and recent verified users still receive mail normally.

The fix is to stop the affected list, suppress confirmed bad addresses, remove untrusted sources, and improve collection and verification workflows.

Patterns that point to your sender configuration

You likely have an authentication or sender-policy issue when:

• Failures begin immediately after a DNS, domain, provider, credential, or code deployment.
• The same 5.7.1 response occurs across many recipients at one mailbox provider.
• A message from one From domain fails while another domain works.
• The recipient addresses had a successful delivery history before the incident.
• Authentication headers show spf=fail, dkim=fail, or dmarc=fail.

In this case, pause nonessential sends from the affected identity. Fix the DNS or signing configuration, wait for DNS propagation according to your record TTL, validate with fresh messages, and then resume gradually.

Patterns that point to a recipient organization

A single corporate domain may reject all external senders because of an internal mail-flow issue, a temporary directory migration, an allowlist requirement, a gateway policy, or a recipient-side security product. If several known-valid users at one domain return a consistent 5.4.x or 5.7.x response, preserve the raw diagnostics and ask the recipient’s mail administrator to investigate.

Do not promise that changing email providers will solve a recipient organization’s configuration issue. Switching a REST API or SMTP relay can change the sending IP and signature path, but it cannot repair the recipient’s nonexistent mailbox, null MX declaration, or internal directory error.

Avoid retries that make hard bounces worse

Email infrastructure should distinguish delivery retries from application retries. A common bug is to treat every API error, webhook event, or failed job as retryable. That can create a loop that attempts delivery to an invalid address hundreds of times.

Build explicit retry rules

Retry only failures that are genuinely transient, such as 421, 450, 451, and 452, unless the provider has already queued delivery on your behalf. Use exponential backoff with jitter and a maximum delivery window. Avoid having both your application and your email provider independently retry the same message without coordination.

For 5xx errors, default to no automatic retry. Create narrow exceptions for known, remediated sender-side incidents. For example, if a DNS record was accidentally removed for 20 minutes and messages received 550 5.7.1 authentication rejections, it can be reasonable to resend important notifications after the record is restored and test messages pass. That is a recovery workflow, not a generic retry policy.

Preserve idempotency in your application

A password-reset request, invoice, account alert, or webhook notification should have an idempotency key or stable business event ID. If you requeue a message after a delivery error, ensure your system does not generate duplicate messages after a later successful call.

With a transactional email service, capture the message identifier returned by the REST API or emitted in SMTP-related event data. Associate it with your own notification ID, recipient ID, and suppression decision. The platform’s event stream can tell you what happened to a particular attempt; your application still needs to decide whether the business event should be retried, shown in-product, or escalated another way.

For implementation details specific to your sending method, consult your provider’s SMTP and email API documentation rather than guessing at event names or retry behavior.

Protect deliverability after a hard-bounce spike

Hard bounces are not only failed messages. They are a data-quality and reputation signal. A sudden spike can reduce trust in your sending domain or IP address, particularly when it results from poor acquisition practices or repeatedly mailing invalid recipients.

Take immediate containment steps

When hard bounces rise sharply:

1. Pause the campaign, import, integration, or job queue creating the failures.
2. Identify the first timestamp of the spike and compare it with deployments, DNS changes, list imports, and credential changes.
3. Segment by recipient domain and bounce code.
4. Suppress confirmed invalid addresses immediately.
5. Test authentication from the exact sender domain and sending path in production.
6. Review source data and remove addresses that were never confirmed or are no longer relevant.
7. Resume slowly after the root cause is verified, especially for low-engagement or older segments.

Do not try to “push through” a bounce event by increasing throughput or switching From addresses rapidly. That makes diagnosis harder and can create additional reputation concerns.

Separate transactional and promotional streams

Account-critical messages such as verification links, receipts, security alerts, and password resets should be operationally separated from newsletters and re-engagement campaigns. That can mean distinct subdomains, streams, suppression logic, and monitoring, depending on your email infrastructure.

The goal is not to evade reputation consequences. The goal is to prevent a poor-quality promotional segment from disrupting time-sensitive mail that users requested. Keep the same authentication discipline across both streams, and never use a new subdomain as a shortcut around unresolved abuse or list-quality problems.

Monitor the right metrics

Track hard-bounce rate by source, message type, sending domain, recipient domain, and acquisition cohort. Also watch delivery rate, temporary deferrals, complaints, unsubscribe rate for marketing sends, authentication pass rate, and the proportion of sends going to previously unengaged addresses.

An overall bounce percentage can hide the root cause. A 2% hard-bounce rate caused by one malformed CSV is different from a 2% rate distributed across every new account signup. The first is a batch incident; the second points to a collection or verification problem.

A practical hard-bounce runbook

Use this checklist whenever an individual message or a batch of messages hard bounces.

1. Retrieve the exact diagnostic. Save the SMTP reply, enhanced code, response text, recipient domain, message ID, and rejection stage.
2. Classify the cause. Is it an invalid mailbox, invalid domain, malformed address, authentication problem, policy/reputation block, or recipient-side routing issue?
3. Check the scope. Is the error isolated to one address, one recipient domain, one sender domain, or all traffic after a change?
4. Suppress only confirmed bad recipients. Suppress 5.1.1-style mailbox failures and invalid domains; do not suppress recipients just because your own SPF or DKIM failed.
5. Validate sender identity. Inspect live message headers and public DNS for SPF, DKIM, and DMARC; confirm DMARC alignment with the visible From domain.
6. Check recipient DNS when relevant. Look up MX records and identify NXDOMAIN or null MX conditions.
7. Stop unsafe retries. Ensure your queue does not reattempt clear 5xx recipient failures.
8. Fix the upstream source. Correct the form, import process, CRM integration, merge field, DNS record, or deployment that created the problem.
9. Test a controlled fix. Send to test mailboxes and inspect headers before resuming volume.
10. Document the incident. Keep the sample diagnostics, cause, corrective action, and prevention rule so the next event is faster to resolve.

FAQ

Is every 5xx SMTP response a hard bounce?

Not in the operational sense. A 5xx response is a permanent failure for that attempt, but some are recipient-specific (550 5.1.1 User unknown) and some are sender-side problems (550 5.7.1 authentication or policy rejection). Suppress invalid recipients, but investigate and fix sender-side failures before deciding an address is bad.

Should I retry a hard bounce?

Normally, no. Do not automatically retry invalid mailbox, invalid-domain, or malformed-address responses. You may resend a business-critical message after correcting a known sender-side cause, such as a broken DKIM record, but only after validating the fix and ensuring your application will not create duplicates.

How do I fix a 550 5.1.1 bounce?

Check the exact recipient address for a typo, confirm the domain exists and accepts mail, and ask the user for an updated address if needed. If the receiving server confirms the mailbox is unknown, suppress that exact address from future sends.

Can SPF, DKIM, or DMARC failures cause hard bounces?

Yes. Receiving systems can permanently reject mail that fails authentication or does not align with the visible From domain. Verify the live SPF, DKIM, and DMARC results in a delivered test message and publish the exact DNS records required by every authorized sending service.

What is the difference between a hard bounce and a soft bounce?

A hard bounce usually corresponds to a permanent failure, commonly an SMTP 5xx response, and usually requires suppression or a configuration fix. A soft bounce is normally temporary, commonly a 4xx response such as 421, 450, 451, or 452, and should be retried by the sending system using controlled backoff.