Starting in February 2024, Gmail and Yahoo will require all email senders to have a SPF, DKIM, and a DMARC record which aligns with a DKIM record on their DNS record.
There are many reasons your email blast may not get delivered to your supporters' inboxes. This article highlights what you can do to reduce the risk of your email not being delivered.
Set Up a Sender Policy Framework (SPF) Record
Email service providers include security to enable email recipients to know who is sending a given email. The intent is to prevent spoofing, which occurs when one sends an email that appears to come from one source but comes from another. This is a common practice used by spammers to trick people into opening, reading, and clicking emails.
This information is usually hidden in the headers of an email (code you don’t normally see but which tracks the journey of an email). Email service providers have begun to add “via” information to show who is sending the email. So even though your blasts are coming from xyz@yourorg.com, the email service provider will show that messages are being sent by Salsa Labs. Here's an example of what this looks like in a Supporter's inbox:
This will no longer appear to the email recipient once the email service provider concludes that the email recipient wants to receive messages from the sender. For example, if the supporter replies to a message or adds your address to their address book, Gmail (or any other email service provider) will conclude that the supporter wants to hear from you.
Email service providers check several ways to see if a message is authentic, but the easiest road to authentication is to set up an SPF record. SPF records verify that email senders (like Salsa) have permission to send an email on your behalf. Adding an SPF record to your email system allows your email servers to approve emails sent by Engage on your behalf. If you don't have an SPF record set up when you add an email address to the "Sent From" field for a Salsa Engage Email Blast, Salsa Engage will prompt you with a warning.
Salsa staff cannot set this up for your organization. You'll need to work with your IT staff. If you are using common web hosting platforms, we have provided walk-throughs from their help desk:
- Click here for GoDaddy
- Click here for BlueHost
- Click here for Google Apps/GSuite
- Click here for NetWork Solutions
- Click here for DreamHost
- Click here for 1&1
- Google Apps
- Host Gator
- Office 365
- Wix
NOTE: Before you begin, make sure you can add or edit a TXT entry to your DNS records. There can be only one SPF record per domain.
PRO TIP: If you're not sure who your domain host is, please go to https://whois.com and enter your domain, you can then look that up and the data will give you insight on who host's your domain.
Once you've made your SPF updates, enter your domain at https://mxtoolbox.com/spf.aspx to confirm that the changes have worked. The following image illustrates what you'll see (in MXToolbox) when you've set up your SPF correctly.
*PLEASE NOTE: It can take up to 24 hours for your changes to populate. DNS records for your domain normally will not update in real-time.
Tips About Adding Your SPF Record (For IT Professionals)
Implementation
The format varies between various DNS platforms. Please consult your specific documentation for instructions to enter an SPF record as a TXT record. It should look similar to...
-
- TXT "v=spf1 mx include:salsalabs.org -all"
NOTE: Do not add your own domain after the TXT. It's not necessary and would create an infinite loop.
To update an existing SPF record...
- Insert include:salsalabs.org into your current configuration, just before the "all" mechanism. This tells the SPF record requestor to look up the record for salsalabs.org and include that information in the organization's SPF response.
Syntax
This typical SPF record contains a breakdown of what each component of the SPF string does.
v=spf1 mx include:salsalabs.org ~all
- v=spf1 means SPF version 1 or SPF Engage, the current version of SPF. This identifies the TXT record as an SPF string.
- MX is a mechanism to show which email servers should be used when relaying email.
- include:salsalabs.org is a mechanism indicating that any server permitted to send mail from salsalabs.org may also send mail from your domain.
- SPF records cannot be over 255 characters in length and cannot include more than ten include statements, also known as "lookups." Nested lookups will also count. If a record has an MX lookup, these will both count as lookups for your domain.
- -all means that all other mail not explicitly permitted by the rest of the SPF record can be accepted but will be marked for greater scrutiny. The all tag is an important part of the SPF record as it indicates what policy should be applied when ISPs detect a server that is not listed in your SPF record. If an unauthorized server does send an email on behalf of your domain, action is taken according to the policy that has been published (e.g. reject the email or mark it as spam). What is the difference between these tags? You need to instruct how strict servers need to treat the emails. The ~all tag indicates a soft fail and -all indicates a hard fail. The all tag has the following basic markers:
- -all Fail—servers that aren’t listed in the SPF record are not authorized to send the email (not compliant emails will be rejected).
- ~all Softfail—If the email is received from a server that isn’t listed, the email will be marked as a soft fail (emails will be accepted but marked).
- +all—We strongly recommend you do not use this option. This tag allows any server to send emails from your domain.
- -all Fail—servers that aren’t listed in the SPF record are not authorized to send the email (not compliant emails will be rejected).
Troubleshooting
You should use the include statements and domain names and not IP addresses. If Salsa changes IP addresses or adds email servers, those changes are reported immediately to the DNS servers that guide domains in knowing what IP addresses are.
Configure a Custom DKIM Signature
PLEASE NOTE: THERE ARE ARTICLES BELOW ON HOW TO MAKE DNS CHANGES FOR POPULAR WEB HOSTING AND DNS PROVIDERS. HOWEVER ONLY USERS WHO ARE INTIMATELY FAMILIAR WITH MAKING DNS CHANGES TO YOUR ORGANIZATION'S DOMAIN SHOULD DO THIS.
Within Salsa Engage, you can now generate your own DKIM signature to ensure messages from Salsa are signed with your domain. To access this option, click on the Settings icon(Hammer and Wrench) at the top right of your Engage account. From the teal Switch to menu, choose DKIM.
On this page at the bottom, you will need to enter the domain of the From Address you use for autoresponders, email blast and series messages.
Once you enter your domain and click add, you will be provided an encrypted key you will need to enter into your web host or DNS provider.
With this code, there are actually 2 sections you would insert the block of text into.
The code before the TXT goes into your Host or Name section. This labeling may differ from provider to provider. From the screenshot above, the s20225125.domainkey goes into the first input box when setting this up. The code after the TXT will go into the main input box for the DKIM key (everything inside the quotation marks).
Once inserted, please allow for up to 24 hours for the DNS changes to propagate. Then click the orange VERIFY button to have Salsa recognize these changes. The status will change to "Pending" if the TXT record is recognized. Overnight, the values will be added to the email servers and then you will be able to send Salsa emails and they will be signed with your domain when delivered to your supporters. This will also ensure your Salsa Engage emails will comply with DMARC if that is active on your domain as well.
Provider specific instructions