SPF #
SPF (Sender Policy Framework) is another email authentication method designed to detect email spoofing. It allows the owner of a domain to specify which mail servers are authorized to send emails on behalf of that domain.
Here’s a simplified example of how SPF works:
- Mitchell sends an email to Elliot
- The email server that Elliot uses checks the SPF record for Mitchell’s domain to see if the server that sent the email is listed as an authorized server.
- If the server is listed in the SPF record, the email is considered to be legitimate and delivered to Elliot’s inbox.
- If the server is not listed in the SPF record, the email may be marked as suspicious or rejected.
Here’s an example of what an SPF record might look like:
dig TXT <example.com> v=spf1 mx a ip4:11.123.44.55 ~all
This SPF record specifies that the domain’s mail exchange (MX) servers and the server with the IP address 11.123.44.55 are authorised to send emails on behalf of the domain.
The “~all” at the end indicates that other servers may send emails from the domain, but it is marked as suspicious. If the “~all” symbol is replaced with “-all” other servers can’t send email from the domain.
DKIM #
DKIM (DomainKeys Identified Mail) is an email authentication method designed to detect email spoofing by providing a mechanism to allow receiving mail exchangers to check that incoming mail from a domain is valid by checking the digital signature that the domain owner adds to outgoing mail.
Here’s a simplified example of how DKIM works:
- Mitchell sends an email to Elliot
- The email server that Mitchell uses adds a DKIM signature to the email message. The signature includes a hashed version of the message and a special DKIM key that is associated with Mitchell’s domain.
- The email is delivered to Elliot’s email server.
- Elliot’s email server retrieves the DKIM key for Mitchell’s domain from the domain’s DNS (Domain Name System) records.
- The email server uses the DKIM key to verify the DKIM signature on the email message. If the signature is valid, it indicates that the email was likely sent by the domain it claims to be sent from and that it hasn’t been modified in transit.
DMARC #
DMARC, or Domain-based Message Authentication, Reporting, and Conformance is a security standard that helps protect email recipients from spam, phishing, and other types of email fraud. It does this by using two other email authentication standards, SPF (Sender Policy Framework) and DKIM (Domain Keys Identified Mail), to verify that an incoming message was actually sent by the domain it claims to be sent from.
Here’s how it works: When an email is sent, the sender’s email server adds a special DMARC record to the message’s header. This record contains information about the sender’s SPF and DKIM policies as well as instructions for the recipient’s email server on what to do if the message fails the authentication check.
Here’s an example of what a DMARC record might look like:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com ruf=mailto:dmarcforensic@example.com; fo=1; adkim=r; aspf=r;
Or you can use the below formats too:
v=DMARC1; p=quarantine; rua=mailto:postmaster@example.com;
v=DMARC1; adkim=s; aspf=s; p=none
These records specify the following:
- v=DMARC1: This indicates that the record is a DMARC record and specifies the version of DMARC being used.
- p=none: This specifies the sender’s policy for handling messages that fail the DMARC check. In this case, the policy is “none,” which means that the recipient’s email server should not take any special action on messages that fail the check. Other possible values for this field include “quarantine” and “reject,” which instruct the recipient’s email server to send failed messages to the spam folder or reject them outright, respectively.
- If “p=quarantine” In this case, the policy is set to quarantine, which means that any message that fails DMARC checks should be quarantined (i.e., placed in the recipient’s spam or junk folder.
- rua=mailto:dmarc-reports@example.com: This specifies the email address where DMARC aggregate reports should be sent. These reports contain information about messages that have passed or failed the DMARC check.
- ruf=mailto:dmarc-forensic@example.com: This specifies the email address where DMARC forensic reports should be sent. These reports contain detailed information about specific messages that have failed the DMARC check and are intended for use in forensic investigations.
The “rua” and “ruf” values can be set according to the requirement. When setting these values ensure that email accounts given here do exist in the domain.
- fo=1: This specifies that DMARC forensic reports should be generated for all messages that fail the DMARC check, regardless of whether they were sent to the domain specified in the “From” field or to a subdomain of that domain.
- adkim=r: This specifies that DMARC alignment should be strict when checking the DKIM signature. This means that the domain specified in the DKIM signature must exactly match the domain in the “From” field of the message.
- aspf=r: This specifies that DMARC alignment should be strict when checking the SPF record. This means that the IP address of the sender’s email server must be listed in the sender’s SPF record in order for the message to pass the DMARC check.
To put it simply, these are all ways to help protect your domain from being used to send spam or phishing emails. They allow you to specify which servers are authorised to send email from your domain and to check that incoming email from your domain is legitimate.