Email Authentication by using DMARC, DKIM and SPF
In this post I want to show how you can prevent that your email domain is abused for email spoofing (forged sender addresses) and phishing.
The original SMTP protocol out of box is not designed to provide and proof the origin of email messages.
Therefore we can use techniques like DMARC, DKIM and SPF. Before I will show how to set up each of them, we will first see how each of them work and how they play together.
With the assistance of SPF and DKIM, DMARC helps combat spoofing, phishing and Business Email Compromise (BEC). DMARC can exist without one of both, SPF or DKIM, but it’s highly recommended to follow best practices and implement all three.
SPF, DKIM and DMARC are for message authentication purposes. This will make sure your email domain is much harder to spoof and receiving email systems know that the source of your email is a trusted source.
Sender Policy Framework (SPF)
First we will see how the Sender Policy Framework (SPF) will help to avoid email spoofing and phishing.
SPF allows the owner of an Internet domain to specify which computers (IPs and FQDNs are authorized to send mail with envelope-from addresses (“Mail From” address:) in that domain, using DNS TXT records.
SPF uses a DNS TXT record to list authorized sending IP addresses for a given domain. Normally, SPF checks are only performed against the 5321.MailFrom address.
The 5322.From address isn’t authenticated when you use SPF by itself, which allows for a scenario where a user gets a message that passed SPF checks but has a spoofed 5322.From sender address.
- “Mail From” address: Identifies the sender and says where to send return notices if any problems occur with the delivery of the message (such as non-delivery notices). Mail From address appears in the envelope portion of an email message and isn’t displayed by your email application, and is sometimes called the 5321.MailFrom address or the reverse-path address.
- “From” address: The address displayed as the From address by your mail application. From address identifies the author of the email. That is, the mailbox of the person or system responsible for writing the message. The From address is sometimes called the 5322.From address.
S: Helo woodgrovebank.com S: Mail from: phish@phishing.contoso.com S: Rcpt to: astobes@tailspintoys.com S: data S: To: "Andrew Stobes" <astobes@tailspintoys.com> S: From: "Woodgrove Bank Security" <security@woodgrovebank.com> S: Subject: Woodgrove Bank - Action required S: S: Greetings User, S: S: We need to verify your banking details. S: Please click the following link to verify that Microsoft has the right information for your account. S: S: https://short.url/woodgrovebank/updateaccount/12-121.aspx S: S: Thank you, S: Woodgrove Bank S: .
In this transcript, the sender addresses are as follows:
- Mail from address (5321.MailFrom): phish@phishing.contoso.com
- From address (5322.From): security@woodgrovebank.com
If you configured SPF, then the receiving server does a check against the Mail from address phish@phishing.contoso.com. If the message came from a valid source for the domain phishing.contoso.com, then the SPF check passes. Since the email client only displays the From address, the user sees this message came from security@woodgrovebank.com. With SPF alone, the validity of woodgrovebank.com was never authenticated.
When you use DMARC, the receiving server also performs a check against the From address. In the example above, if there’s a DMARC TXT record in place for woodgrovebank.com, then the check against the From address fails.
I want to take a closer look about what exactly is the above mentioned Mail from address (5321.MailFrom) in the envelope and what is the From address (5322.From) in the header of the e-mail .
An E-Mail consists of the following three parts:
- Envelope: includes the sender (Mail From) and recipient (RCPT To) from the e-mail and will be just used by the Mail Transfer Agents (MTA) like Postfix for routing the e-mail between the MTAs. They don’t need the E-Mail header to route the e-mail to the destination.
- Header: used by the Mail Client for further information like Client ID and Message ID. Also the From and To address you will find in the header.
- Body: includes the main content, the message itself including attachments.
A great article about these parts you will find in the following post.
Email address types explained
https://www.mailhardener.com/kb/email-address-types-explained
On my postfix in the lab environment I configured a fix e-mail envelop 5321.MailFrom address below to show that the Mail From address could also be different than the From address. If not using to forge a sender address for e-mail spoofing as described further above in the Microsoft article, this normally makes sense in case of an undeliverable e-mail which should be returned to a central e-mail account instead of the origin sender.
my-fixed-envelope-sender@braintesting.eu
To do so you have add the file /etc/postfix/canonical
# Use the empty regexp to map any address to the desired envelope sender.
// my-fixed-envelope-sender@braintesting.eu
Also add the following lines at the end of your /etc/postfix/main.cf file
canonical_maps = regexp:/etc/postfix/canonical
canonical_classes = envelope_sender
Finally restart postfix
$ sudo systemctl restart postfix
Then I was sending an e-mail from the mailbox John.Doe@matrixpost-lab.de on the lab postfix to an user on my productive postfix server Fred.Nurk@matrixpost.de.
On the productive postfix server (destination server) there was logged the following for the receiving email from the lab environment and John.Doe@matrixpost-lab.de.
/var/log/mail.log on the destination postfix server
postfix/smtpd[19541]: Anonymous TLS connection established from mail.matrixpost-lab.de[94.16.122.199]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
policyd-spf[20231]: prepend Received-SPF: None (mailfrom) identity=mailfrom; client-ip=94.16.122.199; helo=mail.matrixpost-lab.de; envelope-from=my-fixed-envelope-sender@braintesting.eu; receiver=
postfix/smtpd[19541]: 4067C1800D8: client=mail.matrixpost-lab.de[94.16.122.199]
postfix/cleanup[20232]: 4067C1800D8: message-id=<00a801d8e3a6$fddd6190$f99824b0$@matrixpost-lab.de>
opendkim[5297]: 4067C1800D8: mail.matrixpost-lab.de [94.16.122.199] not internal
opendkim[5297]: 4067C1800D8: not authenticated
opendkim[5297]: 4067C1800D8: s=default d=matrixpost-lab.de SSL
postfix/qmgr[5265]: 4067C1800D8: from=my-fixed-envelope-sender@braintesting.eu, size=4021, nrcpt=1 (queue active)
postfix/smtpd[19541]: disconnect from mail.matrixpost-lab.de[94.16.122.199] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7
dovecot: lmtp(20234): Connect from local
dovecot: lmtp(Fred.Nurk@matrixpost.de): msgid=<00a801d8e3a6$fddd6190$f99824b0$@matrixpost-lab.de>: saved mail to INBOX
As you can see, in the logs from postfix there is not the sender Address 5322.From Johne.Doe@matrixpost-lab.de logged, but instead my fixed envelope sender address 5321.MailFrom my-fixed-envelope-sender@braintesting.eu, I configured on the lab postfix.
The mail is only accepted from my productive postfix, because I didn’t set an SPF or DMAR record for the braintesting.eu domain, otherwise it would be rejected if the SPF is not include the lab postfix.
Mail Clients won’t display the envelope address normally but you can also see it in the E-Mail header.
When using Exchange or Office 365 you will also see in the E-Mail header the envelop address in the Return-Path
Return-Path: my-fixed-envelope-sender@braintesting.eu
depending which SMTP servers are envolved, the name also could be X-Envelope-From
If you won’t check the E-Mail Header, you just see the 5322.From address from the E-Mail header.
DomainKeys Identified Mail (DKIM)
DKIM is one of the trio of Authentication methods (SPF, DKIM and DMARC) that help prevent attackers from sending messages that look like they come from your domain.
DKIM lets you add a digital signature to outbound email messages in the message header. When you configure DKIM, you authorize your domain to associate, or sign, its name to an email message using cryptographic authentication. Email systems that get email from your domain can use this digital signature to help verify whether incoming email is legitimate.
In basic, a private key encrypts the header in a domain’s outgoing email. The public key is published in the domain’s DNS records, and receiving servers can use that key to decode the signature. DKIM verification helps the receiving servers confirm the mail is really coming from your domain and not someone spoofing your domain.
DMARC (Domain-based Message Authentication, Reporting and Conformance)
DMARC works with Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) to authenticate mail senders.
Like the DNS records for SPF, the record for DMARC is a DNS text (TXT) record that helps prevent spoofing and phishing.
DMARC ensures the destination email systems trust messages sent from your domain. Using DMARC with SPF and DKIM gives organizations more protection against spoofing and phishing email. DMARC helps receiving mail systems decide what to do with messages from your domain that fail SPF or DKIM checks.
DMARC is like SPF and DKIM not just a DNS TXT record, it is also a Framework which on the destination server will provide DMARC verfification.
As mentioned further above under SPF, with DMARC the receiving server also performs a check against the From address instead as with SPF only the envelope Mail From address.
DMARC will process the results of SPF and DKIM against the published policy (DNS TXT records) from the sending domain in the E-Mail Header’s From address.
DMARC also will check if the sending domain in the From header matches both, the sending domain in the envelope Mail From and the signing domain (DKIM).
Set up the Sender Policy Framework (SPF)
The SPF configuration on the sender side is done real quickly, you just need to create a new DNS TXT record at your domain provider portal.
Below for example will tell receiving server, that for the sending domain all servers allowed to sent emails on behalf of, which are registered with MX-Records. So all mailserver they regisitered for receiving e-mails are also allowed to sent emails.
v=spf1 a mx -all
To create such records you can use several SPF online generators. They will guide you through a wizard and finally create the SPF record which you can enter at your DNS provider.
SPF Record Generator
https://dmarcly.com/tools/spf-record-generator
To set up SPF verfication on the receiving side, the steps depends from your E-Mail Server system. For Office 365 you had nothing to configure, SPF verfication out of the box will processed.
About the action Office 365 will take, if SPF verfication associated with DMARC will fail, you can read in my following post.
About settin up SPF verification for postfix, you can read my following post.
Set up DomainKeys Identified Mail (DKIM)
About how to set up DKIM in Office 365 you can read my following post.
About how to set up DKIM on Exchange on-premise you can read my following post.
Also about how to setup DKIM on postfix you can read my following post.
Set up DMARC
The DMARC configuration on the sender side is done real quickly like previously for SPF, you also just need to create a new DNS TXT record at your domain provider portal.
Below is my DMARC TXT record for my matrixpost.net E-Mail domain.
v=DMARC1; p=reject; rua=mailto:noreply-emailsecurity@matrixpost.net; ruf=mailto:noreply-emailsecurity@matrixpost.net;aspf=r
p=reject is the policy for my domain which defines the action receiving mailserver should take, if DMARC verification fails.
- reject = rejecting the mail if DMARC verification fails
- none = no action should be taken by the receiving E-Mail server in case DMARC verification fails
- quarantine = the email should be moved into the junk-folder from the recipient
aspf=r sets the alignment policy for SPF, which specifies how strictly message information must match.
- s Strict alignment. The message From header must exactly match the domain name in the SMTP MAIL FROM command
- r Relaxed alignment (default). Allows partial matches. Any valid subdomain of domain name is accepted.
DMARC alignment options
https://support.google.com/a/answer/10032169#alignment
Add your DMARC record
https://support.google.com/a/answer/2466563#dmarc-record-tags
To create a DMARC record you can also use DMARC online generators like previously for SPF. They will guide you through a wizard and finally create the DMARC record which you can enter at your DNS provider.
DMARC Record Generator
https://dmarcly.com/tools/dmarc-generator
DMARC on the receiving side also depends from your E-Mail Server system.
About how to reject Emails in Office 365 they fail DMARC you can read my following post.
About how to set up DMARC on Postfix you can read my following post.
Authenticated Received Chain (ARC)
DMARC allows a sender’s domain to indicate that their emails are protected by SPF and/or DKIM, and tells a receiving service what to do if neither of those authentication methods passes – such as to reject the message. However, a strict DMARC policy may block legitimate emails sent through a mailing list or forwarder, as the DKIM signature will be invalidated if the message is modified, such as by adding a subject tag or footer, and the SPF check will either fail (if the forwarder didn’t change the bounce address) or be aligned with the mailing list domain and not with the message author’s domain (unless the mailing list rewrites the From: header field.)
ARC was devised to solve this problem by giving intermediate servers a way to sign the original message’s validation results. Even if the SPF and DKIM validation fail, the receiving service can choose to validate the ARC chain. If it indicates that the original message passed the SPF and DKIM checks, and the only modifications were made by intermediaries trusted by the receiving service, the receiving service may choose to accept the email. Validating an ARC chain only makes sense if the receiver trusts the ARC signers. In fact, an ARC chain can be counterfeited, so ARC processing applies when receivers trust the good faith of ARC signers, but not so much their filtering practices.
Source: https://en.wikipedia.org/wiki/Authenticated_Received_Chain
Links
Email authentication in EOP
https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/email-validation-and-authentication?view=o365-worldwide
Use DKIM to validate outbound email sent from your custom domain
https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/use-dkim-to-validateoutbound-email?view=o365-worldwide
Domain-based Message Authentication, Reporting and Conformance (DMARC)
https://de.wikipedia.org/wiki/DMARC
DomainKeys Identified Mail (DKIM)
https://de.wikipedia.org/wiki/DomainKeys
Sender Policy Framework (SPF)
https://en.wikipedia.org/wiki/Sender_Policy_Framework
SPF
http://www.open-spf.org/
DMARC
https://dmarc.org/
How to interpret SPF authentication verification results
https://help.returnpath.com/hc/en-us/articles/115000460632-How-to-interpret-SPF-authentication-verification-results
Email address types explained
https://www.mailhardener.com/kb/email-address-types-explained
Authentication Received Chain (ARC)
https://en.wikipedia.org/wiki/Authenticated_Received_Chain
