SPF Record Checker and Lookup Tool

Verify SPF records, ensure email protection and pinpoint setup accuracy for optimal delivery.

Start Free Trial Start Free Trial
Queried Domain Name
Detected SPF record:
SPF analysis result for
SPF version

SPF record detected.

A Records

List of A records within the SPF record

IP4 Records

List of ip4 records pointed from within the SPF record

Include Records

List of domain records included in the SPF record

MX Records

List of mx records pointed from within the SPF record

IP6 Records

List of ip6 records pointed from within the SPF record

Redirect Records

List of domain records pointed to from within the SPF record

Why Do You Need SPF Record

SPF, or Sender Policy Framework, is a critical tool in combating email address falsification. Its primary objective is to thwart unauthorized manipulation of sender addresses in emails.

Specifically, SPF operates by defining records that prevent the transmission of emails via unauthorized servers. These records are designed to prevent the transmission of emails via unauthorized servers. For this purpose, organizations create an SPF record within the Domain Name System (DNS). This record is usually in the form of a TXT entry within the additional information section.

The SPF record explicitly details authorized mail servers. It is encoded as a TXT entry. When a recipient mail server receives an email, it consults the domain's SPF record. The purpose is to determine its origin. If the email comes from an authorized mail server, the server will accept it. However, the server promptly rejects it if it comes from an unauthorized source.

SPF Checker

Expert Tips to Implement and Manage an SPF Record

#1

To maximize your SPF record, start by publishing a DMARC record. It allows you to dictate how servers handle your emails failing SPF and DKIM checks.

#2

Leverage reports to collect and assess data on your sending sources for improved email authentication. MX Layer offers tools for analyzing email traffic and identifying legitimate sending sources.

#3

Craft a comprehensive SPF TXT record listing all your sending sources, specifying authorized IP addresses and domains for sending emails on behalf of your domain.

#4

Consistently review reports to verify SPF record compliance. Utilize MX Layer for monitoring and maintaining your SPF record, ensuring secure email delivery.

Refer to this glossary for MX Layer SPF Record Check results

SPF Record Existence
To enhance email security, we rely on the presence of an SPF record in your DNS for validation.

Multiple SPF Records in the DNS
It's crucial to remember that each SPF version permits only one SPF record. Having multiple SPF records (identified by 'v=spf1') is a surefire way to nullify your SPF configuration. Therefore, the best practice is to consistently update your existing SPF record rather than adding a new one alongside it.

Maximum Lookups
With SPF, you can conduct up to 10 nested DNS lookups.

PTR Mechanism Used

It's advisable to steer clear of using PTR due to its deprecated status; relying on it might lead to several senders overlooking your SPF record altogether. The PTR record functions inversely to an A record. While an A record resolves a domain name to an IP address, a PTR record resolves an IP address to a domain name. This mechanism validates whether the DNS reverse-mapping for a given <ip> exists and if it properly points to a domain name within a specific domain. However, the PTR mechanism tends to be sluggish and less dependable in comparison to other mechanisms, especially when encountering DNS errors. Hence, we strongly advise against utilizing the PTR mechanism.

Unknown Parts Found
We've identified content that doesn't comply with the SPF specification.

+All Mechanism Used
When employing the "all" mechanism alongside a "+" qualifier, you effectively grant authorization for anyone to send emails on your behalf. Initially, the system attempts to correlate the sending source with another mechanism. In case of failure, the default action permits the source anyway. Consequently, this configuration is not recommended.

Invalid Macro
MX Layer SPF record checker endeavors to validate the SPF macros you employ. Through the utilization of sample data, we will illustrate the lookups that recipients might execute according to your macro configuration.

Record Termination Missing
Ensure that every SPF record includes a fail-safe mechanism by default. This mechanism can take the form of either an "all" directive or a "redirect" modifier. Verify that your SPF record concludes with one of these options.

Multiple Fallback Scenarios
Your SPF record needs to incorporate just one fallback scenario. Currently, you've specified multiple fallbacks, which isn't ideal.

