Как составить spf запись

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.

all | ip4 | ip6 | a | mx | ptr | exists | include

Domains may also define modifiers. Each modifier can appear only once.

redirect | exp

Mechanisms

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:

"v=spf1 -all"

"v=spf1 a -all"

"v=spf1 a mx -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:

The “all” mechanism (edit)

all

This mechanism always matches. It usually goes at the end of the SPF record.

Examples:

The “ip4” mechanism (edit)

ip4:<ip4-address>
ip4:<ip4-network>/<prefix-length>

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:

The “ip6” mechanism (edit)

ip6:<ip6-address>
ip6:<ip6-network>/<prefix-length>

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:

The “a” mechanism (edit)

a
a/<prefix-length>
a:<domain>
a:<domain>/<prefix-length>

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.

The “mx” mechanism (edit)

mx
mx/<prefix-length>
mx:<domain>
mx:<domain>/<prefix-length>

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:

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:

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:

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:

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:

"v=spf1 ?include:example.com -all"

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:

The “exp” modifier (edit)

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.

SPF — это не только уровень защиты от солнечных лучей. Это еще и мощная технология, которая ограждает домен отправителя от действий мошенников. О том, как она работает и почему без настроенной SPF все меры по защите почтовой репутации летят коту под хвост – рассказываем.

P.S. будет много технических терминов, но мы их просто объясним.:)

SPF: что? зачем? и как?

SPF (Sender Policy Framework/структура политики отправителя) — это метод борьбы со спамом, который работает по принципу паспорта. Как главный документ удостоверяет нашу личность, так SPF подтверждает, что емейл пришел с проверенного надежного адреса. Но в отличие от объемной книжечки, Sender Policy Framework представляет собой одну строку в TXT-записи домена. Например, такую:

где v=spf1 – это используемая версия SPF, а +a +mx -all – механизм и условия защиты домена от мошенников.

Это самый простой пример записи, который говорит о том, что отправлять письма от имени домена example.org могут все все сервера, указанные в записях a и mx. Другие же адреса должны быть удалены: -all.

Более сложный уровень SPF-защиты для того же домена может выглядеть так:

и означает, что отправлять сообщения от имени домена example.org. могут все сервера, указанные в mx-записях, а также отправленные с IP 195.3.159.250. Кроме того, можно принимать письма с серверов, указанных в SPF-записи домена gmail.com. Письма со всех остальных серверов нужно отправить в спам без проверки: ~all“.

И это далеко не самая сложная SPF-запись. При необходимости, она может вмещать до 10 параметров. Для удобства, мы собрали их все в одном месте:

+ принимать сообщение. Например: +all – принимать все письма;

– отклонить сообщение. Например: -all – отклонять все письма;

~ принять емейл, но пометить как СПАМ. ~all – отправлять все письма в СПАМ;

? нейтральное отношение;

mx все адреса, указанные в MX-записях домена;

ip4 указывает конкретный IP-адрес. Например: ip4:195.3.156.134 – принимать письма с IP 195.3.156.134;

a указывает действие, которое нужно сделать при получении письма от конкретного домена. Например: +a – принять все письма, которые присланы с IP, который совпадает с IP-адресом в записи отправляющего домена;

include разрешает принимать письма с серверов, разрешенных SPF-записями домена. Например: include:gmail.com – принимать письма с айпишников, которые указаны в SPF домена gmail.com;

all все остальные IP, которые не указаны в SPF-записи;

exists проверяет работоспособность доменного имени;

redirect указывает, что нужно проверять SPF указанного домена, вместо текущего; задает сообщение об ошибке, которое передается отправителю. Например:
exp example.org. IN TXT “v=spf1 +a +mx -all exp=spf.example.org”

spf.example.org. IN TXT “You host not allowed e-mail to me from this domain!”

Главная функция SPF — предотвратить попытки спуфинга и других атак на репутацию отправителя. Ее длина и сложность зависит от нужного уровня защиты и навыков специалиста. Зачастую ее можно прописать самостоятельно, и мы расскажем как – чуть дальше:)

Как SPF защищает домен от спуфинга?

Как известно, основной метод спуфинга — это подмена адреса в поле “FROM”. SPF-запись, как противоядие, направлено именно на это поле, поскольку оно содержит главный критерий для проверки: домен отправителя и его IP адрес. Сопоставляя его с теми айпишниками, которые прописаны в SPF-записи как разрешенные, сервер-получатель принимает решение о безопасности сообщения.

