SPF, DKIM and DMARC records

Update! Gmail and Yahoo Deliverability Changes for 2024

Everything in this document remains valid, even after the Gmail and Yahoo updates for 2024 -https://blog.google/products/gmail/gmail-security-authentication-spam-protection. The only additional recommendation is to avoid using @gmail.com or @yahoo.com in the "From email address" field. We strongly recommend that you use another email instead to ensure high deliverability of your notifications.

SPF

SPF settings for accounts that are using a custom domain for delivery are different from accounts that use default Back in Stock domains. If you don’t know if your account has a custom domain set, please contact Back in Stock support.

Accounts using default domains

No action is necessary to set SPF if your account uses the default Back in Stock domains. For technical details, continue reading.

Technical Details

SPF is used to check if the domain in the sender field allows the IP address where the email comes from to send emails on its behalf. Back in Stock uses the following default domains:

backinstockemail1.com, backinstockemail2.com

Our IP is 166.78.70.136. When an email delivers to the customer, the customer’s server (Google, Yahoo, etc.) will check if there are SPF records set in 166.78.70.136 for the backinstockemail1.com and backinstockemail2.com domains. We have those entries set, so the SPF check will PASS.

You can verify this information by checking the raw email source code. Here is an example of a notification delivered to a Gmail account:

Received-SPF: pass (google.com: domain of [email protected] designates 166.78.70.136 as permitted sender) client-ip=166.78.70.136;

Accounts using a custom domain

You’ll need to have SPF configured in the server that hosts that custom domain. Please contact Back in Stock support if you think your server is not properly configured.

DKIM

If your account is using a custom domain, please contact Back in Stock support to confirm your server is properly configured.

For accounts that use default domains, no configuration is necessary. To check that DKIM is working properly, open the raw source of a notification email, it should contain a text similar with the one below:

dkim=pass [email protected] header.s=k1 header.b=swumfNtf;
dkim=pass [email protected] header.s=mg header.b=SLSCzEBb;

DMARC

If the email domain your account is using to deliver notifications (the domain in the "From email address" field in Customize > Template) doesn't have DMARC records, a custom domain is not necessary. A custom domain is also not required if the DMARC policy is set to none, because even if DMARC test fails, the server will deliver the emails. This option is usually used for reporting.

But if the domain server has DMARC set to quarantine or reject, you'll need either to:

1. Only available for paid plans - Ask Back in Stock support to register a custom domain, like mystore.com, or a subdomain of that store, like backinstock.mystore.com. Then both the From attribute and Return-Path will come from the same domain.

2. Ask the server administrator to add the IP we use to deliver notifications, currently 166.78.70.136, as an exception to DMARC records, so that our notifications won't be rejected or quarantined.

Technical details

DMARC supports three settings for policy: none, quarantine and reject. They inform that if SPF, DKIM, or DMARC alignment fails, the email may be ignored (let it pass), held in quarantine, or rejected. Back in Stock requires a custom domain if the store has policy set to p=quarantine or p=reject because of DMARC alignment (see below).

DMARC alignment checks if the email attributes Return-Path and From have the same domain. It fails for default domains because we use backinstockemail1.com or backinstockemail2.com to deliver notifications, and these are the domains set in Return-Path. But the From attribute has a different domain.

Read here why to use backinstock.mystore.com instead of mystore.com in both fields (In Why subdomains section).

What to use in From field?

You should update the From field to use exactly the same subdomain: [email protected].

Technical details

If DMARC policy in your domain server is set to relaxed (default), then only the domain must match, not the subdomain. But if it is set to strict, the From field and the Return-Path fields must be exactly the same. So to be safe we should use exactly the same domain. More info about DMARC policy: https://mxtoolbox.com/dmarc/details/dmarc-tags/aspf

More info about DMARC:

https://sendgrid.com/blog/what-is-dmarc/

https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html

Verify DMARC settings here:

https://mxtoolbox.com/SuperTool.aspx.

'via' and 'on behalf of'

If the Sender field doesn't match with the From field, Gmail will display the 'via' text in the sender and Outlook will show 'on behalf of'.

To prevent this from happening, we must add a custom domain for that store in Mailgun.

More information here: https://help.mailgun.com/hc/en-us/articles/360012491394-Why-Do-I-See-On-Behalf-Of-in-My-Email-

Additional documentation

External references about SPF records. For specific information, contact your host provider (the way to add SPF records can differ slightly between host providers).

1) https://support.google.com/a/answer/33786?hl=en

2) https://postmarkapp.com/blog/explaining-spf

3) https://serverfault.com/questions/283125/how-to-include-multiple-domains-in-an-spf-txt-record

Warm-up phase:

New sending domains will be using our mail servers dedicated IP addresses, which carry a very high reputation, so there's no need to go through a warmup phase.