An email system typically consists of multiple agents:

  • Mail user agent (MUA)
  • Mail submission agent (MSA)
  • Mail tranfer agent (MTA)
  • Mail delivery agent (MDA)

Mail agent netword

Evidently the 'middlemen' of this system are a spoofing risk. (Technically the endpoints could also be a spoof risk, but let's assume in this case that the end users are genuine.)

What methods are used/can be used to protect against these 'middlemen' agents being spoofed?

I've thought about it myself and the only answer I can come up with is that DNS might provide some sort of limited authentication, though DNS spoofing would still be a risk.

(Image is CC BY-SA 3.0, © Ale2006-from-en.)

  • There's always at least one legitimate host address in the header chain, before an external email gets into your system. Many email service providers will filter messages coming from or passing through a known open relay.
    – Ghedipunk
    Commented Sep 27, 2019 at 19:57

2 Answers 2


Delivery from the MUA is usually done to the domain specific mail provider (MSA in your image). This communication is typically done either inside a companies protected network or to some external mail provider. Mail delivery inside the local network is usually protected against DNS spoofing as long as it can be assumed that there is no attacker inside the local network or that he will not make itself easily visible with DNS spoofing. When using an external mail provider the connection is usually protected by TLS. TLS will protect against DNS spoofing and other traffic rerouting since the MUA will check the subject of the certificate and that it was issued by a trusted CA etc. TLS will also protect against sniffing and modifying the traffic even if the attacker manages to get in the path of mail delivery.

As for MTA/MSA to MTA/MDA communication: this happens on networks where DNS spoofing is not easy too, i.e. this is not on some public hotspot where an attacker could easily inject himself. Additionally DNSSec might be used although lots (if not most) DNS MX/A/AAAA records are currently not protected by DNSSec. But using DNS spoofing to target a specific mail is impossible due to all the caching of DNS. Using it to target all mails to a specific domain is hard too since these might come from various sources which means DNS spoofing might need to be done in various places which might make the attack too visible. The same is true for other ways to reroute the traffic, like BGP hijacking. If the attacker still manages to actively get in the path of the mail delivery though he can likely sniff and modify the traffic since usually there is no TLS enforced between MTA or that the MTA don't properly check the certificates.

None of this actually makes attacks really impossible, it only makes it less likely in most cases. Well-equipped attackers (like governments) will likely be able to mount attacks especially against less protected domains. They might not necessarily attack delivery between MTA/MSA/MDA though since such attacks are more visible to others. Instead they might do a more targeted and less visible attack directly against the victims MDA or the victims mailboxes. The latter is often done using phishing mails to get the users mail account credentials or by delivering malware to attack the victims computer and thus get access to the mails too.


DMARC, which uses SPF and DKIM, is the current state of the art for validating an email's authenticity. To quote their web page,

DMARC, which stands for “Domain-based Message Authentication, Reporting & Conformance”, is an email authentication, policy, and reporting protocol.

To quote Wikipedia:

Sender Policy Framework (SPF) is an email authentication method designed to detect forging sender addresses during the delivery of the email.


DKIM allows the receiver to check that an email claimed to have come from a specific domain was indeed authorized by the owner of that domain. It achieves this by affixing a digital signature, linked to a domain name, to each outgoing email message.

  • As far as I understand the question it is not about validating the authenticity of the mail but about an attacker accessing (and maybe manipulating) a valid mail on the path to the recipient by somehow putting itself in the path of the mail delivery. Commented Sep 27, 2019 at 20:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .