550 5.7.1 Sender ID (PRA) Not Permitted

550 5.7.1 Sender ID (PRA) Not Permitted

If you have seen the error 550 5.7.1 Sender ID (PRA) Not Permitted and would like a solution, you have come to the right place.

 

Whenever I have set up a domain for a customer a Sender Policy Framework (SPF) record has always naturally become an essential part of the setup. Despite this, there has been a debate within our Office and even with colleagues in the past and in the IT industry.

 

SPF records are important though as they prevent spammers from spoofing your domain. The recipient servers use your configured SPF record to check if the E-mail you have received comes from an authorised server or not. If no SPF record is present the server will decide how to treat the E-mail.

 


 

We recently had to deal with a few blocked E-mails, we were getting the error 550 5.7.1 Sender ID (PRA) Not Permitted. After performing research the cause was isolated to be in regard to an SPF record that was missing. We were unable to solve the issue but we correctly identified that the other party did not have an SPF record.

 

A great tool that can be used to lookup issues with your domain is MXToolbox. We don’t just use it to check SPF records, it is a great resource to check many aspects of a domain. Look out for a future video displaying some great tips.

 

Once we tracked down the issue we notified the company involved as they may be missing out on potential business.

Without an SPF record, the following could happen

  • Mail servers may reject your messages as they can’t determine if it is legitimate.
  • Spammers are able to spoof your domain name, send mail to other providers and damage your brand and reputation.
  • Attackers can use spoofed domain names for Malware, Ransomware and Phishing Attacks. Resulting in financial loss/fraud.

 

In truth, any single one of the reasons provided should make you implement an SPF record, now if all three happened can you picture the potential financial loss? I believe it is good practice to add an SPF record on all registered domains, even if you don’t intend to use the domain for e-mail.

 

Changes to Office 365 now include enhanced anti-spoof capabilities which basically means the debate over requiring an SPF record should end. Over the last six months, Exchange online has been moving client E-mail more frequently into junk folders, analysis of the cause points to third-party domains not having an SPF record.


 

What can I do to fix the issue?

  • Verify that your SPF record includes the host that is sending the E-mail if the host does not then I would suggest modifying your domain so it does.s
  • Make sure your FQDN does not include a .local domain. This needs to be set to include the domain that the E-mail is sent from.
  • Hire CHTSI, by completing the form below we can get your E-mail running properly as soon as possible.e
    l=”Contact For Assistance”]

Full support for Outlook throughout Outlook Experts Service, troubleshooting Outlook? Get in touch.

Need help or want to know more?

If you would like to learn more or would like to discuss working together, complete our online form below.

Alternatively, book an appointment via our scheduler or call 01423 423068.

 

Book an Appointment

 

May 2020
MonTueWedThuFriSatSun
27282930123
45678910
11121314151617
18192021222324
25262728293031

 

 

 


 

Leave a Reply

chtsiserve-com