What 550 5.7.1 Means
550 5.7.1 is 'delivery not authorized, message refused.' Per RFC 7372, this is the receiver telling you their anti-abuse policy rejected the message. The cause varies — could be IP reputation, sender domain reputation, content fingerprint matching known spam, missing or failing authentication, or a custom recipient policy.
Every major receiver. Gmail, Microsoft 365, Yahoo, and most enterprise gateways return 550 5.7.1 for any policy-class rejection. The text after the code varies significantly: 'message rejected as spam', 'sender denied', 'IP not authorized for this domain', 'unable to relay', etc.
Sending IP has poor reputation or is blocklisted; sender domain has poor reputation; content matches a known spam fingerprint; SPF, DKIM, or DMARC failed; sending volume to this domain exceeded a policy threshold; or a custom recipient-side filter (transport rule) rejected the message.
How to Fix 550 5.7.1
- 1
Read the descriptive text after 5.7.1
5.7.1 is a category code. The text after tells you the specific cause. Common variants: 'message rejected as spam' (content-based), 'unauthenticated email' (authentication-based), 'unable to relay' (destination mismatch), 'sender denied' (sender on blocklist). Each has a different remediation path.
- 2
Verify SPF, DKIM, and DMARC pass for your domain
Authentication failures are the #1 cause of 550 5.7.1 for cold email. Run the Email Deliverability Test at coldrelay.com/tools/email-deliverability-test against your sending domain. All three must pass for major receivers. If any fail, fix DNS first — that's the easiest cause to remediate.
- 3
Check IP reputation
Run the Blacklist Checker at coldrelay.com/tools/blacklist-checker against your sending IP. If listed on Spamhaus (SBL, XBL, CSS) or another major blocklist, follow the delisting process for that list. Don't keep sending while listed — every send while listed reinforces the listing.
- 4
Check domain reputation
For Gmail recipients, Google Postmaster Tools shows your domain's reputation tier (High, Medium, Low, Bad). For Microsoft, the SNDS dashboard shows IP reputation. If your domain reputation is below 'Medium', sustained 550 5.7.1 is expected — remediate by cutting send volume and improving content engagement.
- 5
Review your message content
Some 550 5.7.1 are content-based — your message matches a known spam pattern. Common triggers: spammy subject lines ("Re: re: re: ", "You won't believe..."), heavy use of emoji in subject, link-shorteners (bit.ly, t.co), all-image content with no text, or HTML/text mismatch. Use the CAN-SPAM Checker at coldrelay.com/tools/can-spam-checker to audit.
- 6
Reduce volume to the affected receiver
If 550 5.7.1 is concentrated at one receiver (e.g. all Gmail recipients), cut your daily send volume to that receiver by 50%. Sustained volume against a degraded reputation accelerates the damage. Let reputation rebuild over 2-4 weeks at lower volume, then ramp back up gradually.
Note: ColdRelay's 2/day/mailbox cap is set specifically to stay below reputation thresholds. Exceeding it is the #1 cause of 550 5.7.1 we see.
- 7
Consider switching to dedicated infrastructure
If you're on shared-IP infrastructure, your reputation is contaminated by other senders. The only structural fix is dedicated IPs. ColdRelay provides dedicated IPs per customer on isolated Azure tenants — your reputation is entirely your own and isolated from anyone else's behavior.
References
- ◇
- ◇Google Postmaster Tools
Domain and IP reputation visibility for Gmail recipients.
- ◇Microsoft SNDS (Smart Network Data Services)
IP reputation visibility for Outlook/Microsoft 365 recipients.
550 5.7.1 in the Cold Email Context
550 5.7.1 is the cold email sender's daily companion — it covers everything from authentication failures to reputation problems. The breakdown by cause is: about 40% authentication (SPF/DKIM/DMARC misconfigured), 35% IP/domain reputation, 20% content-based, 5% custom recipient policies. Each has a different fix. The structural infrastructure fix that addresses authentication AND reputation simultaneously is dedicated IPs with auto-configured SPF/DKIM/DMARC. ColdRelay's provisioning writes all three DNS records automatically when a domain is set up, and your dedicated IP's reputation is yours alone — no other customer's spam contaminates your reputation.
Frequently Asked Questions
Is 550 5.7.1 always about IP reputation?
No. 5.7.1 is a broad policy category covering reputation, authentication, content, and custom rules. The descriptive text after the code is what tells you the specific cause. Don't assume reputation without reading the text.
Can I appeal 550 5.7.1?
Sometimes. Microsoft has a delisting form at sender.office.com/snds. Gmail's appeals go through Postmaster Tools (reputation can recover with behavior changes; there's no direct unblock). Most other receivers don't have an appeal process — fix the underlying cause and the receiver's policy will reverse on its own.
How long until 550 5.7.1 stops if I fix the cause?
Depends on the cause. Authentication fixes: hours (once DNS propagates). Blocklist delisting: hours to days. Reputation recovery: 2-6 weeks of consistent good behavior. Content fixes: immediate next send.
Will switching IPs fix 550 5.7.1?
Only if reputation is the cause. If it's authentication or content, switching IPs doesn't help — the same problem will surface from the new IP. Always fix the root cause first; switch IPs only if you're moving from a contaminated shared-IP environment to dedicated infrastructure.
What's the difference between 5.7.1 and 5.7.26?
5.7.1 is a broad policy category. 5.7.26 is more specific — Gmail's enhanced code for 'unauthenticated email' under the February 2024 bulk-sender rules. 5.7.26 always indicates an authentication problem; 5.7.1 can indicate many things.