SPF and domain keys

Mon Aug 29 14:33:49 UTC 2016

Thanks guys - very helpful information indeed.

On Mon, Aug 29, 2016 at 9:08 AM, Mike Ragusa <mragusa at 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 <project722 at 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 <davew at 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 at 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 at 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 at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20160829/d1c87aaf/attachment.html>