Comments for SPF, DKIM and DMARC brief explanation and best practices

[phinjensen]

Comments for https://www.endpointdev.com/blog/2014/04/spf-dkim-and-dmarc-brief-explanation/ By Emanuele “Lele” Calò

To enter a comment:

1. Log in to GitHub
2. Leave a comment on this issue.

[phinjensen]

original author: Jon Jensen
date: 2014-04-17T21:21:24-04:00

Good explanations of complicated email details, Lele! These things would ideally just work behind the scenes but it's good for even less-technical people to have some idea of how things fit together.

On the pedantic side, I want to note that there is a specific SPF DNS record type, and the generic TXT record type is only a transitional fallback that some far future day shouldn't need be used for SPF anymore.

As you noted, DKIM uses TXT records now. I haven't seen any proposals to add a specific DKIM record type to DNS.

[phinjensen]

original author: Emanuele 'Lele' Calo'
date: 2014-04-18T09:43:50-04:00

Jon, I used the TXT record as a referral cause the SPF record has been deprecated sine last August. [1]

But thanks for pointing out its existence otherwise people finding it would have been clueless of how to use/manage it.

For the moment I still always create the very same record both in TXT and SPF, but overtime it'll make sense to switch permanently (again) only to the TXT record.

[1] http://en.wikipedia.org/wiki/List_of_DNS_record_types

[phinjensen]

original author: Jon Jensen
date: 2014-04-18T11:22:31-04:00

Thanks for the pointer, Lele. I had not heard that the SPF record type is being phased out!

It's kind of sad that everyone went to the trouble to support a specific record type so you don't waste time fetching TXT records that may not have anything to do with SPF, and yet now it won't be used, but SPF record types will continue to be supported in DNS! So it goes, I guess.

I read the details here: http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-21#section-3.1

[phinjensen]

original author: Lavanyam:)
date: 2015-06-20T00:38:57-04:00

I have a scenario with 3rd party vendors... Our company has a lot of 3rd party mail services. I have set up the dmarc with p - none and SPF records were updated with known sending servers. Could you please clarify a statement which I read in Dmarc.org site about making 3rd party vendors Dmarc compliant.

1. Either add their sending servers to our spf records
2. Or share your DKIM private key to them

My question is, SPF checks for envelope from address so when the vendor sends mails on behalf of us, the from address will be our company address and envelope from will be his company. So then how will SPF pass? SPF will check the dns server of envelope from? Is my understanding right?

Secondly, DKIM checks from address or envelope from address? How does it work when we share the private key

[phinjensen]

original author: lucas
date: 2016-07-05T14:02:45-04:00

I know this post is old. But I'm helpless. I have administrated 2 Google Apps for 9 years already and the last year I started to configure SPF, DKIM and DMARC and SPAM just got worse. I get many impersonations (sending emails with my domain that doesn't exist), many DMARC fake reports and so on. I've re-checked and it's correctly configured. My feeling is that using those 3 have worsened. Why I think that? Because my 2º Google Apps account didn't have any of this and I hadn't this kind of spam. Since I've transferred my domain from google to another registar and setup the SPF, DKIM and DMARC it start right away with those nasty spams. Am I crazy?

[Dustinlheld]

upon reception the receiving mail server checks if there is any existing DMARC policy published in the domain used by the SPF and/or DKIM checks