Score:0

Changing SPF record from ~all to -all where employee inboxes are with Google and Amazon SES is used for website transactional emails

pt flag

I'm interested in moving from ~all to -all in my SPF record in order to lock down my domain emails a bit more, but I want to know what the impacts might be (I do understand at ~ is SOFTFAIL and - is FAIL).

My domain's SPF record currently looks like this: v=spf1 include:_spf.google.com ~all since we use Google Workspace for email. But we also use Amazon SES for our website's transactional emails (account registration, order confirmation, etc), so we have configured some CNAMES to enable that. And for our marketing emails we use Drip, which had us configure a CNAME as well, they use SendGrid underneath.

If I change my SPF from ~all to -all could this impact deliverability of my emails being sent via Amazon SES or Drip/Sendgrid? Instructions from Amazon and Drip do not include steps to modify my SPF record, so I'm guessing there shouldn't be an impact, but that is just a guess.

One more thing to consider is that I'm also considering making my DMARC record more restrictive as well, changing it from v=DMARC1; p=none; (no policy) to v=DMARC1; p=quarantine;. Would this also have have an impact on whether I should use -all in my SPF?

Edit with additional info:

To be a little more clear I have these CNAME entries in my DNS, and these are specifically requested by my Drip provider, and Amazon SES...

Type Name Value
CNAME drip.herobullion.com. u19706134.wl135.sendgrid.net
CNAME o6x5araaijdl472tryvyp5tvniyzv2o2._domainkey o6x5araaijdl472tryvyp5tvniyzv2o2.dkim.amazonses.com
Score:0
pt flag

Keith's answer I think could be helpful to some but I dug a little deeper and found out some additional details that helped me understand that my current SPF setup is okay and that changing to -all shouldn't affect my Amazon SES and Drip emails. Details...

DMARC report helpfully shows passing SPF

I have setup some DMARC reporting through a service called mailercheck.com that takes my DMARC xml reports and summarizes them in an easy-to-understand web report that shows which sending IPs have passing SPF and DKIM.

The top level report shows that sending IPs for my drip.herobullion.com CNAME and my *.us-west-2.amazonses.com CNAMES have all passing SPF: MailerCheck.com DMARC report - top level

And the drill down on one of the Amazon SES sending IPS gives more detail: MailerCheck.com DMARC report - Amazon SES IP

And the drill down on the Drip sending IP gives similar detail: MailerCheck.com DMARC report - Drip IP

So it appears that the SPF is passing due to the fact that my CNAME records have some SPF record associated...

CNAME DNS entries make it clearer

So above it is established that for my Drip provider the CNAME points to SendGrid's host, u19706134.wl135.sendgrid.net, so when I run dig txt u19706134.wl135.sendgrid.net to inspect TXT records for that domain I get this result:

v=spf1 ip4:167.89.40.107 ip4:167.89.40.148 ip4:167.89.79.110 ip4:167.89.79.139 ip4:167.89.93.30 ip4:168.245.74.76 ip4:168.245.95.128 ip4:168.245.99.76 -all

So, indeed these emails from my Drip provider are passing SPF because they are being sent from one of these IPS. Same story on the Amazon SES side.

But why isn't my primary domain's SPF being used by these providers?

The email's smtp.mailfrom tag is used to determine which domain name to check SPF

When I inspect one of my Amazon SES email's headers I see that the smtp.mailfrom tag specifies the sender like this

smtp.mailfrom=01010188da94f0b8-5f5e5be2-0842-4c4e-89ab-8600a4bfbc5b-000000@us-west-2.amazonses.com

and furthermore, a header says

spf=pass (google.com: domain of 01010188da94f0b8-5f5e5be2-0842-4c4e-89ab-8600a4bfbc5b-000000@us-west-2.amazonses.com designates 54.240.27.22 as permitted sender)

Similarly, my drip emails have an smtp.mailfrom="bounces+19706134-e9bb-shaun+test3=herobullion.com@drip.herobullion.com"

So even though the email has other headers such as From: Our Company <[email protected]>, the email provider will use the smtp.mailfrom tag to determine which domain to check SPF against This article explains this in a bit more detail https://www.valimail.com/blog/understanding-email-authentication-headers

With that I am relatively certain that changing my main domain's SPF from ~all to -all will not impact emails coming from these other providers.

Keith Langmead avatar
us flag
Ahh OK, so the Amazon and Sendgrid emails are being sent from a subdomain, not your main domain, and those subdomain's have their own SPF configured? That would make sense since those are then effectively controlled completely independently, and not impacted by the root domain's SPF record. Glad to hear you got to the bottom of it.
Reinto avatar
es flag
This setup used by Sendgrid and Amazon and many others is described as CNAME delegation, for example by Dmarcian from the perspective of the 3rd parety service: https://dmarcian.com/soboo-delegation-with-cnames/. The different headers and the fact that SPF is checked on the `smtp.mailfrom` and not the `header.from` is significant, because only the `header.from` field is shown in most email clients. The other reason why to have a different `smtp.mailfrom` (a.k.a. `Return-Path`) domain is to be able to catch bounces and maintain email address lists automatically.
Score:0
us flag

It can depend on how the recipient's servers are configured to treat the SPF record, but a common use would be to treat them as :

~ = If the sending server is listed within the SPF record then it's good, if it's not then evaluate it and the email just like you would if there was no SPF record there at all.

- = If the sending server is listed within the SPF record then it's good, if it's not then reject it / disgard the message as it's NOT from a legitimate source.

If you only have an SPF record in place and no DKIM setup on each of the senders (in particular Amazon and Sendgrid in your example), then you're likely already having email rejected from some destinations, as places like Gmail have started requiring SPF or DKIM to be in place for all/most emails they accept.

Whether you switch from ~ to -, I'd suggest you need to add Amazon and Sendgrid to your SPF record, so then those sources ARE listed as being legitimate for outbound email from them.

Each service likely has information (perhaps within their respective control panels / help documentation) on what the correct details are, but looking online you can find info for each in places like :

https://dmarcly.com/blog/how-to-set-up-spf-and-dkim-for-sendgrid

https://dmarcly.com/blog/how-to-set-up-spf-and-dkim-for-amazon-ses

So if you added those to your existing SPF you'd end up with

v=spf1 include:_spf.google.com include:amazonses.com include:sendgrid.net ~all

sdek avatar
pt flag
Thanks for the helpful explanations, Keith! That being said, I've discovered a few more things about my setup that let me figure out that modifying my domain's SPF to include amazonses.com and sendgrid.net won't actually be beneficial since apparently their `smtp.from` is set to an email that is related to the CNAME records, which have their own SPF records associated. If I have time I'll post more in an answer.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.