What is SPF?
SPF (Sender Policy Framework) is a security feature that is used to authenticate the sender of an email message. SPF declares which mail servers have permission to execute messages from your domain - this way the recipient's mail server 'knows' that the message was sent from an authorized server.
In short, it is a technology to prevent spam and the possibility of impersonation.
Each email message contains two sending addresses indicated in the 'from' field and the 'return_path'. The return_path is the address to which messages are to be sent back or bounced if they cannot be delivered. It is included in the hidden header of the email. It is not the same address as "reply to" (the address to which you can write back to a received message). SPF is set for the domain contained in the "return_path" address.
You can find more information here:
Why set up SPF, why is it so important?
If you care about deliverability in general and the authenticity, credibility of your domain/brand, as well as your security and that of your audience, then setting up an SPF entry is a must.
By setting up SPF you will ensure:
fraud protection - SPF determines which servers can send messages under a given domain, and this makes it more difficult for people to impersonate your domain and send emails on your behalf.
reducing spam - if an email does not meet the SPF record criteria, the recipient's mail server can block delivery.
improved deliverability - mail servers are more likely to deliver emails from senders who have the correct SPF record, as this is a sign that the sender is genuine.
support for other anti-spam technologies - SPF can be used in conjunction with other anti-spam technologies such as DKIM and DMARC to increase the security of emails.
protection of a domain's reputation- domains that do not protect their emails with SPF can become an attractive target for fraudsters and spammers, which can negatively affect their reputation.
How does SPF verification work?
When sending, the recipient's mail server "checks" the address contained in the "return_path". Then validates the SPF record, i.e. verifies that the message was sent from a server that is included in the SPF record of the domain (the domain of the address from the 'return_path').
If the domain is validated - the sending server is included in the SPF record of the domain - then the message is delivered.
If not - the sending server is not included in the SPF record - then, depending on the SPF record suffix (-all, ~all, etc.), the message may be rejected (not delivered), or delivered but flagged as suspicious, or end up in SPAM.
How to set up an SPF record for messages from edrone?
SPF is a DNS record that you configure in the sender's domain hosting (there should be a place to configure DNS records in the hosting). The SPF is in TXT format/type, or in some hosts simply SPF.
There can only be one SPF record for a given domain, so if you need to edit it, do not create another SPF record, but configure the existing one.
Example SPF record:
v=spf1 a mx include:spf.protection.outlook.com include:_spf.google.com ~all
What does the '~all' at the end of the record mean?
There are several ways to end an SPF record, and each determines how to deal with messages that have been sent under a particular domain, but their servers are not included in the SPF. The differences are explained below:
"all" means that messages that do not match the SPF record should be rejected. This is the strictest option and means that only servers listed in the SPF record are authorized to send emails on behalf of a domain.
"-all" also means that messages that do not match the SPF record should be rejected, as with "all", but "-all" is an older, less commonly used notation, "all" is more common.
"~all" means that messages that do not match the SPF record should be treated as suspicious, but will not be rejected. This is a softer option and allows emails to be delivered from servers that are not included in the SPF record but may be flagged as potentially suspicious.
"?all" - means that incorrect authentication does not affect the delivery of the message.
How to authenticate a message sent from edrone using SPF?
SPF is configured for the domain from the return_path (bounce domain). In edrone, we have two types of return_path because we use two email providers.
In the first one, we use the domain edrone.me, which means SPF configuration is on our side. This is ensured for every client, and in this case, you don't need to change SPF. However, we have another type.
The second type includes a subdomain of the sending domain. For example, if the sending domain (used in the sender's address) is shop.pl, then in edrone bounce domain (return_path), it will be mailing.shop.pl. To authenticate this domain, you need to add a new CNAME record, which looks like this for the above example domain:
Name: mailing.shop.pl
Type: CNAME
Value: mailing.mf-settings.com
You can find the dedicated record for your domain in our system under SETTINGS → INTEGRATIONS → SENDING DOMAIN. When you click on your sending domain, you will see a record entitled Return Path (SPF). For detailed instructions on how to add this record, see the article How to add a sending domain and authenticate it in edrone.
This record will redirect to the SPF record managed on our provider's side, so you don't have to modify your own SPF record. You can find detailed instructions on how to add and verify the record in the article “How to add a sending domain and authenticate it in edrone”
Modification of SPF on some hosts:
How do I verify that the SPF has been correctly configured?
Use an online tool, such as https://app.dmarcanalyzer.com/dns/spf, to verify the correctness of the SPF record.
In the Domain field, enter your sender domain (the one from your sender address, not your shop domain if they are different) and click Validate SPF.
If the SPF is configured correctly, you will see the message "We did not find problems with your SPF record":
If you receive the message "We could not find an SPF record" or you do not see the part which you added after verification, it is most likely that the record has not been configured correctly, or the changes have not yet been saved.
Propagation of a record (spreading across the internet) can take up to 48h, so sometimes verification immediately after addition may not be successful, so it is worth waiting and checking the entry again after this time.
The most common causes of unsuccessful verification:
verification too fast (before full propagation)
adding the SPF to the shop domain and not to the sender's domain
adding another SPF entry instead of configuring the existing one
incorrect format/type (other than TXT)
attempting to add this record on a different platform than the hosting one
so-called typos/incorrectly copied record (it will appear in the entry, but will not be correct)
If your verification has not been successful, and you are not sure what each error means, please contact your hosting provider or us (if it applies to our records) to determine the cause.
Need more help?
If you have any further questions about SPF records, please do not hesitate to contact us at hello@edrone.me