Sending an email is easy. Making sure it actually reaches the recipient's inbox is much harder.
For businesses, startups, and developers managing professional email, authentication standards such as SPF, DKIM, and DMARC are an important part of email security and deliverability.
These three protocols work together to help receiving mail servers determine whether an email is legitimate, whether it was authorised by the domain owner, and what should happen when authentication checks fail.
In this guide, we'll explain what SPF, DKIM, and DMARC are, how they work together, and why configuring all three correctly matters.
What Is Email Authentication?
Email authentication is a set of techniques used to verify the identity of a sender.
Without authentication, attackers can impersonate legitimate domains in phishing and spoofing attacks. For example, an attacker could send a message that appears to come from billing@yourcompany.com without actually controlling yourcompany.com.
SPF, DKIM, and DMARC give receiving mail systems information they can use to evaluate whether a message is legitimate.
What Is SPF?
SPF stands for Sender Policy Framework.
SPF allows a domain owner to publish a DNS record specifying which mail servers are authorised to send email on behalf of that domain.
An SPF record is published as a DNS TXT record. A simplified example looks like this:
v=spf1 include:example-mail-provider.com ~all
The exact record depends on which email services your organisation uses to send mail.
How SPF Works
Suppose your company sends mail from example.com.
When a receiving mail server receives a message claiming to come from your domain, it can check your domain's SPF record and determine whether the sending server is authorised.
If the sending server is included in the SPF policy, the SPF check can pass. If it isn't authorised, the SPF check can fail.
Why SPF Matters
SPF helps domain owners identify authorised sending infrastructure and can reduce unauthorised use of their domain.
However, SPF alone isn't enough. It focuses on the sending infrastructure and doesn't provide the complete authentication and policy framework that businesses need.
That's where DKIM and DMARC come in.
What Is DKIM?
DKIM stands for DomainKeys Identified Mail.
DKIM adds a digital signature to outgoing email.
The sending mail server uses a private cryptographic key to generate the signature, while the corresponding public key is published in the domain's DNS records.
When the recipient's mail server receives the message, it can retrieve the public key and verify the signature.
In simple terms:
Private key → signs the message
Public key → verifies the signature
This helps the receiving server determine whether the message was signed correctly and whether relevant parts of the message were altered after signing.
What Does a DKIM Record Look Like?
A DKIM public key is typically published under a selector.
For example:
selector1._domainkey.example.com
The DNS record contains the public key and other DKIM parameters. The exact record is generated by your email provider or mail server administrator.
What Is DMARC?
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance.
DMARC builds on SPF and DKIM.
It allows a domain owner to publish a policy that tells receiving mail systems how to handle messages that fail DMARC authentication requirements. It can also provide reporting information to help domain owners monitor email activity.
A basic DMARC record might look like this:
v=DMARC1; p=none; rua=mailto:dmarc@example.com
There are three commonly used DMARC policies.
1. p=none
The receiving server is asked not to apply a specific enforcement action.
This is commonly used during the monitoring stage while an organisation identifies legitimate sending sources.
2. p=quarantine
Messages that fail the DMARC policy may be treated as suspicious, such as being placed in a spam or junk folder.
3. p=reject
Messages that fail the DMARC policy can be rejected by receiving mail systems.
A strict policy should be introduced carefully because legitimate sending sources need to be identified and configured correctly first.
How SPF, DKIM, and DMARC Work Together
The easiest way to understand these three protocols is to think of them as complementary layers of email authentication.
SPF asks:
Is this sending server authorised for the domain?
DKIM asks:
Does the message contain a valid cryptographic signature?
DMARC asks:
Does the message satisfy the domain's authentication and alignment requirements, and what should happen if it doesn't?
Together, they provide a stronger authentication framework than relying on only one of these technologies.
SPF vs DKIM vs DMARC
| Technology | Main Purpose | Uses DNS? | Helps With Spoofing? |
|---|---|---|---|
| SPF | Authorises sending servers | Yes | Yes |
| DKIM | Verifies a cryptographic email signature | Yes | Yes |
| DMARC | Applies policy, alignment, and reporting | Yes | Yes |
These technologies are complementary rather than competing alternatives.
Why SPF Alone Isn't Enough
One common mistake is assuming that an SPF record completely protects a domain from spoofing.
It doesn't.
SPF checks whether the sending infrastructure is authorised. It doesn't provide the complete message-signing and policy capabilities provided by DKIM and DMARC.
There can also be situations where a legitimate message passes SPF but doesn't satisfy DMARC alignment requirements.
That's why SPF, DKIM, and DMARC should be treated as one complete email authentication strategy.
Why DKIM Matters for Email Deliverability
DKIM gives receiving systems a way to cryptographically verify a message's signature.
This becomes especially important when businesses use multiple email platforms, such as marketing tools, CRM systems, help desks, or transactional email services.
Each legitimate sending source should be reviewed and configured correctly.
A missing or incorrectly configured DKIM record can cause authentication problems.
Why DMARC Is Important for Businesses
DMARC gives domain owners more control over unauthorised email using their domain.
DMARC reporting can also help organisations discover email sources they may not have known were sending messages on their behalf.
For example, a company might discover that a third-party application is using its domain to send email. The organisation can then determine whether that source is legitimate and configure it correctly.
A Practical Email Authentication Checklist
If you're setting up email authentication for a business domain, work through these steps.
Step 1: Create Your SPF Record
Identify every legitimate service that sends email using your domain.
Then create an SPF record that authorises the appropriate sending services.
Step 2: Configure DKIM
Generate or obtain DKIM credentials from your email provider.
Publish the required public key in DNS and verify that outgoing messages are being signed correctly.
Step 3: Create a DMARC Record
Start with a monitoring policy while you identify legitimate sending sources.
For example:
v=DMARC1; p=none
Step 4: Review Authentication Reports
Look for both legitimate and unauthorised sources sending email for your domain.
Step 5: Fix Legitimate Authentication Failures
Before moving to a stricter DMARC policy, make sure your legitimate email services are correctly configured.
Step 6: Consider Stronger Enforcement
Once you understand your legitimate sending sources and authentication is working reliably, you can consider moving toward quarantine or reject, depending on your requirements.
Common SPF, DKIM, and DMARC Mistakes
1. Creating Multiple SPF Records
A domain should not have multiple independent SPF records.
SPF mechanisms should be consolidated into one valid SPF policy.
2. Forgetting Third-Party Email Services
Marketing platforms, CRM systems, support tools, and transactional email providers can all send messages on behalf of your domain.
If legitimate services aren't configured correctly, their messages can fail authentication.
3. Publishing the Wrong DKIM Key
A typo in the selector, hostname, or public key can cause DKIM verification to fail.
4. Enforcing DMARC Too Quickly
Moving directly to p=reject without identifying legitimate sending sources can potentially cause legitimate messages to be rejected.
Monitoring first is usually the safer approach.
5. Assuming Authentication Guarantees Inbox Placement
SPF, DKIM, and DMARC are important, but authentication alone doesn't guarantee inbox placement.
Sender reputation, message content, recipient engagement, sending behaviour, infrastructure, and other factors can also affect email deliverability.
How Developers Can Check Email Authentication
Developers and administrators can inspect DNS records using standard command-line tools.
For SPF:
nslookup -type=TXT example.com
or:
dig TXT example.com
For DKIM, you'll need the selector:
dig TXT selector1._domainkey.example.com
For DMARC:
dig TXT _dmarc.example.com
These commands can help verify whether the expected DNS records are publicly available.
SPF, DKIM, and DMARC Are a Team
It's tempting to think of SPF, DKIM, and DMARC as three separate technologies.
A better way to understand them is as complementary layers.
SPF identifies authorised sending infrastructure.
DKIM provides cryptographic verification.
DMARC adds domain alignment, policy enforcement, and reporting.
When configured correctly, together they provide a stronger foundation for protecting a business domain from spoofing and improving email authentication.
For a deeper technical walkthrough, see Mailafiniti's SPF, DKIM & DMARC Setup Guide.
Final Thoughts
Authentication is one of the most important technical foundations of email deliverability, although it isn't the only factor.
If you're responsible for a business domain, start by identifying every legitimate service that sends mail on your behalf. Configure SPF and DKIM correctly, then use DMARC to monitor authentication before gradually strengthening your policy.
You can also check your domain's current email authentication configuration with Mailafiniti's free Email Health Check, which checks SPF, DKIM, DMARC, and MX records.
The key takeaway is simple:
SPF tells receiving servers who can send. DKIM helps verify the message. DMARC brings authentication and policy together.
Top comments (0)