All offers are aimed at traders, not end consumers and do not include VAT.
© 2024 nicmanager.com. All rights reserved.
© 2024 nicmanager.com. All rights reserved.
SPF entries can be quite simple (v = spf1 a-all), but they can also be quite complex to take into account the multitude of outgoing mail server configurations available on the Internet. It seems that especially SPF newcomers often make similar mistakes when creating their first SPF record. In general, you should pay attention to the following points.
The purpose of SPF is to promote the mail servers of your domain. It often helps to create a list before you start. Consider using one of the following options to send e-mail:
Only the last mail server is relevant. This is because if your company has a more complicated setup and an internal mail server forwards e-mail to the world via an outgoing mail server, SPF will only list the outgoing mail server.
At a given time, AOL captures the outgoing SMTP traffic (port 25) from its users and transparently intercepts the messages and routes them through AOL's outgoing mail servers. Thus, all AOL users would send e-mail through AOL's mail servers whether they wanted to or not. Using an alternative port such as port 587 can help if your hosting company supports it.
You may have more than one domain. But you should also be careful, because domains you do not use can also be abused by spammers! See also the publication of SPF zero records for ...
Eventually, SPF lookups are resolved to an IP address. It is therefore not necessary to list the same server using multiple hostnames (e.g., "example.com" and "www.example.com" both resolve to the same IP). In fact, this is somewhat more difficult on your DNS servers, since a receiving server traversing your record may be forced to perform multiple DNS lookups if a single reference to the server's hostname would have been sufficient.
If the IP address of the server rarely changes, you should use the spelling ip4: x.x.x.x (or ip6) so that the recipients can completely avoid DNS lookups. Since there is a limit of 10 DNS lookups per SPF record, it is preferable to specify an IP address or address range for long lists of outgoing mail servers. However, often an SPF record can be compressed to something like v = spf1 ip4: x.x.x.x -all if there is only one outgoing mail server.
The purpose of SPF is to publish a list of outgoing mail servers. Therefore, all servers that do not send e-mail to the world, such as web servers or pure incoming mail servers, should not be listed.
Sometimes it is easy to add the mx mechanism when using configuration aids. However, since MX records are used to forward of inbound e-mail is used for your organization, the same servers might or might not be used for outbound e-mail. If the IP address of your outgoing server is covered by an a, ip4 or other mechanism, this server does not need to be referenced again with the mx mechanism (see Listing servers only once above). However, if the servers listed in your MX records are only used for incoming e-mail, the MX mechanism does not need to be used.
The specification of mx: mailserver.example.com is generally wrong, unless you really want to use SPF scanning to find all hosts that accept mail for the domain "mailserver.example.com". (Normally there will be no such hosts, since "mailserver.example.com" is a host itself, not a domain). However, this is not shown as a syntax error, simply nothing is found. The correct use for checking against the MX records for "example.com" is mx: example.com, or if you want to specify the host name or IP of a particular mail server, a: mailserver.example.com or ip4: x.x.x.x.
Finally, note that "example.com" is the default domain for the rule if your SPF rule is stored as a DNS record linked to "example.com". Therefore, mx alone (without specifying an explicit domain) is sufficient to compare the sender IP with all MX mail hosts listed for "example.com" in this context. Since 2008, the SenderID wizard makes it easy to get this wrong. For example, if the commands "dig -tmx mailserver.example.com" or "nslookup -q = mx mailserver.example.com" do not yield anything, using "mx: mailserver.example.com" wastes the bandwidth of the recipients who check SPF, as well as the bandwidth of your own name servers, which then answer pointless questions.
If you host e-mail for others, do not create an SPF record for a customer without investigating which e-mail servers that customer uses, because you may have blocked or obstructed your customer's outgoing mail from their internal mail server or from end users who send e-mail through their home ISP's mail server. To be on the safe side, follow the instructions for ISPs.
Suppose you want to include the outgoing mail servers of your web hosting company in your SPF record. Network Solutions also hosts your website and e-mail. You may be tempted to use: networksolutions.com in your SPF record. You may be tempted to use: networksolutions.com in your SPF record. However, this can lead to two problems.
First, if Network Solutions does not currently publish an SPF record for the networksolutions.com. domain and you use include: networksolutions.com, your record will immediately become invalid.
The other problem is more subtle: include: networksolutions.com would also include mail servers that are authorized to send e-mail through the networksolutions.com domain. So this could be the same list of mail servers that networksolutions uses to send e-mail through customer domains. Sometimes an ISP creates a special SPF record that customers can include in their record, for example _spf.example.com.
So if you want to use an ISP's mail servers, you should ask them if they manage an SPF record for their customers. Otherwise, you will need to change your record every time your ISP adds or removes a mail server, or changes its name and/or address.
Checking HELO / EHLO names is recommended by SPF-RFC. The Publishing records for these hostnames is therefore an important Part of the SPF protocol. HELO or also its modern version EHLO will used when an e-mail from ... even if a recipient does not perform a 100% HELO check. Publishing a HELO rule usually creates an SPF record associated with the HELO FQDN used by your mail server (example: "mailserver.example.com").
Normally this should be a completely different SPF rule than the one that checks the sender addresses in your domain that may be linked to "example.com". A simple example of two rules could be: example.com. IN TXT "v=spf1 mx -all" mailserver.example.com. IN TXT "v=spf1 a -all" The first rule would be activated from any address ending with "@ example.com", and would only validate such an e-mail if it came from an IP address associated with an MX record for "example.com".
The second rule would be activated by a HELO identification of "mailserver.example.com" and would only validate the e-mail if it comes from an IP address assigned on this server. Another reason to consider HELO names is to publish zero SPF records for your domains that do not send e-mail. Suppose you follow the instructions in this FAQ, but don't think about HELO names. You could inadvertently deny servers the right to send e-mail.
An example of this would be a cloud of web servers sending e-mail forms, with "webform@example.com" as the sender address. Each of these web servers uses (as it should) its own name as a HELO parameter.
If you have protected your e-mail sending domains with SPF and someone tries to spoof them, the first thing they would try is to spoof your non-e-mail sending domains. Publishing "v = spf1 -all" means that a domain is not sending mail. As an example, you could publish:
Use a test tool to test a new SPF dataset
SPF is based on DNS lookups. So for the world to find your SPF record, you must also create it on the correct DNS server. If you are not sure which (main) DNS server(s) are "authoritative" for your domain, simply check your domain with "whois" or ask your web hosting company.
Remember that if you use a test utility to look up your SPF record in DNS, you must wait for its TTL (Time to Live) to expire and for the change to propagate to the world before the utility detects the changes. However, it is often easier to insert your SPF record into the utility to make your changes immediately visible.
Don't forget to give instructions to the people who need to send e-mail with the domain you just protected. They may need to configure SMTP AUTH in their e-mail client and they may need a login and password. If sending from hotel PCs (or whatever) is now prohibited, they need to know about it.