Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I understand that

  • SPF "binds" a message envelope to a set of permitted IP addresses.

  • SenderID (with the default pra option) "binds" the message header to a set of permitted IPs in addition to the SPF logic.

  • DKIM "binds" the from address header (and any additional header the sender chooses), and the body to a DNS Domain name

I'm using the word "bind" above instead of "authorized" because it makes more sense (to me)


  1. If SPF is already verifies a message FROM in the envelope, why is there a need to check the headers?

  2. When would the need to verify the envelope (SPF) need to be different than the headers (SenderID)

  3. If I'm already verifying the headers with DKIM, why do I need SenderID?

  4. Most large companies I've checked don't disable SenderID with an explicit record. EBay is a notable example of one that does. What is the rationale for disabling SenderID "pra" processing of outbound messages?

share|improve this question

I think the first reason you would do implement your SPF, SenderID and DKIM is that not all email providers check for the same things.

See for a table of providers and authentication methods they use.

So in order to ensure that your message get accepted by the largest amount of email providers, doing all the authentication methods would be best.

Technically, there is some overlap. It's mostly due to adoption of the methods by email providers and servers.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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