DNS Type “SPF” Used
You've put out your SPF record using the DNS SPF type. This SPF type, introduced back in 2006 through RFC 4408, has since fallen out of use. According to the newer RFC 7208, SPF records now must be published as DNS TXT (type 16) Resource Records.

Uppercase SPF
It appears that you've employed uppercase characters in your SPF record. While it's not obligatory, it's considered a best practice to present SPF records in lowercase format. Once you've subjected your SPF record to all necessary checks, feel free to proceed with updating it in your DNS settings!

Connect to our experts

  1. Block all email-based threats
  2. Get real-time intelligence on attacks
  3. Zero Investment to Start
For more information, please see our Privacy Policy.

Frequently Asked Questions

The Sender Policy Framework (SPF) is a method used to verify the authenticity of emails. It empowers domain owners to designate which mail servers or IP addresses are authorized to send emails on behalf of their domain. When an email is received, the receiving mail servers employ SPF to ascertain its legitimacy. Receiving mail servers do this by cross-referencing the "envelope from" address in the email header with the list of IP addresses authorized by the domain.

An SPF record serves as an authorized list of mail servers, stored in the Domain Name Service (DNS). When a mail server receives an email, it checks the IP addresses in the SPF record. If the email header's IP address isn't listed in the SPF record, the mail server may consider the email illegitimate and reject it.

The SPF TXT record in DNS helps prevent spoofing and phishing by confirming the sender's domain name for email messages. SPF verifies the sender's IP against the domain owner. Domain managers publish SPF info in TXT records. These records list authorized outgoing email servers. Target email systems use this info to verify legitimate messages.

SPF Lookup actively verifies the sender's identity when sending out an email. It entails performing a DNS lookup of the claimed sender's domain and checking that the sender's IP address matches the one listed in the SPF record for that domain. If there's no match, it flags the email as potentially coming from a fraudulent sender.

MX Layer’s SPF Record Checker serves the vital function of verifying several key aspects:
  1. Confirming the existence of the SPF record.
  2. Validating the accuracy of the IP addresses from which the emails originate.
  3. Identifying and rectifying any syntax errors that may be present.
  4. Ensuring the absence of the "10 DNS lookup" error within the record.

Checking SPF records is a breeze with MX Layer’'s complimentary SPF Record Checker tool. Just input the domain name into the designated field and hit 'Check SPF.' In no time, you'll have all the lookup and verification results for that domain at your fingertips. If you prefer a manual approach, you can always verify SPF records by executing the command 'nslookup -type=txt' followed by the domain name in your command prompt.

The Sender Policy Framework (SPF) is a crucial email security tool. It helps prevent email spoofing, where fake addresses are used to impersonate others. SPF lets domain owners list authorized IP addresses for sending emails. When an email arrives at a server, it checks the sender's SPF record. If the IP address isn't authorized, the server can reject the email or mark it as spam. However, SPF has limitations. It only checks the "envelope" sender address, not the visible "From" address. So, it can't stop all spoofing, like when attackers use compromised accounts. SPF is just one of many email security methods. Others include DKIM and DMARC. Most servers use multiple methods, not just SPF. But some still follow the original SPF rules, rejecting emails that fail SPF checks.

  1. Make sure only one server sends emails:
    v=spf1 ip4:198.51.100.1 -all
    This SPF record lets only the mail server with IP address 198.51.100.1 send emails. Other servers can't.
  2. Let a range of IP addresses send emails:
    v=spf1 ip4:192.0.2.0/24 -all
    This SPF record allows any server within 192.0.2.0/24 to send emails. Other servers can't.
  3. Include a third-party email service in the SPF record:
    v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all
    This SPF record lets servers in Google's SPF record (_spf.google.com) and Microsoft's SPF record (spf.protection.outlook.com) send emails to the domain. Other servers can't.
  4. Combine IPv4, IPv6, and third-party services:
    v=spf1 ip4:192.0.2.0/24 ip6:2001:0db8:85a3::/64 include:_spf.google.com include:spf.protection.outlook.com -all
    This SPF record allows servers with IPv4 addresses in 192.0.2.0/24, servers with IPv6 addresses in 2001:0db8:85a3::/64, and servers in Google's SPF record (_spf.google.com) and Microsoft's SPF record (spf.protection.outlook.com) to send emails for the domain. Other servers can't.

