2

I am looking for an email provider that I will use with custom domain, one provider is cheaper but has only SPF while the other is more expensive but uses both SPF and DKIM and I'm not sure if paying more is worth it if the other factors are similar. I read about SPF and DKIM and I have some questions about them and also some about email security in general.

  1. What benefit would DKIM provide if SPF is already used?

  2. Is it correct to say that SPF ensures that the server from which the email claim to originate is the one from which it in fact originated and DKIM ensures that the content of the email message hasn't been modified?

  3. If it's correct that DKIM protects the message from being tampered with, then from whom does it protect exactly? Who can alter the content of the email while in transit, what are the common attack vectors? Can there be a malicious "node" that relays the email but modifies its content?

  4. Would it be possible for an attacker to make a server that relays emails and then snoop on them or modify the content, just like anybody can make a malicious Tor node?

  5. If the email provider I use supports sending emails over SSL and I want to send an email to my friend who uses Gmail (which also supports SSL), does my message travels the whole path encrypted? Does it mean that the message is encrypted with a public key belonging to Gmail and no server which relays the message will ever see it unencrypted?

  6. Let's assume that I use SPF. An attacker attempts to sends an email that appears to come from me. Where is this email relayed to (is this something called MTA)? Does it work like a node that forwards information to further nodes? If the attacker controls the first "node", can't he report to the nodes that it forwards to, that the message passes SPF when it does not and the nodes that get forwarded the message would believe it?

11

What benefit would DKIM provide if SPF is already used?

If a domain has SPF configured the receiving mail server can check if the claimed sender of the mail according to the SMTP dialog (i.e. MAIL FROM) is allowed to send mail from this IP address. This helps against sender spoofing only a bit since only the sender based on the SMTP dialog is checked but not the From header of the mail. But mail clients usually care only about the latter one.

With DKIM the outgoing mail server signs a mail and this signature can also be checked by the sender, i.e. not only by the receiving SMTP server. This signature might include the whole body but might also be include only part of the body. And while the From header is part of this signature it does not mean that the From header must be from the signers domain which means spoofing is still possible.

Spoofing of From is only addressed by configuring a DMARC policy which requires that the domain in the From header is either protected by SPF or DKIM and which specifies a policy when the requirement is not met.

Is it correct to say that SPF ensures that the server from which the email claim to originate is the one from which it in fact originated and DKIM ensures that the content of the email message hasn't been modified?

E-mails don't claim to be from a specific server but from a specific domain. And like I said both SPF and DKIM alone don't protect against spoofing the From header. And DKIM only protects part of the mail against modification: usually it protects the full body but might be configured to allow extending the body. And it only protects some headers but not all.

If it's correct that DKIM protects the message from being tampered with, then from whom does it protect exactly? Who can alter the content of the email while in transit, what are the common attack vectors? Can there be a malicious "node" that relays the email but modifies its content?

Mail is delivered hop by hop and even if it is encrypted with TLS this only is relevant between the hops. So there are many parties involved which have access to the unprotected mail and could modify it.

Would it be possible for an attacker to make a server that relays emails and then snoop on them or modify the content, just like anybody can make a malicious Tor node?

If the attacker can spoof DNS MX records which specify how a mail gets delivered or if the attacker can intercept the mail on unprotected transport or at one of the hops the attacker can modify it. But the attacker cannot simply put a server on the internet and declare it to be the responsible server for the domain, he must other parties convince that they send the mail through this server (i.e. spoofing DNS MX record).

If the email provider I use supports sending emails over SSL and I want to send an email to my friend who uses Gmail (which also supports SSL), does my message travels the whole path encrypted? Does it mean that the message is encrypted with a public key belonging to Gmail and no server which relays the message will ever see it unencrypted?

The messages travels encrypted from your mail client to the mail server of your provider, is decrypted there, modified (Received header added, maybe DKIM header) and the re-encrypted again to transport it to the next hop which might be google already or might be another upstream mail server.

Let's assume that I use SPF. An attacker attempts to sends an email that appears to come from me. Where is this email relayed to (is this something called MTA)? Does it work like a node that forwards information to further nodes? If the attacker controls the first "node", can't he report to the nodes that it forwards to, that the message passes SPF when it does not and the nodes that get forwarded the message would believe it?

While the attacker can add a Received-SPF header to the mail and thus claim the it did check for SPF a mail server (MTA) on the edge between internet and intranet receiving this mail might check again from which IP address the mail really comes, i.e. it will not trust the Received-SPF header. This header is mainly used by spam checkers which want to incorporate the result of the SPF test into their reputation check but don't run at the mail server and thus don't have access to the original IP of the sender.

  • What does it mean by saying " And while the From header is part of this signature it does not mean that the From header must be from the signers domain which means spoofing is still possible." ? Isn't DKIM used to ensure that the From header is sent by the signer's domain? – Rick Jun 14 at 10:15
  • @Rick: "Isn't DKIM used to ensure that the From header is sent by the signer's domain?" - contrary to what is often written DKIM alone has nothing to do with the From field in the mail header. Only DMARC checks if there is a valid DKIM-Signature where the domain aligns with the From field. – Steffen Ullrich Jun 14 at 10:20
  • OK, I got it after reading more materials about DMARC. SPF or DKIM alone indeed don't help much about From header spoofing. – Rick Jun 17 at 1:12
  • Hi, sir, would you like to take a look at my question about DKIM? After deploying DKIM on my server and reading RFC, I still have a few questions. :) Does DKIM protect the whole body message? – Rick Jun 17 at 9:11
2

In a nutshell, the difference between SPF and DKIM is simple: SPF uses path-based authentication while DKIM uses an identity-based authentication.

SPF uses DNS to publish a record of all mail transfer authorities (MTA) authorized to send mail on behalf of the domain. Recipient MTAs then query DNS for the SPF record and reconcile the list of approved IP addresses against the path the message actually took. SPF syntax dictates how mail is handled if the IP addresses don't match. For instance, -all means mail is either rejected entirely. ~all means mail is marked but still permitted through.

SPF has its limitations. It can be cumbersome to deploy completely (large organizations can find it difficult to track down every MTA they use) which may lead to a more passive SPF policy to prevent legitimate mail from being snagged by filters. This can increase the prevalence of phishing.

DKIM uses asymmetric cryptography to digitally sign a message. A domain has a public/private keypair. DKIM will take a hash of several fields of an email, including To:, From:, Date:, etc. This hash is then signed with the private key of the domain in question and placed in the DKIM header. The domain public key is published in DNS and used to verify the authenticity of the email.

DKIM doesn't protect against forging theFrom: field directly but it does ensure that an email truly came from the domain in question. For instance, DKIM can guarantee an email came from the domain foo-bar.com but it can't necessarily guarantee from whom within that domain sent the message, since the domain as a whole uses one keypair, not individual senders.

  • 1
    Good note. But a small correction- now a days there is a DKIM for a domain and DKIM for email. If DKIM is enabled for email too, then it CAN guarantee from whom the mail came from. – HopeKing Jun 25 '18 at 11:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.