I think it's a bit different from this question since it's about SMTP, but similar idea. Wikipedia says on email spoofing:

MAIL FROM: - generally presented to the recipient as the Return-path: header but not normally visible to the end user, and by default no checks are done that the sending system is authorized to send on behalf of that address.

So is there a reason why we don't check? It would seem to make sense we'd have some form of digital signature to check.

1 Answer 1


So is there a reason why we don't check?

Because SMTP was designed at a time where the sender was considered trusted. The origins date at least back to RFC 788 from 1981, i.e. at a time where only comparably few nodes on the internet existed, mails could be easily traced back to the sending node by IP address and sender spoofing was not an issue.

It would seem to make sense we'd have some form of digital signature to check.

A digital signature would require to have each sender some kind of key or certificate in the first place. Also this certificate would need to be widely trusted because otherwise one could not really check if the sender is the one he claims (i.e. self-signed certificates would not help). One also would need some infrastructure to revoke and renew certificates in case they were compromised.

Instead it is common today to require authentication by the end user. But since SMTP is a hop by hop model where the end user only sends the mail to the first hop and the next hop forwards the mail in behalf of the original user the other hops are still somehow need to trust each other. There are some mechanism to make at least sure that the claimed senders IP address is somehow associated with the senders IP (SPF), to have some trustable path between mail servers (DKIM) and to align the SMTP.MAILFROM with the RFC822.From (i.e. SMTP envelope with mail header) as done with DMARC. Only, these "add-ons" are not sufficiently employed to broadly protect against sender spoofing.

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.