Make sure only one server can send emails. The Sender Policy Framework (SPF) helps with this. SPF is an important email authentication protocol. It allows specific IP addresses to send emails for a domain. This makes sure incoming emails are real. When an email has a valid SPF record, mail servers trust it more. SPF also helps with DMARC compliance. DMARC is important for a good email reputation. It makes sure email authentication rules are followed. When SPF is used with DKIM, it makes sure emails are real and protected from attacks. This makes emails more likely to get delivered and improves overall email performance.

We highly recommend automation, especially if you manage multiple domains in large organizations. You can manually manage your SPF record, but using SPF record management services like Managed SPF by MX Layer is faster and more efficient. With a managed solution, you can avoid making syntax errors during SPF configuration and management. This keeps your record useful. Another benefit is that a managed solution helps keep your record up-to-date. We suggest assessing your organization’s needs and circumstances to make the right choice.

Enhancing email deliverability happens when you use email authentication protocols like SPF, DKIM, and DMARC. DMARC relies on SPF and DKIM working properly. If SPF or DKIM fails, DMARC has less chance of succeeding. When SPF gets a permerror, it fails, putting DMARC compliance and email deliverability in danger.

You can define your SPF record by selecting the TXT record type in your DNS service.

The primary purpose of this record is to verify that emails are coming from the correct source and to prevent fake (spoofed) emails, thus thwarting phishing scams.

By defining an SPF record for your domain where you use email services, you significantly reduce the likelihood of your emails ending up in the spam folder.

Each SPF record begins with a version number, "v=spf1," indicating the current SPF version. Following that, you evaluate an unlimited number of records sequentially. Most records consist of a qualifier that defines the sender's authorization and a mechanism, which is an optional qualifier, and a specific condition (IP address) that either results in a match or does not result in a match, forming what are known as directives. The first mechanism that results in a match determines the outcome of the entire evaluation of the SPF record. The rules below determine the outcome of the entire evaluation of the SPF record.

Mechanism Description
All The queried (or explicitly stated) domain has an MX record or MX IP address.
A The queried (or explicitly stated) domain has an MX record or MX IP address.
mx The queried (or explicitly stated) domain has an MX record or MX IP address.
ip4 The specified IPv4 address is the sender's IP address, or the specified IPv4 subnet includes it.
ip6 The specified IPv6 address is the sender's IP address, or the specified IPv6 subnet includes it.
redirect Another domain's SPF record legitimizes the sender's IP address.
include An additional SPF request for the domain specified in the "include" statement includes the sender's IP address.
exists The sender's IP address is authorized based on the client's connection or other criteria as per RFC7208.

  1. Once you've logged into cPanel, navigate to the Advanced Zone Editor by clicking on the corresponding link.
  2. Once the page loads, you'll notice an automatically generated SPF record that's typically added when setting up a hosting account. You'll want to delete this record.
  3. After removing the existing SPF record, proceed to add a new one using the form located at the top of the page. Make sure to fill in all the required fields accurately.
  4. Once you've entered the necessary information, click on the 'Add Record' button to finalize the process.

  1. Sign in to your PLESK Panel.
  2. Navigate to DNS Settings and click on Add Record.
  3. Choose TXT as the Record Type.
  4. Leave the Domain Name field empty.
  5. In the Record String field, enter the appropriate information. Typically, this involves selecting either TXT or SPF, depending on the instructions provided by your email service provider.
  6. Follow any additional instructions provided by the company managing your email service to complete the setup.