How to fix the 'SPF unauthorized mail is prohibited' error
Michael Ko
Co-founder & CEO, Suped
Published 13 Jul 2025
Updated 13 Jul 2025
6 min read
It's one of the most common and frustrating email errors you can encounter. You send an important message, only to receive a bounce-back notification stating: "550 SPF unauthorized mail is prohibited." This cryptic message can stop your communication in its tracks, leaving you wondering what went wrong and how to fix it. This error is a clear signal that your email failed a critical security check.
In simple terms, the recipient's mail server looked at your domain's Sender Policy Framework (SPF) record and determined that the server you used to send the email wasn't on the approved list. This is a protective measure designed to prevent spammers and phishers from spoofing your domain and tricking your recipients. While it's a valuable security feature, a misconfiguration can block your legitimate emails, causing significant disruption. The good news is that fixing it is entirely within your control.
What is an SPF record and why does it matter?
Sender Policy Framework, or SPF, is an email authentication standard that helps protect against email spoofing. It functions as a public list of all the servers and services authorized to send email on behalf of your domain. This list is published as a TXT record in your domain's DNS (Domain Name System). When an email server receives a message, it can perform an SPF check to verify the sender's authenticity.
The process is straightforward. The receiving server inspects the email's headers to find the sending domain. It then performs a DNS lookup to find that domain's SPF record. Finally, it checks if the IP address of the server that sent the email is included in the approved list within the SPF record. If the IP address is found, the check passes. If it's not on the list, the check fails, often resulting in the SPF fail - not authorized error.
This error typically arises from a few common scenarios. You might have recently started using a new third-party service, like a marketing automation platform, a CRM, or a customer support tool, to send emails from your domain. If you didn't add that service's sending servers to your SPF record, their emails will be seen as unauthorized. Other causes include a change in your server's IP address or a simple syntax error in the SPF record itself.
SPF works best alongside two other authentication protocols: DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting, and Conformance). DKIM adds a digital signature to your emails, while DMARC provides instructions on how to handle emails that fail SPF or DKIM checks. Together, they form a powerful triad that significantly boosts your email security and deliverability.
How to find the cause of the SPF error
Before you can fix the problem, you need to identify exactly what's causing it. The first step is to create a complete inventory of every service and server that sends email using your domain name. This isn't just about your primary mailbox provider like Google Workspace or Microsoft 365. You need to account for all third-party applications.
Don't forget third-party senders
Common sending sources to check:
Email marketing platforms: Services like Mailchimp, SendGrid, or Constant Contact.
Transactional email services: Platforms used for sending receipts, password resets, and notifications.
Customer Relationship Management (CRM) software: Systems like Salesforce or HubSpot that send email on your behalf.
Helpdesk and support systems: Tools like Zendesk or Freshdesk.
Website and e-commerce platforms: Systems like Shopify or your own web server sending contact form submissions.
Once you have your list, the next step is to examine your current SPF record. You can do this with a simple command-line tool. On macOS or Linux, you can use dig. On Windows, you can use nslookup. Check your domain's TXT records and look for the one that starts with v=spf1. If you don't find one, or if it's incomplete, you've likely found your problem.
macOS / Linuxbash
dig yourdomain.com TXT
Windowsbash
nslookup -type=TXT yourdomain.com
A step-by-step guide to fixing your SPF record
With your list of authorized senders in hand, you can now construct a correct SPF record. An SPF record is a single line of text with specific components. It always starts with v=spf1 to indicate the version. This is followed by one or more mechanisms that define the authorized senders, such as ip4: for specific IPv4 addresses or include: to incorporate the SPF record of a third-party service. The record ends with a qualifier, typically -all or ~all, which tells receiving servers how to treat emails from sources not on the list.
-all (Hard fail)
The -all mechanism is known as a "Hard Fail". It's a strict instruction to receiving mail servers to reject any email that doesn't originate from one of the authorized sources listed in the SPF record. This is the most secure option and is generally recommended for preventing spoofing.
Provides the strongest protection against spoofing.
Clearly tells servers to drop unauthorized messages.
~all (Soft fail)
The ~all mechanism is a "Soft Fail". It suggests to the receiving server that the email is suspicious and should likely be marked as spam or inspected more closely, but it does not demand outright rejection. This is often used as a transitional policy or when you are not completely certain about all your sending sources.
Allows for a more lenient policy during migration.
Reduces the risk of blocking legitimate mail due to misconfiguration.
For example, if your company uses Google Workspace for primary email and SendGrid for marketing newsletters, your SPF record would need to include both. You would combine their respective include mechanisms into a single record. Once created, you will add this as a TXT record in your domain's DNS settings, replacing any existing SPF record.
This record authorizes both Google and SendGrid and instructs servers to reject all other sources.
Warning: The 10 DNS lookup limit
The SPF specification states that a single SPF check cannot result in more than 10 DNS lookups. Mechanisms like include, a, mx, and redirect count towards this limit. Exceeding it will cause an SPF Permerror, making your entire record invalid. If you use many services, you may need to 'flatten' your record or use subdomains for different sending purposes.
After you've updated your DNS with the correct SPF record, you've done your part. However, DNS changes are not instantaneous. They need to propagate across the internet, a process that can take anywhere from a few minutes to 48 hours, depending on the TTL (Time To Live) value set for your DNS records. Be patient and monitor your email bounce notifications to confirm the issue is resolved.
Remember that managing your SPF record is an ongoing task, not a one-time fix. Every time your organization adopts a new tool or service that sends email on your behalf, you must remember to update your SPF record accordingly. Failing to do so will just lead you back to the same "unauthorized mail is prohibited" error. Keeping a current inventory of your sending services is a key part of maintaining good email deliverability and protecting your brand's reputation.
While it can seem technical, fixing this SPF error is a manageable process of identifying your senders, building the correct record, and publishing it. By taking these steps, you not only solve the immediate problem but also strengthen your domain against phishing and spoofing attacks, ensuring your legitimate emails reach their destination without issue.
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Google Workspace or 
Microsoft 365. You need to account for all third-party applications.
