Sender Policy Framework (SPF)

There is no need to update the SPF records to send emails from Envoke. To understand why, here's a brief overview:

Emails in general have two sending addresses associated with them:

the "envelope sender", and the "from address".

  • The envelope sender works in the background; it is where computers respond (in the case of bounce messages or errors)

  • The from address is visible to contacts; this is where people respond.

SPF is used to validate the envelope sender. Envoke's envelope sender (Return-Path header) is always lists.bettermail.ca which is the address that is being verified by SPF records and we manage the SPF record for its domain.

The from address can be customized to use any email you like. The sending domain for this email address should be authenticated using Domain Keys.

This means you can send messages through Envoke, using your own from address without updating your SPF record.


Additional technical details for forwarded messages:

SPF records and forwarded messages

smtpX.mailsender04.com is the name for some of our SMTP servers, this however is not being verified by SPF records.

Our SPF records for bettermail.ca allow sending from all of our IP ranges.

See the following sample SPF pass header from Gmail for example.

spf=pass (google.com: domain of xxx-xxxxx-xxxxx@lists.bettermail.ca designates 216.105.95.193 as permitted sender) smtp.mail=xxx-xxxxx-xxxxx@lists.bettermail.ca

The problem with some forwarded emails is that the destination still checks the SPF records of the original sender (our Return-Path header).

Since the IPs of the forwarding server are not in our SPF records it will be rejected by the destination server due to our SPF policy which was previously set to a hard fail "-all".

This really is not a problem with the SPF records but how the forwarding is done. 

Please see http://www.openspf.org/SRS or http://en.wikipedia.org/wiki/Sender_Rewriting_Scheme for help in implementing the Sender Rewriting Scheme.

Our SPF records will allow forwarded messages to be classified as a soft SPF fail instead of the original hard SPF fail.

Did this answer your question?