Note: This page serves as an introduction and quick overview of SPF mechanism syntax. For the complete and definitive picture, please see the specification.
Domains define zero or more mechanisms. Mechanisms can be used to describe the set of hosts which are designated outbound mailers for the domain.
Domains may also define modifiers. Each modifier can appear only once.
redirect | exp
Mechanisms
The SPF record for domain replace the current record. The macro-expanded domain is also substituted for the current-domain in those look-ups. SPF records cannot be over 255 characters in length and cannot include more than ten include statements, also known as “lookups.” Here’s an example of what your record might look like: v=spf1 ip4:1.2.3.4 ip4:2.3.4.5 include:thirdparty.com -all.
Mechanisms can be prefixed with one of four qualifiers:
If a mechanism results in a hit, its qualifier value is used. The default qualifier is '+', i.e. 'Pass'. For example:
The SPF record for domain replace the current record. The macro-expanded domain is also substituted for the current-domain in those look-ups.
'v=spf1 -all'
'v=spf1 a mx -all'
Mechanisms are evaluated in order. If no mechanism or modifier matches, the default result is 'Neutral'.
If a domain has no SPF record at all, the result is 'None'. If a domain has a temporary error during DNS processing, you get the result 'TempError' (called 'error' in earlier drafts). If some kind of syntax or evaluation error occurs (eg. the domain specifies an unrecognized mechanism) the result is 'PermError' (formerly 'unknown').
Evaluation of an SPF record can return any of these results:
Result | Explanation | Intended action |
Pass | The SPF record designates the host to be allowed to send | accept |
Fail | The SPF record has designated the host as NOT being allowed to send | reject |
SoftFail | The SPF record has designated the host as NOT being allowed to send but is in transition | accept but mark |
Neutral | The SPF record specifies explicitly that nothing can be said about validity | accept |
None | The domain does not have an SPF record or the SPF record does not evaluate to a result | accept |
PermError | A permanent error has occured (eg. badly formatted SPF record) | unspecified |
TempError | A transient error has occured | accept or reject |
The 'all
' mechanism (edit)
all
This mechanism always matches. It usually goes at the end of the SPF record.
Examples:
'v=spf1 mx -all'
'v=spf1 -all'
'v=spf1 +all'
The 'ip4
' mechanism (edit)
The argument to the 'ip4:
' mechanism is an IPv4 network range. If no prefix-length is given, /32 is assumed (singling out an individual host address).
Examples:
'v=spf1 ip4:192.168.0.1/16 -all'
The 'ip6
' mechanism (edit)
The argument to the 'ip6:
' mechanism is an IPv6 network range. If no prefix-length is given, /128 is assumed (singling out an individual host address).
Examples:
'v=spf1 ip6:1080::8:800:200C:417A/96 -all'
'v=spf1 ip6:1080::8:800:68.0.3.1/96 -all'
The 'a
' mechanism (edit)
All the A records for domain are tested. If the client IP is found among them, this mechanism matches. If the connection is made over IPv6, then an AAAA lookup is performed instead.
If domain is not specified, the current-domain is used.
The A records have to match the client IP exactly, unless a prefix-length is provided, in which case each IP address returned by the A lookup will be expanded to its corresponding CIDR prefix, and the client IP will be sought within that subnet.
'v=spf1 a -all'
'v=spf1 a:example.com -all'
'v=spf1 a:mailers.example.com -all'
'v=spf1 a/24 a:offsite.example.com/24 -all'
The 'mx
' mechanism (edit)
All the A records for all the MX records for domain are tested in order of MX priority. If the client IP is found among them, this mechanism matches.
If domain is not specified, the current-domain is used.
The A records have to match the client IP exactly, unless a prefix-length is provided, in which case each IP address returned by the A lookup will be expanded to its corresponding CIDR prefix, and the client IP will be sought within that subnet.
Examples:
'v=spf1 mx mx:deferrals.domain.com -all'
'v=spf1 mx/24 mx:offsite.domain.com/24 -all'
The 'ptr
' mechanism (edit)
The hostname or hostnames for the client IP are looked up using PTR queries. The hostnames are then validated: at least one of the A records for a PTR hostname must match the original client IP. Invalid hostnames are discarded. If a valid hostname ends in domain, this mechanism matches.
If domain is not specified, the current-domain is used.
If at all possible, you should avoid using this mechanism in your SPF record, because it will result in a larger number of expensive DNS lookups.
Examples:
'v=spf1 ptr -all'
'v=spf1 ptr:otherdomain.com -all'
The 'exists
' mechanism (edit)
Perform an A query on the provided domain. If a result is found, this constitutes a match. It doesn't matter what the lookup result is – it could be 127.0.0.2.
When you use macros with this mechanism, you can perform RBL-style reversed-IP lookups, or set up per-user exceptions.
Examples:
In the following example, the client IP is 1.2.3.4 and the current-domain is example.com.
'v=spf1 exists:example.com -all'
The 'include
' mechanism (edit)
The specified domain is searched for a match. If the lookup does not return a match or an error, processing proceeds to the next directive. Warning: If the domain does not have a valid SPF record, the result is a permanent error. Some mail receivers will reject based on a PermError.
Examples:
In the following example, the client IP is 1.2.3.4 and the current-domain is example.com.
'v=spf1 include:example.com -all'
-all
', the include as a whole fails to match; the eventual result is still Fail from the outer directive set in this example.Trust relationships — The 'include:
' mechanism is meant to cross administrative boundaries. Great care is needed to ensure that 'include:
' mechanisms do not place domains at risk for giving SPF Pass results to messages that result from cross user forgery. Unless technical mechanisms are in place at the specified otherdomain to prevent cross user forgery, 'include:
' mechanisms should give a Neutral rather than Pass result. This is done by adding '?' in front of 'include:
'. The example above would be:
In hindsight, the name 'include' was poorly chosen. Only the evaluated result of the referenced SPF record is used, rather than acting as if the referenced SPF record was literally included in the first. For example, evaluating a '-all
' directive in the referenced record does not terminate the overall processing and does not necessarily result in an overall Fail. (Better names for this mechanism would have been 'if-pass', 'on-pass', etc.)
Modifiers
Modifiers are optional. A modifier may appear only once per record. Unknown modifiers are ignored.
The 'redirect
' modifier (edit)
The SPF record for domain replace the current record. The macro-expanded domain is also substituted for the current-domain in those look-ups.
Examples:
In the following example, the client IP is 1.2.3.4 and the current-domain is example.com.
'v=spf1 redirect=example.com'
The 'exp
' modifier (edit)
Spf Record Creator Microsoft
If an SMTP receiver rejects a message, it can include an explanation. An SPF publisher can specify the explanation string that senders see. This way, an ISP can direct nonconforming users to a web page that provides further instructions about how to configure SASL.
The domain is expanded; a TXT lookup is performed. The result of the TXT query is then macro-expanded and shown to the sender. Other macros can be used to provide an customized explanation.
Our informative post will help you find out how you can setup Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM) Signatures on your Microsoft 365 email to eliminate spam from your domain and increase security.
Microsoft requires you to configure the following DNS records for your domain: Microsoft 365 SPF and DKIM.
SPF records allow receiving servers to check whether an email with the specified source domain was actually sent from a server authorized by the owner of this domain.
DKIM adds a digital signature to each message. This allows the receiving server to check if the message has been sent from an authorized sender, faked or changed upon delivery.
Setting up an SPF Record
In order to authorize Microsoft 365 to send emails on your domain behalf, you will need to create or update your SPF Record which includes the following mechanism: include:spf.protection.outlook.com
You can achieve this easily with our SPF Record Generator tool; here are the steps:
Setup Spf Record
- Generate a new SPF Record with authorizing Microsoft 365
2. Copy the newly generated SPF Record
3. Update your DNS TXT Record for SPF at your domain provider (We will show examples with GoDaddy and Cloudflare)
E.g GoDaddy
E.g Cloudflare
4. Click Save
Important Note: Make sure you don’t create multiple SPF TXT records on one domain. If you do, SPF will return a PermError.
If you are using multiple IPs, ESPs, Third-Party services for your various email strategies, you should include them in a single SPF Record.
E.g v=spf1 ip4:17.67.137.221 include:spf.protection.outlook.com include:thirdpartyservice.com ~all
Configuring DKIM for Microsoft 365
- Choose Admin from your Office365 portal
2. In the Admin Center, choose ‘Exchange’
3. Go to protection -> DKIM
4. Create CNAME Records
Spf Record Generator Microsoft Office 2010
Host name: selector1._domainkey
Points to address or value: selector1-<domainGUID>._domainkey.<initialDomain>
TTL: 3600
Host name: selector2._domainkey
Points to address or value: selector2-<domainGUID>._domainkey.<initialDomain>
TTL: 3600
Important Notes:
- <domainGUID> is in the MX record for your custom domain that appears before mail.protection.outlook.com. For example, in the following MX record for the domain company.com, the domainGUID is company-com:
company.com. 3600 IN MX 0 company-com.mail.protection.outlook.com
- <initialDomain> is the domain that you used when you signed up for Microsoft 365. Initial domains always end in onmicrosoft.com
For example, if you have an initial domain of company.onmicrosoft.com, and a custom domain “company.com”, you will need to add CNAME Records as:
Host name: selector1._domainkey
Points to address or value: selector1-company-com._domainkey.company.onmicrosoft.com
TTL: 3600
Host name: selector2._domainkey
Points to address or value: selector2-company-com._domainkey.company.onmicrosoft.com
TTL: 3600
5. Add CNAME Records in your DNS Zone
6. Select the domain that you want to authenticate, and click Enable
7. After successful implementation, you should see:
Congrats, you now successfully authenticated your outgoing mail stream from Office365 with SPF and DKIM.