Коротко, алгоритм работы SPF проходит четыре этапа. Для примера, возьмем отправку сообщения с адреса [email protected] на адрес [email protected] через почтовый сервис Estismail:

И такие этапы проходит каждое письмо. Графически, преодоление SPF-фильтра выглядит следующим образом:

Базовую роль в проверке домена играет список IP адресов, указанных в SPF-записи. Именно он подтверждает честные намерения отправителя. Поэтому постарайтесь вписать в этот список все возможные IP, которым вы разрешаете отправку: все корпоративные адреса, а также не забудьте о сервисах почтовых рассылок.

Как настроить и проверить SPF-запись для своего домена самостоятельно?

Создание SPF — простая операция. В большинстве случаев для установки базовой защиты достаточно прописать одну строку в TXT-записи домена. Но и здесь есть много подводных камней:

Процесс настройки SPF-записи проходит на сайте провайдера и состоит из 5 этапов. Последний из них — проверка работоспособности и правильности SPF. Ее можно провести на одном из специальных сервисах:

или в личном аккаунте почтового сервиса Estismail. Зеленая галочка в разделе “Статус” означает, что SPF прописана и внедрена в TXT – запись домена верно:

Поздравляем, теперь Вы можете самостоятельно за несколько минут настроить SPF-запись для своего домена и обеспечить мощную защиту репутации отправителя. Тем не менее, одному лишь SPF не под силу полностью оградить домен от фишинга и спуфинга. Для полной защиты нужно действие трех магов: SPF, DMARC и DKIM. Если хотя бы один из них будет не настроен, то в защите отправляющего домена образуется брешь, через которую спуферы смогут подменить информацию об отправителе. В результате – ваши клиенты от вашего же имени получают спам или вирус, а вы – ни сном ни духом. Чтобы избежать такой ситуации – проверьте все записи или обратитесь в нашу службу поддержки. Мы всегда поможем.

The Sender Policy Framework (SPF) is a technique that prevents email spoofing. In this article, you will learn the importance of the SPF record and how to correctly configure it in your domain’s DNS so that emails sent from your domain are not marked as spam by the recipient.

If your email messages are landing your recipients’ spam folders, the likeliest cause is a missing or misconfigured SPF record in the sending domain.

Modern email providers might even completely reject your message with an error, as shown in the following screenshot:

This problem is most common in email messages generated by websites or CMS software. If you are facing such a problem, this guide can help you.

Sender Policy Framework (SPF)

The Sender Policy Framework (SPF) is a standard that is used as a policy by publishing a TXT record in the DNS of a domain. The SPF record contains the list of IP addresses, domain names, and third-party services that are authorized to send email messages on behalf of your domain.

To prevent recipient email servers from rejecting or treating the email messages sent from your domain as spam, it is highly recommended to publish an SPF record in your domain’s DNS. The recipient email servers could then query this record to verify whether the email message was actually sent by a legitimate (authorized) source IP address or domain.

SPF record syntax and examples

The syntax of an SPF record is fairly simple, as shown below:

v=spf1 <authorized_IP_addresses_or_domains> <enforcement_rule>

The following screenshot shows an example of an SPF record:

1. The value of every SPF record starts with v=spf1, which indicates that it is an SPF (version 1) record.
2. The next section defines the authorized IP addresses (or IP address block) and domain names. The multiple values are separated by a single white space. For example, if you’re using Microsoft 365 for business emails and MailChimp for sending transactional emails from a website, you could use multiple include mechanisms. Your SPF record will look like this:

   v=spf1 include:spf.protection.outlook.com include:spf.mandrillapp.com -all
   

The last part of the SPF record is the enforcement policy, which could have either of the following values:

• ?all—Use this at the end to set the SPF policy to neutral, which means the SPF record doesn’t explicitly state that the IP address is authorized or not. This setting is rarely used.
• ~all—Use this at the end to indicate that all other servers, except those specified, are not authorized. The email messages are marked with soft-fail in the envelope but are likely to be accepted by the recipient server. This is a temporary setting that is recommended during a transitioning period, such as during an email migration process.
• -all—Use this at the end to indicate that all other servers are not authorized. The email messages are marked with hard-fail in the envelope and are likely to be rejected by the recipient server (depending on the policy). This is a recommended setting for production domains.
• +all—Use this at the end to indicate that all other servers are also authorized to send emails on the domain’s behalf. This setting makes the SPF record useless and should never be used.

The following table shows the SPF records of some popular email service providers:

Before copying and pasting these SPF values, check the official documentation of the respective email service provider to make sure it is up to date.

