Preventing Emails from Going to Spam
When emails are sent on your behalf (i.e. looking as if they originated from your domain) from service providers (such as Helcim), they can sometimes register as spam in your recipient’s email system. This is because the SPF record in your DNS entry is not correctly set. SPF records are used by all major email providers to combat spam – it allows you to set what IP addresses are allowed to send email on your behalf.
Other service providers (Square, Quickbooks, etc.) get around this by having all emails sent through their systems register as sent from their domains. This means that emails sent to your customers using their systems appear as coming from @square.com, etc, rather than from you. If this is not important to you, simply leave the sent email domain as firstname.lastname@example.org and your emails should be delivered without issue. At Helcim, we understand most business owners like a more cohesive customer experience and might prefer to have email communication with their customers look like it is coming from their own domain. That’s why we allow you to set the sent email address as your own.
If the emails you are sending via Helcim Commerce (or the legacy Helcim Gateway) are going to your customers’ spam folders, the solution is quite simple, though does require a bit of technical ability. Those of you who administer your own domain should have no problem with the instructions below. If you have a web/domain administrator, send them the instructions below and they should have no trouble making the change. Once complete, emails sent from our systems on your behalf should arrive in your customers’ inboxes without issue.
- Create a TXT record in the DNS entry for your domain name or modify your existing one.
- Domain name that you should include in your SPF entry: spf.helcim.com
- If you do not have an existing SPF TXT record:
- You can add: v=spf1 include:spf.helcim.com -all to allow email from Helcim to be sent on your behalf.
- However, if you send email from anywhere but us (i.e. Office 365) those emails will start failing the checks for their normal delivery. You will have to look up your email providers' SPF domain name and add it as well. For example, to use Office 365 you would put the following: v=spf1 include:spf.protection.outlook.com include:spf.helcim.com -all
- If you have an existing SPF TXT record:
- If your SPF record was:
- v=spf1 include:mail.example.com -all
- It will now change to:
- v=spf1 include:mail.example.com include:spf.helcim.com-all
DMARC is a TXT record that you set for your domain that tells email receivers how to treat your message if it fails the SPF or DKIM checks.
If you are using DMARC, you will have to set your policy to 'none' to allow us to send emails on your behalf. Setting the policy to none means that messages will still be delivered even if they fail SPF + DKIM checks.
An example DMARC policy: "v=DMARC1;p=none;pct=100;rua=mailto:email@example.com"
If you don't wish to change your DMARC policy, you can leave the default firstname.lastname@example.org email address as your FROM email in the Commerce settings and the emails will get delivered. Click here for more info on Commerce email settings.
If you are using Gmail, Yahoo, Outlook, etc. (a domain you do not own) as your business email, it's very likely that if we send email using that FROM address, it will not be delivered. The DMARC settings for these providers are particularly strong. If you use one of these providers, it is likely best that you leave the FROM email address as the default email@example.com.