In the previous blogpost I have been discussing how SPF works and how it uses public DNS to validate the authenticity of the sending SMTP servers. When SPF is implemented correctly a receiving mail server can validate is the sending mail server is allowed to send email on behalf of the sender or his organization.
In this blogpost I will discuss DKIM signing as an additional (and more complicated, and more difficult to spoof) step in email validation.
As a quick reminder, here’s how my lab environment looks like:
There’s an Exchange 2016 CU2 Mailbox server hosting several Mailboxes, and there’s an Exchange 2016 CU2 Edge Transport server. An Edge synchronization will make sure that all inbound and outbound SMTP traffic is handled by the Edge Transport server.
In my previous blogpost an SPF record was created and implemented with the following value:
v=spf1 a:smtphost.exchangelabs.nl ~all
so receiving mail servers can validate that my Edge Transport server is allowed to send email on my behalf, and when mail is originating from another mail server it might well be a spoofed message.
But for now let’s continue with DKIM. Continue reading SenderID, SPF, DKIM and DMARC in Exchange 2016 – Part II
You must be logged in to post a comment.