How SPF works

Now that you understand all the parts of the SPF record, let’s understand how it works in the real world with an example:

v=spf1 ip4:192.167.0.0/30 include:_spf.google.com include:spf.mandrillapp.com -all

This SPF record authorizes all the servers having IP addresses 192.167.0.1—192.167.0.2, Google servers, and Mailchimp servers to send emails on your domain’s behalf. All other servers except these are explicitly stated as unauthorized (due to -all).

Let’s say the Gmail server receives a forged email message that claims to be sent from your domain. The Gmail server will query the DNS for the SPF record and check whether the server (from where the email message was sent) is actually listed there. Since it was a forged message, the IP address will not be listed in the SPF value, and the SPF check will fail. Ultimately, the Gmail server will mark that message as spam or permanently reject it. Of course, there is much more going on under the hood, but this is how it works in a nutshell.

Important points about SPF records

• All the IP addresses, domain names, and third-party services that you use to send emails should be listed in the SPF record.
• There should be only one SPF record in a domain. Having multiple SPF records causes problems.
• The maximum DNS lookups are limited to 10 by the SPF specification. If lookups exceed this limit, the SPF check will fail. See the troubleshooting section for additional details.
• Keep your SPF record updated by removing outdated vendor names that are no longer in use, and keep only active sending domains and services.

Set up and validate the SPF record

The easiest way to generate an SPF record is to use the SPF record generator by MXToolBox. It offers an easy-to-use wizard. If you don’t want to use any third-party service, make sure you understand the syntax of SPF as discussed above, and then create your SPF record accordingly.

To publish the SPF record in your domain, log on to the DNS management page and add a new TXT record, as shown in the screenshot below:

You might see slightly different options depending upon your DNS registrar, but the idea of adding the SPF record is the same everywhere. You must choose TXT under the record type when you create the SPF record.

Once you publish the TXT record in DNS, give it some time to propagate through the DNS servers, and then use the SPF record checker to validate your SPF record. This tool validates the record and reports whether there are any problems with the record. Moreover, it also shows the number of DNS lookups, as shown in the following screenshot. This is helpful in verifying that lookups do not exceed 10.

By the way, if you don’t want to use any online tool, you could use the nslookup command, as shown below:

nslookup -q=txt yourdomain.com 8.8.8.8
This command uses Google DNS (8.8.8.8, which is optional) to query TXT records in yourdomain.com. 

Troubleshoot SPF problems

When you publish your SPF record in DNS, remember that DNS propagation can take a while. So don’t worry if your newly added SPF record couldn’t be validated. Give it some time, and then try to validate again. If it still doesn’t work, see the following points to troubleshoot:

1. Syntax Errors—Make sure there is no syntax error, such as an extra space, typo, comma, etc., in your SPF record.
2. Multiple SPF records—When you change your email service provider or hosting provider, they suggest adding their own SPF record. As a result, you might end up having multiple SPF records in your domain. Make sure there is only one SPF record and that it includes all the email sending servers and services.
3. The DNS record type 99 (SPF) has been deprecated—When the SPF was in development, its requirements were stricter, and a dedicated DNS record of type 99 (SPF) was needed. However, support for the SPF record type ended in 2014. Now, you need to publish the SPF record as a type 16 (TXT) record. The above error indicates that you have selected the SPF record type while publishing it. To resolve this error, delete the old record and create a new record, choosing TXT as the record type.
4. DNS lookup limit exceeded—The maximum DNS lookups are limited to 10 by the SPF specification. Mechanisms such as include, redirect, a, and mx trigger a DNS lookup in your SPF record. When you use such mechanisms multiple times, the lookup limit is exceeded, and the SPF check will probably fail. To get around this problem, avoid using multiple mechanisms that trigger a DNS lookup, and consider using ip4 or ip6 whenever possible.
5. Missing qualifier at the end—Never forget to add the qualifier (- or ~) with the all mechanism at the end. For example, if your SPF record looks like this: v=spf1 a ip4:1.2.3.4 all, you’re essentially authorizing everyone (*) to send emails on your domain’s behalf, which makes your SPF record pretty much useless.

Conclusion

You see that SPF is important to prevent your email messages from landing in your recipients’ spam folders. Unfortunately, SPF alone is not enough for guaranteed email delivery. The use of SPF together with DKIM and DMARC is highly recommended to set up proper email authentication and signing.

Subscribe to 4sysops newsletter!

In my next post I will describe how to configure DKIM and I will cover DKIM and DMARC in one of my next articles.