Sender Addresses in E-Mails
Like paper mail letters, e-mail messages have at least two kinds of sender addresses: one on the envelope and one in the letterhead.
The envelope sender address (sometimes also called the return-path) is used during the transport of the message from mail server to mail server, e.g. to return the message to the sender in the case of a delivery failure. It is usually not displayed to the user by mail programs.
The header sender address of an e-mail message is contained in the "From" header and is what is displayed to the user by mail programs. Generally, mail servers do not care about the header sender address when delivering a message.
If you send email from a custom domain (for example, @yourdomain.com), you can list the IP addresses of the mail servers authorized to send your mail. By checking your list of IP addresses, email services and ISPs can identify whether the message came from a trusted server.
More precisely: SPFv1 allows the owner of a domain to specify their mail sending policy, e.g. which mail servers they use to send mail from their domain. The technology requires two sides to play together:
- the domain owner publishes this information in an SPF record in the domain's DNS zone, and when someone else's mail server receives a message claiming to come from that domain, then
- the receiving server can check whether the message complies with the domain's stated policy. If, e.g., the message comes from an unknown server, it can be considered a fake.
First, you must create an SPF record that lists the IP addresses of the mail servers authorized to send mail from your domain. Then you're ready to send messages with SPF as follows:
- You send an email, for example, from the address firstname.lastname@example.org. Suppose the message is sent from one of your authorized email servers with the IP address 188.8.131.52.
- When the email arrives, the receiving mail server checks the sender's address in the Return-Path (also known as MAIL FROM) field of the email header and looks up the SPF record for your domain (in this example, yourdomain.com).
- The receiving mail server checks whether the IP address from which the mail was sent (184.108.40.206) is listed in your SPF record.
- If the IP address is listed, the message passes SPF; if it isn't, it fails.
Note that in step 2. the receiving mail server looks up the SPF record for the domain in the Return-Path field, which doesn't need to be the same as the domain in the From field. Even if the domain in the From address is spoofed and differs from that in the Return-Path, a message can pass SPF.
Let's look at an example to give you an idea of how SPF works. Bob owns the domain example.net. He also sometimes sends mail through his Gmail account and contacted GMail's support to identify the correct SPF record for GMail. Since he often receives bounces about messages he didn't send, he decides to publish an SPF record in order to reduce the abuse of his domain in e-mail envelopes:
example.net. TXT "v=spf1 mx ip4:220.127.116.11 a:pluto.example.net include:_spf.google.com -all"
The parts of the SPF record mean the following:
|SPF DNS key||Description|
|v=spf1||SPF version 1SPF version 1|
|mx||the incoming mail servers (MXes) of the domain are authorized to also send mail for example.net|
|ip4||The IP address(es) of the servers authorized to send email from your domain. They can be IPv4 or IPv6 addresses; IPv6 addresses use the tag ip6.|
|a:pluto.example.net||the machine pluto.example.net is authorized, too|
|include:_spf.google.com||everything considered legitimate by gmail.com is legitimate for example.net, too|
|-all||all other machines are NOT authorized.|
SPF (Sender Policy Framework) verifies that an email has been sent from an IP address authorized to send emails from the sender's domain.
DKIM (DomainKeys Identified Mail) cryptographically verifies that the sender's address and message contents haven't been changed in transit.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) ensures that the domain in DKIM and SPF checks matches the sender's domain in the From field. It also specifies how email service providers should deliver a message that fails both DKIM and SPF — accept, reject, or mark it as spam.
When forwarding a message, if the sending mail server replaces the original sender's email address in the Return-Path (MAIL FROM) field with the forwarder's address, the receiving server will check the SPF record of the forwarder's domain. In this case, the message should pass SPF.
But not all email platforms rewrite the Return-Path field when forwarding. If the mail server preserves the original sender's address in the Return-Path field, the receiving mail server will check the original sender's SPF record. As this doesn't include the IP address of the forwarding server, the message fails.
Fortunately, if an email fails SPF, it may still pass the DKIM check because DKIM verifies a message's content, not its sending IP address. As long as you don't change the content and structure of the original message, it should pass DKIM.
SPF makes it harder for cybercriminals to send messages pretending to be from your domain (email spoofing). Specifying trusted mail servers with SPF helps to prevent fraudsters from using your domain for spam and phishing attacks.
SPF helps ISPs and email platforms identify legitimate emails. So using SPF increases the chances of your messages being delivered instead of ending up in the spam folder. The more your emails pass authentication checks like SPF, the more you improve your domain's reputation with email platforms. So SPF can help improve your emails deliverability in the long run.