In this post I will go through some concepts and/or actions you should know about when you have to send emails from custom domains like
[email protected]. This is a common requirement when you want to send emails to your users for different kinds of notifications (welcome mails, payment mails, marketing mails, etc.).
I will not go through the concepts in detail but instead link to relevant guides which already does the job really well. So consider this article to be more of a reference to what you must keep in mind when sending emails to your users from custom domains. Interestingly most of the actions you have to take to do this, is around setting up DNS records.
Reverse DNS Zones
A record points
domain.com to an IPv4 address like
188.8.131.52 (both are just examples). Generally the DNS records you create in your domain provider’s console/admin ends up in a Forward DNS Zone.
A Reverse DNS Zone on the other hand contains
PTR records that let you lookup the domain against the IP (reverse of forward zones). With this you can point an IP like
184.108.40.206 to a domain like
domain.com. To do this, you setup a PTR record if your ISP/cloud provider allows that (preferably) in a reverse zone. You can’t just go and add a PTR record in your domain provider’s console/admin for your
domain.com (forward) zone.
domain.com we would need to create a PTR record for
domain.com as its value. Notice how the octets of the IP address are reversed. We can also setup an entire Reverse DNS zone (if our ISP/cloud provider allows) for say
220.127.116.11/24) and then add a bunch of
PTR records under that pointing one or more IPs to multiple domains.
Then if you hit
dig PTR 18.104.22.168.in-addr.arpa or
dig -x 22.214.171.124 or
host 126.96.36.199, you will get
domain.com as the answer.
Now why did we talk about reverse DNS lookups? Because some mail providers (like Gmail) might require the sender IP of an email to be resolvable to a domain and also the domain to point to the same IP. This can be achieved with
From one of Gmail’s support page:
Your sending IP address must have a PTR record. PTR records verify that the sending hostname is associated with the sending IP address. Every IP address must map to a hostname in the PTR record. The hostname specified in the PTR record must have a forward DNS that refers to the sending IP address.
dig +trace domain.com and
dig +trace <your-ip>.in-addr.arpa to understand the entire namespace tree for these domains.
Now if you are using third party mail services like Mailgun, Sendgrid, Postmark, Amazon SES, etc. then you do not need to worry about supporing reverse DNS lookups.
Sender Policy Framework (SPF)
SPF is an open standard that details out a method to prevent sender address forgery or spoofing. So for instance, if
[email protected] wanted to send you an email from
[email protected], he couldn’t do so if
yourbank.com implemented SPF. In fact email service providers like Gmail would completely reject incoming mails that do not pass either SPF or DKIM (discussed below) checks.
Before understanding SPF, it is important to understand that when sending an email the concept of sender email is different from the address used in
From header of the message. Conceptually, SMTP has an envelope that contains details like the sender email (SMTP
MAIL FROM command), recipient email (SMTP
RCPT TO command), etc. to be used by the recipient’s mail server and the actual message that contains the message header and body for usage by the recipient’s mail client. The message header is where the
From email is present that is shown in the recipient’s mail client. Read this SO thread for detailed explanation.
This is why I can send an email from
[email protected] (using a self-hosted mail server or a third party tool like Amazon SES or Mailgun) which is the SMPT
MAIL FROM email (or the sender email) but put
[email protected] in the message’s
From header and
[email protected] in the
To header that in Bar’s email client (say Gmail) would make it seem like it came from
[email protected] and not
[email protected]. Although thankfully good clients like Gmail would show extra information like
Mailed-By: codingshower.com or
From [email protected] via codingshower.com.
Similarly the address to which the email is actually delivered can be different from what is put inside
To header of the message.
Now the envelope sender email is actually added to the email header as a
Return-Path header by the recipient’s mail server, for example
yourbank.com might send you an email from
[email protected] which would lead to the following header getting added by the recipient mail server –
Return-Path: [email protected].
Now the problem is a malicious person called
foo could send you a spoofed email from
[email protected]. But if
yourbank.com added an SPF
TXT DNS record specifying a whitelist of IPs or domains who were allowed to send emails on their behalf, any legit email client or email service provider like Gmail would either reject the email or mark as spam. An SPF
TXT record looks something like this:
v=spf1 ip4=192.0.2.0 -all
This means that the recipient’s email server will first lookup the TXT record that starts with
v=spf1 for the domain in
Return-Path header and check if the sending mail server’s IP is whitelisted in that DNS record. If not the SPF check will fail and the mail will get rejected or moved to spam box.
It is important to note that SPF validation works against the domain in
Return-Path not the
From header in the SMTP message which is what the email client shows as the
from sender when you open an email (in Gmail for instance). This means that with SPF although
[email protected] cannot send you an email whose SMTP sender/Return-Path/envelope sender is
[email protected] but he can still send you an email where the SMTP sender is
[email protected] but the
From header contains
[email protected] tricking your email client and you into thinking that the email was sent from
Some clients like Gmail would show such emails as
from [email protected] sent via [email protected]. But the email could still end up in the user’s inbox if it passed SPF and DKIM checks. This spoofing can be prevented by DMARC (covered below).
For in-depth guides on SPF, follow these links:
- What is a DNS SPF record? – Cloudflare
- SPF Guide – Postmark
- Help prevent spoofing and spam with SPF – Gmail
- SPF Record Syntax
- SPF RFC
DomainKeys Identified Mail (DKIM)
DKIM is a method to validate the authenticity of email messages to ensure it has not been tampered with/altered while in transit. It uses the commonly known public/private cryptographic keys to sign the emails on the sender’s mail server and verify on the recipient’s side.
The following guides explains DKIM in detail:
Basically the sender signs the message body along with certain headers with its private key and adds the signature to the
DKIM-Signature header and then the recipient takes the same contents and the signature to verify them using the public key. The public key is available in the sending domain’s DNS
TXT record. The domain to be looked up for this record is available in the
d= tag present in
DKIM-Signature. To understand different tags, try the RFC or this article.
Here is an exampled DKIM-Signature:
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i45dv7c2xz3womuasteono;
The public key will be available in a
TXT record at
<s._domainkey.d>, which in the above example would be at
dig TXT 224i45dv7c2xz3womuasteono._domainkey.amazonses.com.
Now if DKIM check is passed on the recipient’s mail server, the authenticity of the email is ensured but
[email protected] can still send a valid email with
From: [email protected] header, i.e., spoofed mails. This is fixed using DMARC.
Domain-based Message Authentication, Reporting & Conformance (DMARC)
SPF takes care of spoofing of SMTP sender emails, i.e., an IP can send emails on behalf of another mail server/domain only if it is authorised by them via
TXT record. So SPF protects your domain from being used as the envelope sender/
Return-Path by random people.
DKIM signs mails protecting them from getting tampered in transit but that signed message could just be sent from a random/malicious email to an innocent user with a spoofed
From email header that shows up as the sender in most email clients/providers.
Both SPF and DKIM are powerless against spoofed
From header addresses. This is where DMARC “alignment” comes into picture. DMARC is a DNS record that
yourbank.com will have to set so that whenever an email provider/recipient mail server gets an email with
From header address whose domain is
yourbank.com, it will first require either SPF or DKIM to pass and after that “align” with the domain as well.
For SPF DMARC alignment means that the domain in
Return-Path must be the same as the one in
From header. If they are different then the email will be rejected or marked as spam. For DKIM DMARC alignment, the
d= tag in
DKIM-Signature must match with the
Matching of the domains (alignment) can be relaxed (subdomains pass) or strict (subdomains do not pass), i.e., in (default) relaxed mode
bar.example.com align but
anotherexample.com don’t. In strict mode the latter is true but
bar.example.com also do not pass the alignment test.
DMARC also has the concept of reports that the recipient’s mail server sends you from time to time regarding how emails with
From header of your domain is being delivered by them (rejected, marked as spam, etc.). The Gmail guide (linked below) has a detailed walkthrough of this.
Here is an example DMARC
TXT record (always added to
v=DMARC1; p=reject; adkim=s; aspf=s;
This record says reject an email if it fails strict alignment with both DKIM and SPF. Do note the way DMARC is designed, either SPF or DKIM has to pass and be aligned (not both) for the email to pass DMARC and be delivered (not rejected or spammed).
For in-depth understanding of DMARC:
- What is a DNS DMARC record? – Cloudflare
- DMARC: What is it and why do you need it? – Postmark
- Help prevent spoofing and spam with DMARC – Gmail
- DMARC Syntax
Following is a list of some other external links that might be useful FAQ, relevant concepts, guides, etc. around the same topic:
- Why there are two DKIM signatures in email – StackOverflow
- Prevent mail to Gmail users from being blocked or sent to spam
- What is ARC, or Authenticated Received Chain? – Postmark
A note on third party email services like Mailgun, Sendgrid, Postmark, Amazon SES, etc.:
- When using these services, you don’t have to worry about setting up reverse DNS records (
- When using these services, they will give you SPF and DKIM records that you should add in your domain as
TXTrecords. This not only helps prevent sender email spoofing and email tampering but also ensures your emails with custom domain (
[email protected]) do not get rejected or marked as spam by email service providers nor does it show up as
from [email protected] sent via mailgun.net.
- When using these services, it is still recommended to setup DMARC on your domain so that random people are unable to spoof the
Fromemail address with emails of your domain.