On it’s own SMTP protocol does not do much validation on the authenticity of sender. One can spoof protocol headers at SMTP and MIME levels to send a message in another users name. That can be problematic as it makes spam and social engineering attacks easier. To address this problem, some email authentication technologies have been developed. We will discuss the three major ones: SPF, DKIM and DMARC. SPF and DKIM authenticate sender metadata and DMARC extends them to configure email handling in case authentication fails. All of these rely on DNS records for the sender domain.
SPF: Sender Policy Framework
Sender Policy Framework, specified in RFC 7208
is a way for domain owners to authorize or disallow email sending from email addresses
associated with that domain via DNS TXT records. This sets a policy regarding what entities
(if any) can use the domain for their sender email identities. If a receiving or intermediate email
server is compliant with SPF, it would check the DNS records against source email address
in the SMTP
MAIL FROM messages and base the decision to allow or reject
the message based on the policy that domain owner has published. If a sending domain does
not publish any SPF records, the SPF-compliant email server is allowed to drop the email
message, which has implications for email deliverability. Setting up SPF records is one
of the recommended practices to prepare a domain for sending cold email.
Suppose we have a domain example.org and we want to disallow any and all email from that domain. We would publish the following DNS TXT record:
All SPF records start with version prefix
v=spf1 and contains zero or more
directives (mechanism-qualifier pairs). It can also contains some optional modifiers.
In this case
- is a qualifier that means “fail” (i.e. hard error on sending) and
is a mechanism that matches all sender IP addresses.
On the other, if we wanted everyone to be allowed to use the domain for email sending, we could publish this:
Now there’s a qualifier
+ that means “pass”, thus email sending is allowed from all
There are two more possible qualifiers.
~ means “softfail”, which corresponds to lesser
error condition on sending an email. This may cause email to be marked as possible spam
or bounced with a note to retry it later.
? neither allows not disallows email to be
There are the following mechanisms that SPF supports:
all- match any and all sender IP addresses
include- include SPF records from other domain (e.g.
a- match all IPs in domain name A records (e.g. just
afor the current domain or
a:example.netfor another domain)
mx- match all IPs in domain name MX records (can also point to another DNS name)
ptr- match IP addresses that reversely-resolves to given domain name or its subdomain (not recommended)
ip4- match a single IPv4 address or IPv4 range (e.g.
ip4, but for IPv6 addresses
exists- takes a domain spec and matches iff that matches at least one A record; meant for advanced use cases.
SPF implementations go through directives from left to right until it finds the one that conclusively (dis)allows email transfer, runs into error conditions or runs out of directives to check. In the case of conflicting directives, the one earlier in the records has precedence.
At the end of the SPF record there can be the following modifiers:
redirect- redirect SPF policy checks to another domain
exp- used for configuring error message when email is rejected.
Now that we’re familiar with concepts and some technical details of SPF, let us see how SPF is implemented by a real world email provider - hey.com. We use dig(1) to see what kind of SPF records hey.com domain has published:
$ dig -t TXT hey.com | grep spf1 hey.com. 60 IN TXT "v=spf1 include:_spf.hey.com ~all"
There’s two SPF directives here:
include:_spf.hey.com- include SPF policy of subdomain
~all- soft-reject all email that is not covered by any other directive.
include mechanism triggers recursive check. Now we must check the SPF records
of a referenced subdomain:
$ dig -t TXT _spf.hey.com | grep spf1 _spf.hey.com. 120 IN TXT "v=spf1 ip4:220.127.116.11/23 -all"
This specifies an IPv4 address range that is allowed to send email messages
from mailboxes under hey.com domain and strongly forbids all email traffic
to be sent from elsewhere, thus overriding the
~all directive in the previous
If you are growth hacker working on cold emails campaigns it is strongly recommended to set up SPF for all your outreach domains. Your email provider will most likely provide the exact instructions on how to do that.
But what if you want to do bug bounties? In that case, SPF records or lack thereof are not that relevant. Missing SPF records are not generally considered to be a serious security problem and reporting that is unlikely to lead to any payout.
DKIM: Domain Keys Identified Mail
DKIM, specified in RFC 6376 and some other additional RFCs goes beyond simple domain-level policies and enables email message signing by public key published in DNS record. This lets the intermediate email server to check if email message was sent from the keeper of respective private key (e.g. sender email provider) and that there was no tampering by adversarial parties (e.g. rogue email servers) as the message was enroute to the recipient. Depending on how exactly DKIM is deployed, the cryptographic signature may cover all message or only some headers.
DKIM also relies on DNS TXT records, but they are required to be published
at subdomain of following form:
selector is provider-specific value and
domain is a sender domain.
The DKIM signature is computed by sending email server that is managed by your email provider. As the email message goes through further DKIM-compliant servers it is being verified for the valid signature. DKIM implementation by itself does not reject any messages, but introduces extra email headers that can be used by spam filtering solutions.
DKIM has implications for email deliverability. As far as anti-spam systems are concerned, lack of DKIM record means less reliable sender identity. Furthermore, DKIM misconfiguration can cause signature validation to fail, which can lead to message being filtered as spam (especially if DMARC is being used).
RFC 6367 provides the following example of
DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane; c=simple; q=dns/txt; [email protected]; t=1117574938; x=1118006938; h=from:to:subject:date; z=From:[email protected]|To:[email protected]| Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700; bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=; b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR
The following is an example of DKIM record that ZOHO provides:
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXzlbk53i+yhhnbLM6Z/dzASCoGrRMbnMJzFsJK9Q17cHVDqmSUjQkNMfBhMD0JgwZcuUpHBE2aTVzwaLEQXRkR7BDOLBY+JpGjtJ45sjI9rmlN/4ntJLFEzuGaaHDp/XyR3eORKSt2QBHs9OM9U8zMoXCQc1+MW6vbtYJeWhacwIDAQAB
Like with SPF, your email provider will probably give you exact DNS record to use for enabling DKIM for your domain.
DMARC: Domain-based Message Authentication, Reporting and Conformance
DMARC is something that builds upon SPF and DKIM. It allows domain owners to publish DNS records telling how messages that violate SPF or DKIM authorization should be treated (rejected or quarantined). Furthermore, domain owners can provide an email address for the aggregate or forensic notifications to be sent to, so that they could be used for troubleshooting. Furthermore, you may want to know if someone if trying to spoof your email for malicious purposes.
RFC 7489 is the specification to read if you want to know more about DMARC.