SPF and domain keys

Mon Aug 29 14:08:33 UTC 2016

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/b2268873/attachment-0001.html>