Thanks guys - very helpful information indeed. On Mon, Aug 29, 2016 at 9:08 AM, Mike Ragusa <mrag...@gmail.com> wrote:
> Ideally it is best to use both technologies and then put DMARC on top to > ensure reporting and enforcement of the policies. DKIM cryptographically > signs your messages and SPF informs receiving mail servers of who is > allowed to send on your behalf. You should not think of using only one or > the other as they work best together to accomplish the same goal. When > utilizing DMARC on top of it all, you get the added benefit of reporting > from over 200 different ISPs from around the world. In general, DKIM is > first used as the authentication method and SPF as a backup. > > If you have a valid DKIM key, then failed SPF should not matter but if you > have a failed DKIM key and SPF passes, there still may be deliverability > issues to account for. If you do enable DMARC, then your DKIM and/or SPF > headers must align with your domain or you will encounter deliverability > issues depending on how your policies are setup. DKIM in relaxed mode > allows for mail to pass the test with the same parent domain but > canonicalization requires that your domains match up exactly as stated ie > example.com and mail.example.com are not the same and will fail. SPF with > DMARC requires two or more FROM headers (https://tools.ietf.org/html/ > rfc2822#section-3.6.2) match up exactly or it will fail SPF checks but > without DMARC anyone listed in the sender policy can send on your behalf. > While this may seem strange at first, this is to prevent people from > signing up to something like google and sending on your behalf with the > default google DKIM key and a wide open SPF policy. > > With DMARC: > DKIM : headers must match domain or else fail > SPF: 2 or more headers must match domain or else fail > > Without DMARC: > DKIM: just needs to be signed by sending mail server > SPF: just needs to be send from a valid sender > > Depending on your needs, I would recommend putting SPF in soft fail, DKIM > in relaxed mode and DMARC in reporting mode only for the first 15-30 days > and see how your traffic looks and who is sending on your behalf. Once you > have a comfortable baseline, start to tighten up your policies. > > > > > On Mon, Aug 29, 2016 at 9:51 AM project722 <project...@gmail.com> wrote: > >> What about DKIM only? Can it be used instead of, or, as a "replacement" >> for SPF? For example mails are signed with DKIM from the SMTP servers, and >> the receiving servers are checking both SPF and DKIM. If the receiving >> server detected a missing SPF would it allow mail through if DKIM is >> present and valid? I suppose a lot of this depends on the SPF policies >> enforced on the receiving side. >> >> On Mon, Aug 29, 2016 at 1:53 AM, Dave Warren <da...@hireahit.com> wrote: >> >>> The easiest answer is: Whatever you want. Strictly speaking, >>> alphazulu.com can send mail on behalf of foxtrot.com using a >>> alphazulu.com DKIM selector, and that's perfectly valid under DKIM. >>> However, it won't have DMARC alignment, which is becoming more and more >>> important, so if alignment is relevant, you'll need to use a foxtrot.com >>> selector. >>> >>> tl;dr: Use a foxtrot.com selector unless you simply can't. >>> >>> As for who generates it, it's irrelevant. The sending server will need >>> the private key, your DNS records will contain the public key, but it makes >>> no difference if foxtrot.com creates the keys and delivers them to the >>> appropriate parties, or if alphazulu.com generates generates a private >>> key and provides the alphazulu._domainkey.foxtrot.com record to >>> foxtrot.com. >>> >>> Remember that you can have as many selectors as you want, don't reuse >>> them across trust boundaries (in other words, consider that in the future, >>> foxtrot.com and alphazulu.com may part ways, when that happens, it's >>> ideal if you can remove the selector from your DNS (after a period of time, >>> at least a week), such that alphazulu.com cannot continue to sign mail. >>> It's also ideal if you don't have to update DKIM records elsewhere in your >>> infrastructure. >>> >>> I hope at least some of this makes sense, but if not, ask. DKIM and >>> DMARC are fiddly, and a lot of the DKIM advice out there isn't entirely >>> complete now that DMARC is on the scene and DMARC builds on top of DKIM and >>> SPF. >>> >>> >>> On Sun, Aug 28, 2016, at 16:13, project722 wrote: >>> >>> Lets say my domain is foxtrot.com and we have SPF records for the SMTP >>> servers on foxtrot.com. Now lets say I have decided I want to allow >>> alphazulu.com to send mail as foxtrot.I know how to add alphazulu.com >>> to the SPF but If I wanted to also use DomainKeys or DKIM to authenticate >>> alphazulu.com would the keys need to be in foxtrots name or alphazulu? >>> For example, >>> Would I use: >>> >>> _domainkey.foxtrot.com. IN TXT "t=y\; o=~\;" >>> xxxxxxx._domainkey.foxtrot.com. IN TXT "k=rsa\; >>> p=xxxxxxxxxxx >>> >>> or >>> >>> _domainkey.alphazulu.com. IN TXT "t=y\; o=~\;" >>> xxxxxxx._domainkey.alphazulu.com. IN TXT "k=rsa\; >>> p=xxxxxxxxxxx >>> >>> Also, >>> 1) Who generates the keys? Foxtrot or Alphazulu? >>> 2) Would I need both SPF and keys or would keys alone be enough to >>> authenticate the other domain? ( I am in a position where I would like to >>> use only keys) >>> 3) Which one is better to use in terms of provider checking? For >>> example, are providers even checking keys as much as they are SPF? >>> >>> *_______________________________________________* >>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to >>> unsubscribe from this list >>> >>> bind-users mailing list >>> bind-users@lists.isc.org >>> https://lists.isc.org/mailman/listinfo/bind-users >>> >>> >>> >>> _______________________________________________ >>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to >>> unsubscribe from this list >>> >>> bind-users mailing list >>> bind-users@lists.isc.org >>> https://lists.isc.org/mailman/listinfo/bind-users >>> >> >> _______________________________________________ >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to >> unsubscribe from this list >> >> bind-users mailing list >> bind-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users > >
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
