Intro to Email Security with SPF DKIM and DMARC

Photo by Torsten Dettlaff:

Phishing and e-mail in general continue to be the most targeted attack vector according to Cloudflare’s 2023 Phishing Report. With e-mail service being the live blood of communication for most organizations, the security of such a service is paramount.

Hardening e-mail infrastructure and services is one piece to the puzzle, and most services provide integrated malware and spam prevention capabilities that add a layer of security to e-mail. However, another mechanism exists to provide additional security to e-mail services in the form of a number of DNS implementations, specifically, SPF, DKIM and DMARC.

SPF, DKIM, and DMARC are DNS implementations that provide security and reporting functionality to your e-mail delivery and receiving services. Let’s discuss each implementation further.


Sender Policy Framework (SPF), is a mechanism of identifying what servers are authorised and/or not authorised to send e-mail on behalf of a domain name. SPF also provides a mechanism to determine how strict to enforce the policy, allowing for some flexibility in implementation.

SPF Records

SPF exists in the form of a DNS TXT record. Here is an example:

v=SPF1 ip4: ip4: ~all

SPF Tags

Tag Default Description
v SPF1 indicates the version of SPF that the TXT record is using. This is for future expansion, but for now, v=spf1 is the only correct version. Every SPF TXT record must start with this string.
ip4 IPv4 address authorised to send e-mail on the behalf of a domain.
ip6 IPv6 address authorised to send e-mail on the behalf of a domain.
include CNAME or Domain Name of server authorised to send e-mail on the behalf of a domain.
a A record of server authorised to send e-mail on the behalf of a domain.
mx MX record of server authorised to send e-mail on the behalf of a domain.
ptr PTR record of a server authorised to send e-mail on the behalf of a domain.
exists Perform a check to see if a domain name has an assigned A record.
extensions The extensions mechanism provides a method of using custom mechanisms.
all all This mechanism always matches and must be used at the end of the SPF record. More details below.

The all Tag

The all tag always tests as positive and is used with a qualifier to determine how SPF evaluates the message. For example, the use of the - or fail qualifier, -all, would return a failed SPF check unless the sending server exists exactly in the SPF record, and quarantine the message. Using the ~ or softfail qualifier, ~all, would still return a failed SPF check, however, the message will not be quarantined.

SPF Qualifiers

The following qualifiers exist in the SPF standard:

+ – pass
- – fail
~ – softfail
? – neutral


DomainKeys Identified Mail (DKIM) Signatures is a domain-level authentication framework that uses public-key cryptography in order to verify the contents and source of a message. DKIM uses cryptographic signatures to protect integrity of messages, as well as a irrefutable evidence of the source of the message. As DKIM uses DNS records, there is no need for a Certificate Authority (CA) to check the certificate against. A receiving server can simply query the sender domain to validate the necessary keys.

DKIM Records

The DKIM Selector is a DNS TXT record that indicators where a recipient server can locate the domains public key. The public key will is used to create a hash of the received e-mail, and compared to the hash written by the senders server. If the hashes match, we know that the e-mail contents were not changed in transit, and because the public key worked to create the proper has, we also know that the e-mail could have only come from that server.

Here is the DKIM record for at selector1

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxAUDUvo/w6sBFGGC/hd8aNO0VNbZhGyvbOuHkG/dmlC+coDRH05zvWQgAbO1QSSatxb37d6AZ1sot+UeRbCpIVFBNvabPf/3QtYTj5gM3yl2k6FPK56uXTFNGZooA+WFYSKltYkaKnV1dNH7B0nlbV9Zh1NMcXLXsYb2idmi3RPkT12hxgeoaqdE1G6WfDstOd9B02kxxWr1gzuPGVmzLRCu8v170xEtvwoTghHcJSxmZT2zvauzTGuhkC9h65aPmebVPUiPipXw3ISmLd4YibzpbC/wGoVVS/McDZBSkUxFGcnM97eZF6ZLiS371TmCz4PqRc8iAmKJGLBRunpdnQIDAQAB;


Tag Default Description
v DKIM1 Indicates the version of DKIM to use. Always DKIM1.
h * Acceptable hash algorithms.
k rsa Indicates the key type. In this instance, we’re using RSA. Values include: rsa or ed25519
n Optional notes of interest to a human.
p Finally, we have the public key used to produce a hash of the message.
s * A list of service types which the record applies to. Values include: email
t A list of flags. Values include: y – DKIM testing mode, or s DKIM strict mode


Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a mechanism for providing domain-level policies and preferences for message validation, disposition and reporting. DKIM provides domain owners with a way of assigning a preferred method of handling authentication failures to reduce the amount of successfully delivered spoofed e-mail.

DKIM can also be configured to provide domain-level reporting on authentication and the disposition of received e-mail.

DMARC Records

DMARC records, like SPF and DMARC records, are DNS TXT entries that are defined using various mechanisms. Here is the DMARC record for at _dmarc.



Tag Default Description
v DMARC1 The version of DMARC being used. Always DMARC1.
p none What policy is applied to e-mails that fail DMARC? Values include: none, quarantine, or reject.
ruf none List of URIs to send forensics reports to.
rua none List of URIs to send XML feedback to.
sp p= How should DMARC treat messages from sub-domains? Values include: none, quarantine, reject.
adkim r Specifies alignment mode for DKIM signatures. Values include: r, or s. r indicates Relaxed Mode and s indicates Strict Mode. This determines how exact an e-mails "Header-From" domain must match a DKIM authenticated domain.
aspf r Specifies alignment mode for SPF. Values include: r, or s. r indicates Relaxed Mode and s indicates Strict Mode. This determines how exact an e-mails "Header-From" domain must match a SPF authenticated domain.
fo 0 Provides various forensics reporting options. Values include: 0, 1, d, or s. These options determine what triggers forensics reports.
rf afrf The reporting format for forensics reports. Values include: afrf or iodef.
pct 100 This option tells receivers to only apply the policy against failed DMARC checks, x percentage of time. For example, pct=50 would tell the receiver server to apply the policy against 50% of messages that fail the DMARC check.
ri 86400 The reporting interval for how often to receive XML reports in an aggregated form.

Leave a Reply

Your email address will not be published. Required fields are marked *