When it comes to Email authentication and safety, SPF, DKIM, and DMARC stand as three key measures protecting you against spam, phishing, and other security risks. In short, each of these protocols contributes in its own unique way to the process of validating the authenticity of Email senders, making sure that the arriving message does indeed originate from the claimed domain. Whenever illegitimate actors are trying to sneak into your digital communication, the job of SPF, DKIM, and DMARC is to prevent that from happening. Let’s unpack their inner workings in more detail, shall we?
From the standpoint of a business owner or another individual responsible for running external Email communication, failure to properly implement these protocols can lead your sender domains down a dangerous path. Your Email deliverability may suffer, with messages being directed straight to spam, or worse, fall victim to impersonation by crafty spammers.
Email security primer
Email, an indispensable communication channel and a tool used in a variety of contexts, has had its security challenges since inception. Encryption, the main safety measure applied during transfers between servers may prove insufficient in combating all sorts of spammers and unwelcome senders if it’s all you rely on. It doesn’t erase the dangers of phishing scams and Email spoofing, fueled by sneaky techniques aimed at mimicking legitimate organizations. Thus, it became necessary to turn to advanced validation methods.
The original, 1982 Simple Mail Transfer Protocol (SMTP) didn’t put much foresight into Email security. Since then, the digital post going back and forth between servers has evolved to embrace encryption and authentication through the Transport Layer Security (TLS) protocol. Importantly though, there was a lack of any provisions for authenticating messages, leaving a crucial gap in the revamped defenses.
In response to the rising challenges posed by spam, phishing, and spoofed Email, three main Email authentication methods have been developed to fortify the digital barricades, protecting both ends of the communication line. These are:
- SPF, which verifies mail server authorization for Email delivery in DNS.
- DKIM, which digitally signs and authenticates messages, validating the authorized Email server.
- DMARC, which determines responses to Emails that fail authentication (DMARC uses SPF’s and DKIM’s assessment in the first place).
How does SPF work?
Sender Policy Framework (SPF) was introduced in 2014 to address the aforementioned SMTP’s vulnerability to unauthorized domain usage. This protocol establishes a clear process for you as the sender domain owner to specify the IP addresses and domains authorized to dispatch Emails on behalf of your business.
Implementation of SPF authentication yields tangible benefits, leading to spam reduction and enabling the identification and discard of phishing messages originating from spoofed domains. Briefly, the way it works is it allows mail servers to effectively authenticate incoming Email messages by cross-referencing the sender’s address with the domain’s SPF record. A match greenlights delivery.
At the core of SPF lies a concise one-line DNS TXT record. This small file contains the IP addresses of legitimate Email servers and the corresponding domain or subdomain. Mail servers that use SPF conduct DNS lookups for this SPF DNSrecord, ensuring the validation of Emails that claim affiliation with the domain.
Here are the 7 possible responses to a verification query listed in the SPF record:
- Pass: Indicates the sending mail server’s authorization to send Email for the domain.
- Fail: Means the sending mail server isn’t authorized to send an Email for the domain.
- None: Implies there’s no SPF record in place for the domain in question.
- Neutral: Occurs when the domain’s SPF record explicitly asserts no authorized IP addresses or domains. Further interpretation of this response may vary depending on the DMARC configuration for the domain.
- Soft fail: Suggests that the sending host likely lacks authorization. Treatment as a pass or fail depends on the DMARC configuration and the receiving mail server.
- Temporary error: Arises from a transitory error condition, like a DNS timeout, leading to a delayed message delivery.
- Permanent error: Indicates the SPF record couldn’t be processed correctly, resulting in message delivery failure. This can occur when there are multiple SPF records or syntax errors.
While DMARC and DKIM are not mandatory for SPF to do its job, they all complement each other. We cover the mutual relations between the three pillars of Email authentication later in the article.
How does DKIM work?
DomainKeys Identified Mail (DKIM) employs DNS to broadcast public keys essential in the process of authenticating Emails as originating from a specific domain. In essence, DKIM allows you to add a DKIM signature to their messages, confirming the ownership. This digital signature performed through public key cryptography, mathematically verifies the Email’s legitimacy, confirming its origin with the claimed domain.
The DKIM record process consists of the following steps:
1. DKIM public key storage
A DKIM record in DNS stores the domain’s public key. Email receiving servers can access this file to obtain the required public key.
2. Digital signature creation
The sender, holding the private key, signs the Email’s header. This private key remains confidential.
3. Verification by receiving servers
Upon receiving the Email, mail servers verify if the sender’s private key was indeed used by applying the public key retrieved from the DKIM record.
The DKIM protocol establishes a framework for Email senders to claim responsibility and authorship of messages through digital signatures. These become a fixed element of custom message headers, adhering to internet standards for Email syntax. SMTP servers supporting DKIM automatically authenticate messages with pa roper signature in the Email header.
DKIM authentication allows domain owners to allocate distinct signing keys for various Email service providers to send communication on their behalf. These keys could be internal, used by various branches, for example, or utilized by commercial service providers that you authorize to use your domain.
Regardless of the setup, the private keys remain secure with those controlling the Email servers, while the public keys are openly available in DNS for anyone receiving messages from the domain. This cryptographic relation ensures a reliable and transparent authentication process.
How does DMARC work?
DMARC, which stands for Domain-based Message Authentication Reporting and Conformance, uses DNS to broadcast policies dictating the course of action for Emails which failed SPF, DKIM, or both of these authentication processes. It’s almost like a third-party’s opinion on an issue.
This protocol decides and instructs the receiving Email servers on how to handle authentication results. A domain’s DMARC policy, set through a DMARC record, can tell mail servers to quarantine, reject, or still deliver Emails that haven’t completed SPF or DKIM authentication.
Implement DMARC to specify what to do when the receiving server is unable to authenticate a message. Its policies provide flexibility in determining the response to authentication failures. With this framework in place, you can receive feedback, both in individual reports for specific failed messages and aggregate reports summarizing SPF, DKIM, or combined primary authentication failures. This feedback loop helps in refining your Email security protocols and identifying potential domain attacks.
Actions specified in the DMARC record can include:
- None: No action is necessary, allowing legitimate messages to be delivered. Often used during initial DMARC implementation for logging purposes.
- Quarantine: Flags suspicious messages (authentication fails), directing them to designated folders like spam for review.
- Reject: Asserts that the message is definitely unauthorized and mustn’t be delivered, as it’s potentially malicious Email.
DMARC authentication, stored as DNS TXT, not only contains the acting instructions, but also specifies the expected reports and their destinations. This comprehensive approach enhances Email security, allowing you to secure yourself against unauthorized communication and swiftly identify potential threats.
How do SPF, DKIM and DMARC work together for Email delivery?
Your comprehensive Email authorization process starts with SPF verifying ownership of a domain. This step is crucial for DMARC and DKIM to function properly down the line. SPF draws on DNS records to authenticate Email servers. However, it doesn’t lay out the course of action for authenticated domains or detect message spoofing on its own.
Here’s where DKIM comes in, where digitally signed Emails undergo authentication checks via public keys stored in DKIM records. These files, included in the sender’s DNS, validate the legitimacy of the message’s origin.
Next up, DMARC builds on both SPF and DKIM authentication results, allowing domain owners to decide how receiving servers should handle unauthorized messages. DMARC introduces a DNS record storing the sending domain’s public key.
Together, these records allow business Email servers to:
- Authenticate the sender’s through an SPF check.
- Verify a message’s digital signature using DKIM.
- Determine what to do with unauthenticated messages via DMARC.
Where are DMARC, DKIM, and SPF records stored?
To enjoy the benefits of SPF, DMARC, and DKIM, you need Email server software supporting these protocols. The exact configuration is case-specific, but the heart of the matter lies in storing the protocol data in DNS TXT records.
The Domain Name System (DNS) serves as the repository for these files. As a public resource, DNS mainly matches web addresses with IPs, streamlining server location for online content retrieval. Beyond its core function, the service also hosts various records associated with a domain, including CNAME records, AAAA records for IPv6 addresses, and PTR records for reverse DNS lookups.
DKIM, SPF, and DMARC records find their home within the DNS framework. TXT files, versatile in their capacity to store just about any text, provide the space for these Email authentication protocols that allow you to safeguard communication integrity.
How to set up SPF, DKIM, and DMARC for a complete Email authentication protocol
SPF, DKIM, and DMARC, the three Email security protocols that complement each other, have to be set up in the domain’s DNS settings area. Senders can contact their DNS provider or their web hosting platform who may offer tools that enable the upload and editing of DNS records.
On top of everything else that’s been discussed here, it’s worth adding that in order to use SPF and DKIM and consistently pass the DMARC evaluation, you need to send Email from your domain, as widely available free services don’t provide the option to authenticate your communication.
Set up SPF
- Create an SPF record for your domain in DNS, listing IP addresses authorized to send Emails on behalf of your domain.
- Ensure your Email server aligns with the SPF record to enhance Email authentication.
Set up DKIM
- Generate public and private key pairs for DKIM, storing the public key in a DKIM DNS record.
- Configure your Email client server software to include a DKIM signature in the Emails you send using the private key.
Set up DMARC
- Create a DMARC record in DNS, specifying your preferred policy (None, Quarantine, or Reject) for handling unauthenticated messages.
- Determine where DMARC aggregate reports should be sent for analysis, improving visibility into Email authentication issues.
- Regularly monitor reports to fine-tune your policies and address any authentication challenges.
If you’d like more information on this topic or require assistance from Email communication experts in implementing these validation requirements, feel free to reach out to us anytime at We’ll help you check all the authentication boxes and send safely.
