Email authentication is not a simple process. There's no one methodology baked into the internet specifications for email, unfortunately. But there are a number of technologies out there that help with this process. In order to prevent forgeries and email spoofing, we use them all to help identify malicious messages.
But don't worry - MailRoute will take care of your Email Authentication needs. We just need you to set up some stuff in your DNS so that we can manage it afterwards.
Here's what you need to know
First, a little bit of background info:
Every email has two different "from" addresses. One is in the header, and one is in the SMTP envelope. Think of them as being analogous to the return address on an envelope, and one on the letterhead of the note inside.
The envelope MAIL FROM header is a return address. It tells the email servers where to return a failed message, or where to send bounce or other delivery status notifications.
The other header is the "From:" header in the email header. This is what email users see. It's typically set by the sender's email client.
Email authentication attempts to validate these "from" addresses and ensure that they are coming from servers that are authorized to be sending email on those senders' behalf.
We have three three email authentication protocols to help fight forgeries, spoofing, and impersonation attacks: SPF, DKIM, and DMARC.
What is SPF?
SPF (Sender Policy Framework) helps to detect sender forgeries in email. SPF allows the receiving mailserver to check that email claiming to come from a particular domain does indeed come from an authorized IP address. The list of authorized sending IP addresses is published in the DNS of the sending domain.
But here's a quick summary.
SPF uses the email address provided in the SMTP Envelope sender (MAIL FROM). The recipient's email server looks up a TXT or SPF record in the DNS of the sender's domain, and is able to use that information to determine if the sending mailserver is allowed to send email for that domain.
SPF isn't perfect. It breaks many types of email forwarding. That's why we don't blindly reject email that violates SPF. But we do use any SPF violations to contribute to a higher overall SpamScore for a message, and we use that information in conjunction with DMARC and DKIM records, as available, to determine if a message may be a forgery.
And SPF, being based on the envelope from address, does nothing to prevent forging of the "From:" header that users typically see in their email clients. It just makes sure that the SMTP envelope "MAIL FROM" sender is sending from a server that is allowed to send mail for that domain.\
See our KnowledgeBase article on Implementing SPF for the MailRoute Outbound/SmartHost Service
What is DKIM?
- That the contents of the email have not been modified.
- That certain important headers, including the Subject, From, and various Received headers have not been been modified and no new important headers (like Subject or From) have been added.
- That the sender of the email is authorized by the owner of their domain.
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=domain.com; h=x-mailer:date:date:message-id:subject:subject:mime-version:content-transfer-encoding:content-type:content-type:from:from:received:received; s=01; t=1544226411; bh=g3zLYH4xKxcPrHOD18z9YfpQcnk/GaJedfustWU5uGs=; b=tEsR3mOyyUWXmg1iOU75oTHZhpwLCwxPtOfJxE+7Dwxz1cP7YwiErj68sBcH6C2nfi8fiX3nY89AQdYBqe1VXj3TGS+9aRjET9h565y6GSgsb0O/3lbSpu0ZVFwgWG3dN0u49e/dsxpnJgWqLk6eeRsJg1jj8lOgx2Rlp2E0ajg=
dkimkey._domainkey.domain.com. 3600 IN TXT "v=DKIM1\; p=" "MIGfMA0GCSqGSIb3DQEBAQUAA4GNIDJEKSLIgQDADOGoDBzA2ZAOCW7gtmnvCsr/" "tnpLrsDJo8Tm4v0KNRxhVxm75Jj/1oNY/zGqvmNh+nfn+mWJSOIENCksGo67xxom1" "qVZ7U3P3zwAt0vPMrPh96j/fnwUtGcxvfRasfGFkRRAx32HQ1dvXt+JO5b10RMUs" "gr1MGrgUtfJsskLQbwIDAQAB"
mr01._domainkey.<domain>. CNAME mr01.dkim.mailroute.net.
mr02._domainkey.<domain>. CNAME mr02.dkim.mailroute.net.
mr03._domainkey.<domain>. CNAME mr03.dkim.mailroute.net.
See our KB article on Implementing DKIM for the MailRoute Outbound/SmartHost Service
What is DMARC?
_dmarc.domain.com. 3600 IN TXT "v=DMARC1; p=reject;"
What about ADSP?
Long before DMARC came along, there was a little thing called ADSP (Author Domain Signing Practices). The was an RFC in 2009, but it was abandoned in 2013 because of general lack of use. Wikipedia has the details, as usual.
Why? Because DMARC doesn't have any feature that specifies that every single message from a particular domain MUST be signed with DKIM. A message that breaks DKIM or SPF is penalized, but an unsigned message doesn't get penalized (it doesn't get any nice bonus points either, but it's not automatically relegated to the quarantine or the trash).
_adsp._domainkey.domain.com. IN TXT "dkim=all"
And I know you're expecting another KB article on that, but we just added it to the one on Implementing DMARC for the MailRoute Outbound SmartHost Service