SMTP error 521: What it means and how to fix it
SMTP error 521 overview:
- SMTP 521 is a permanent block: Delivery won’t succeed until something changes.
- Rule out the recipient first: Pause sends and confirm they can receive messages.
- If they can, it’s likely blocklisting: Fix the cause, then complete the delisting process.
- If they can’t, it’s recipient-side: Remove the address or domain from your mailing lists.
SMTP error 521 indicates the receiving server doesn’t accept messages, or more commonly, that your sending domain or IP address has been blocklisted. This permanent failure means your email won’t be delivered until the underlying issue is resolved.
Want fewer 521 blocks?
Authentication gaps can hurt sender reputation over time, which increases the risk of blocklisting. Sendmarc helps you keep SPF, DKIM, and DMARC aligned across your domains, so you can reduce avoidable reputation damage.
What SMTP error 521 means
A 521 error typically means “Server does not accept mail” or indicates that your domain/IP address has been blocked.
This is a permanent failure code (5xx), so your email server won’t automatically retry. You need to verify the server configuration or address the blocklisting before emails can be delivered.
Common causes of SMTP error 521
- Server doesn’t accept email: The destination server isn’t configured to accept email
- IP blocklisting: Your sending IP is on a blocklist, possibly due to:
- Abuse reports: High complaint rates led to blocking
- Delivery issues: Too many messages are bouncing
- Suspicious behavior: Sending patterns have changed significantly
- Poor sender score: Low reputation triggered rejection
Provider-specific 521 error
La Poste
| Error message | Meaning |
|---|---|
| 521 5.7.1 – Service unavailable | Your IP is blocklisted |
How to fix SMTP error 521
Step 1: Confirm the recipient server is accepting email
SMTP error 521 can mean the destination server isn’t configured to accept messages. If this is isolated to a specific server, it might be a recipient-side issue.
- Pause sending to that address or recipient domain
- Contact the recipient via another channel to confirm they can receive messages
If the recipient confirms the address/domain isn’t set up to receive email, permanently remove it from all sending lists to prevent repeated bounces and protect your sending reputation.
Step 2: Check your reputation
Confirm whether your sending domain or IP has been blocklisted.
Use Sendmarc’s blocklist checker tool to see whether your domain or IP is listed, and which blocklists it appears on.
Step 3: Identify what triggered the listing
First, confirm whether the listed IP or domain is currently sending email. If it is, look back at what changed recently, for example, a new campaign, a sudden jump in list size, or a new third-party platform/tool sending on your behalf.
Then work through the most likely drivers:
- Clean up your lists (remove unknown, inactive, or long-unengaged recipients)
- Validate how contacts were added and whether you have clear permission to email them
- Check for signs of unauthorized sending (compromised accounts or systems)
Step 4: Follow the delisting process for each blocklist
Delisting isn’t one-size-fits-all – each blocklist handles removals differently. Some will ask you to complete a form, others accept an email submission, and a few will drop the listing automatically once your sending remains clean for a set period.
Once you’ve requested removal (or the listing times out), re-run a blocklist check to confirm you’re delisted.
Step 5: Monitor your reputation
After delisting, maintain good standing:
- Google Postmaster Tools: Monitor Gmail reputation
- Microsoft SNDS: Track Outlook reputation
- Regular blocklist checks: Review weekly
Email authentication and SMTP error 521
Proper authentication helps prevent blocklisting and improves delivery.
SPF
SPF (Sender Policy Framework) tells receiving servers which IPs can send on behalf of your domain.
Example SPF record:
| Host | Type | Value |
|---|---|---|
@ | TXT | v=spf1 ip4:192.168.0.1 include:mail.example.com -all |
DKIM
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to verify message authenticity.
Example DKIM record:
| Host | Type | Value |
|---|---|---|
selector._domainkey.yourdomain.com | TXT | v=DKIM1; k=rsa; p=[public key] |
DMARC
DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells receiving servers how to handle unauthenticated email and provides reporting.
Example DMARC record:
| Host | Type | Value |
|---|---|---|
_dmarc.yourdomain.com | TXT | v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; fo=1; |
How Sendmarc helps you stay authenticated
Getting SPF, DKIM, and DMARC right isn’t a once-off task. Records change, new sending services get added, and small DNS mistakes can quietly break authentication – often before anyone notices. Sendmarc gives you an ongoing view of your authentication posture so you can catch issues early and reduce the risk of trust and delivery problems.
Sendmarc helps you:
- Reduce spoofing and impersonation risk by strengthening authentication
- Detect compromised accounts and suspicious sending activity earlier
- Improve visibility across all senders and domains, including third-party tools
- Minimize delivery issues caused by misconfigured or unauthenticated senders
- Support audit and compliance requirements with clear reporting and traceability
- Standardize authentication policies across teams and regions while keeping management lightweight
SMTP error 521 FAQs
How long does it take to get delisted?
Delisting time varies by blocklist. Some delistings take effect within 24 hours once you’ve fixed the cause and submitted a request, while others can take a few days.
Can I prevent 521 errors entirely?
No, you can’t prevent 521 errors entirely. You can reduce them by keeping authentication aligned, maintaining list hygiene, sending consistently, honoring unsubscribes quickly, and monitoring reputation. But some 521 blocks can still happen due to the recipient’s server configuration.
Should I remove addresses that return 521 errors?
No, not immediately. Pause sending to those recipients and ask them to confirm whether their mailboxes can receive messages. If they can, check whether your sending IP or domain is blocklisted, fix the underlying issue, and confirm delisting before you resume sending.