In order to implement SPF a valid SPF record must be published. Use the SPF checker to validate the published SPF Record for a given domain.
We strongly recommend to carefully test any updates the SPF records before applying them. We can also test a future change to the SPF Record in advance to ensure there are no complications during implementation.
Validate the SPF Record
Need help on creating a SPF record?
Go to the: SPF Generator
How to: create a SPF record
About: SPF records
DMARC Analyzer is a pure play DMARC specialist with over 15 years of email deliverability experience. We provide user friendly DMARC Analyzer software and Mimecast DMARC Analyzer acts as a comprehensive guide to move towards a reject policy as fast as possible. Sign up for a free trial.
Logically we require a SPF record in the DNS so we can validate it.
It is not allowed to publish multiple SPF records. If multiple SPF records are published (v=spf1), this will invalidate the record. Therefore, always update the existing SPF record and do not place a new record next to the existing record.
When using SPF, it’s only possible to perform 10 (nested) DNS lookups. Please check our knowledgebase article for more information on subject.
We recommend not to use PTR as this is a deprecated mechanism and several senders may (completely) ignore the SPF record when this method is used.
We have detected content which is not in the SPF specification.
If the mechanism “all” is used with a “+” qualifier it means that basically anyone can send email on your behalf. The record will first try to match the sending source with another mechanism. If this fails, the default behavior is to allow this source anyway. Therefore, this setup is discouraged.
Our SPF record checker will try to validate SPF macro’s that are in use. Using some example data we will give examples of the lookups receivers may do based on the macro setup.
An SPF record should always have a ‘default’ fallback mechanism. This can either be an ‘all’ mechanism or a ‘redirect’ modifier.
A SPF record should have 1 fallback scenario. The record contains multiple fallbacks.
The domain has published the SPF record in a DNS type SPF. This DNS type ‘SPF’ (/99) was introduced in RFC 4408 in 2006. However, this type became obsolete by RFC 7208 which states: SPF records MUST be published as a DNS TXT (type 16) Resource Record (RR).
The SPF Record contains uppercase characters. Although it is not a requirement, it is a best practice to publish the SPF records in lowercase.
After running the SPF record through all these checks it’s save to update the SPF record in the DNS.
SPF determines which email servers are allowed to send email on your behalf. In doing so, SPF prevents spoofing and phishing attacks against the email domain. SPF is added as a TXT record used by DNS to determine which email servers can send email on behalf of the custom domain. Recipient email systems consult the SPF TXT record to determine if a message from the custom domain originated from an authorized message server.
The SPF checker searches for an SPF record, displays the SPF record present, and validates the record, highlighting any errors found within it.
The SPF TXT record is a DNS record that helps prevent spoofing and phishing by verifying the domain name from which email messages are sent. SPF validates the origin of email messages by verifying the sender’s IP address against the so-called owner of the sending domain. Domain managers publish SPF information in TXT records in the DNS. The SPF information identifies authorized outgoing email servers. Target email systems verify that messages originate from authorized outbound email servers.
|all information about the Sender Policy Framework (SPF)|
|learn how to create an SPF record|
|learn how to validate a SPF record|
|everything you need to know about SPF records|