How to fix the 'SPF unauthorized mail is prohibited' error

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.

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.

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.

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.

dig yourdomain.com TXT

nslookup -type=TXT yourdomain.com

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.

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.

v=spf1 include:_spf.google.com include:sendgrid.net -all

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.

What is the full form of SPF in email?

Matthew Whittaker

11 Jul 2025

Curious about what SPF means in the context of email? The full form is Sender Policy Framework, a crucial email authentication standard that helps prevent spoofing and phishing. Learn how this framework allows you to publicly declare which mail servers are authorized to send emails for your domain, protecting your brand reputation and improving your email deliverability.

Why you shouldn't add MailChimp to your SPF record

Michael Ko

11 Jul 2025

Discover why adding MailChimp to your SPF record is not only unnecessary but can actually harm your email deliverability. Learn how MailChimp uses DKIM for authentication and why you should avoid wasting a valuable DNS lookup, bringing you closer to the 10-lookup limit.

Why your emails fail at Microsoft: the hidden SPF DNS timeout

Michael Ko

11 Jul 2025

Discover a little-known Microsoft 365 behavior that could be causing your emails to fail. We dive into the 500ms DNS timeout for SPF lookups, explaining why it happens, how it leads to intermittent delivery errors, and what you can do to create a robust SPF record that works every time.

Solving the SPF alignment puzzle for google workspace alias domains

Matthew Whittaker

11 Jul 2025

Struggling with SPF alignment for your Google Workspace alias domains? This guide explains why it happens, why it's usually okay, and how to ensure DMARC compliance and protect your email deliverability by focusing on DKIM alignment.

Demystifying the SPF TempError in your DMARC reports

Matthew Whittaker

14 Jul 2025

Ever seen an 'SPF TempError' in your DMARC reports and wondered what it means? This article demystifies this common, yet confusing, result. We'll explain what a TempError is, how it differs from a PermError, its impact on DMARC evaluation, and what actions, if any, you should take when you see them.