SMTP 550 5.7.1 Message Rejected: Causes and Fixes

A 550 5.7.1 reply means the receiving mail server permanently rejected your message because of a policy decision, not because the mailbox is missing. The first digit 5 marks a permanent failure, and the enhanced code 5.7.1 means delivery is not authorized: the receiver does not like something about the sender, the sending IP or the message.

You see it in a bounce (non-delivery report) in the sender's inbox, in your mail server log as status=bounced, or in the response from your transactional email provider. The text after the code is the important part, since different providers use 5.7.1 for different reasons.

550-5.7.1 Unauthenticated email from example.com is not accepted due to the domain's DMARC policy
550 5.7.1 Service unavailable; Client host [203.0.113.25] blocked using zen.spamhaus.org
550 5.7.1 Message rejected due to local policy
550 5.7.1 Unable to relay

Causes, most likely first

1. Failed authentication. SPF, DKIM or DMARC fails, and the receiver, or the recipient domain's DMARC policy, rejects the message.
2. Sending IP on a blocklist. The host or its shared IP range is listed.
3. Missing reverse DNS (PTR) or a mismatched HELO name on the sending IP.
4. Content or reputation filtering. Spammy content, a new domain, sudden volume or bad engagement.
5. Relay denied, when you submit to a server that does not allow your client to send. For that variant see SMTP 554 relay access denied.
6. Recipient-side rules, such as an allowlist that only accepts internal senders.

Step 1: read the full text of the bounce

The words after 5.7.1 decide your path. Quote the whole message from the bounce or the log, and look for a URL; large providers often link to a help page for that exact condition.

sudo grep -E "status=bounced|5\.7\.1" /var/log/mail.log | tail -n 20

Step 2: check SPF, DKIM and DMARC

If the text mentions DMARC, SPF or "unauthenticated", test your DNS records. Run the domain through the Email DNS Checker and the SPF रिकॉर्ड चेकर, then inspect them directly:

dig +short TXT example.com | grep -i spf
dig +short TXT _dmarc.example.com
dig +short TXT selector1._domainkey.example.com

Common problems:

• No SPF record, or the sending service is not included. Add its include: (check your provider's documentation for the exact value).
• More than one SPF record, or more than 10 DNS lookups, which causes a permanent SPF error. See fix SPF too many DNS lookups.
• DKIM not enabled for the sending service, or the selector record missing. See DKIM setup and troubleshooting.
• DMARC p=reject or p=quarantine with neither SPF nor DKIM aligned to your From domain. Alignment means the domain that passes must match the visible From domain.

The SPF and DMARC Generator can help write valid records, and SPF, DKIM and DMARC complete guide explains alignment.

Step 3: check blocklists and reverse DNS

If the text names a DNSBL such as Spamhaus, check your sending IP with the Blacklist Checker. Follow the listing's removal process after you fix the cause; delisting without fixing the problem leads to relisting. See email blacklist removal guide.

Then verify the PTR record:

dig +short -x 203.0.113.25
dig +short A mail.example.com

The PTR should return a hostname that resolves back to the same IP, and your server's HELO should use that hostname. See reverse DNS (PTR) for email. On a shared or cloud IP, you often set PTR in the provider's control panel, not in your DNS zone.

Step 4: bulk sender requirements

Large receivers publish requirements for senders of high volume, which commonly include SPF and DKIM, a DMARC policy, valid reverse DNS, TLS and easy unsubscribe for marketing mail. Check the current requirements on Gmail's and Microsoft's sender guidelines pages, since they change.

Step 5: content and reputation

If authentication and IP checks all pass, look at the message: link shorteners, mismatched URLs, heavy images with little text, attachments with executable types, or a sudden volume jump from a new domain. Warm up new domains gradually; see email warmup for a new domain. Send a test through the ईमेल डिलीवरेबिलिटी टेस्ट and fix the issues it reports. If you still get rejected, contact the receiving provider's postmaster team with the bounce text, your IP and a timestamp.

How to verify

Send a new test message to an address at the same receiving provider and confirm delivery. In the received message, view the original headers and check for spf=pass, dkim=pass and dmarc=pass in the Authentication-Results header. Re-run the Blacklist Checker और Email DNS Checker. To keep an eye on the records themselves, see email bounce codes explained.

अगले कदम

• Run the Email DNS Checker on your sending domain.
• Test deliverability with the ईमेल डिलीवरेबिलिटी टेस्ट.
• Check your IP on the Blacklist Checker.
• Read email going to spam fix.

सामान्य प्रश्न

Is 550 5.7.1 a temporary error?

No. 5xx codes are permanent for that message, so retrying the same message unchanged will fail again. Fix the cause, then send again.

Does 5.7.1 always mean spam?

No. It means "not authorized by policy". Authentication failures, relay restrictions, blocklists and recipient allowlists all use it.

Why does it only happen to Gmail or Microsoft recipients?

Large providers enforce stricter authentication and reputation policies than small servers do. Their bounce text usually links to the exact reason.

My SPF passes. Why does DMARC still reject?

DMARC needs alignment, not just a pass. The domain authenticated by SPF or DKIM must match the From domain you display.

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.