Table of Contents
- Introduction
- What SPF Does in Email Authentication
- What DKIM Does in Email Authentication
- What DMARC Does and How It Connects Everything
- Key Differences Between SPF, DKIM, and DMARC
- Why These Protocols Matter for Email Deliverability
- How to Set Up SPF, DKIM, and DMARC Together
- Common Mistakes When Configuring All Three
- Conclusion
- Other Things You Need to Know About SPF, DKIM, and DMARC
Last Updated
Do not index
IntroductionWhat SPF Does in Email AuthenticationWhat DKIM Does in Email AuthenticationWhat DMARC Does and How It Connects EverythingKey Differences Between SPF, DKIM, and DMARCWhy These Protocols Matter for Email DeliverabilityHow to Set Up SPF, DKIM, and DMARC TogetherCommon Mistakes When Configuring All ThreeConclusionOther Things You Need to Know About SPF, DKIM, and DMARC
Introduction
Every email you send passes through a series of invisible checkpoints before reaching the recipient. These checkpoints do not evaluate your subject line or content. Instead, they verify whether your email is legitimate, confirm that the message has not been altered during delivery, and check whether your domain has defined how receiving servers should handle email authentication failures.
Three protocols sit at the center of this process: SPF, DKIM, and DMARC. While they are often mentioned together, each one plays a distinct role in verifying identity, protecting message integrity, and guiding how failures are handled. Understanding the difference between SPF, DKIM, and DMARC is essential for improving email deliverability, strengthening sender reputation, and ensuring consistent inbox placement.
In 2026, these protocols are no longer recommendations. Gmail, Microsoft, and Yahoo now enforce them as hard requirements for bulk senders, and emails that fail authentication are increasingly rejected at the server level rather than being routed to the spam folder. Knowing how each protocol works and how they connect to each other is now a baseline requirement for anyone who depends on email to reach their audience.
What SPF Does in Email Authentication
SPF, or Sender Policy Framework, is responsible for verifying the source of an email. It allows domain owners to define which mail servers are permitted to send emails on their behalf by publishing this information in their DNS records.
When an email is received, the receiving server checks the SPF record of the sender's domain and compares it with the sending server's IP address. If the server is authorized, the email passes SPF. If it is not, the message may be flagged or filtered. In simple terms, SPF acts as a permission list that tells receiving servers which sources are allowed to send emails for your domain. This process happens automatically and forms part of a broader system designed to reduce spoofing and improve trust across email networks.
SPF is often the first authentication check a receiving server performs, which makes it a critical first gate. If SPF fails, the email starts the evaluation process at a disadvantage, and depending on the receiving server's policies, it may never get the chance to be evaluated further.
One important limitation to understand is that SPF has a maximum of 10 DNS lookups. Every include statement or redirect mechanism in the record counts toward this limit. Businesses that use multiple email platforms for marketing, transactional, and outreach purposes can easily exceed this limit without realizing it, which causes SPF to fail automatically for every email sent from that domain.
What DKIM Does in Email Authentication
DKIM, or DomainKeys Identified Mail, focuses on message integrity rather than the sending source. It works by attaching a cryptographic signature to each outgoing email, which can be verified by the receiving server.
This signature is made using a private key held by the sending domain, while the corresponding public key is published in the domain's DNS records. When the email arrives, the receiving server uses the public key to confirm that the message has not been altered during transmission.
Because DKIM verifies the content of the email, it ensures that what was sent is exactly what was received. This adds an additional layer of trust that goes beyond source verification. Where SPF answers the question "is this server allowed to send email for this domain," DKIM answers a different question entirely: "has this email been tampered with since it was sent." These are two separate trust signals, and inbox providers evaluate both of them independently before making a placement decision.
DKIM failures are less common than SPF failures in terms of basic configuration, but they do occur when email forwarding services or mailing lists modify the message body or headers after the original signature was applied. In those cases, the DKIM signature no longer matches the content, and the check fails even though the email is legitimate. This is one of the reasons why relying on a single authentication protocol is insufficient.
What DMARC Does and How It Connects Everything
DMARC, or Domain-based Message Authentication, Reporting, and Conformance, builds on both SPF and DKIM. It defines how receiving servers should handle emails that fail authentication and ensures alignment between the domain used in authentication and the domain visible to the recipient.
DMARC allows domain owners to set policies such as monitoring, quarantining, or rejecting emails that fail SPF or DKIM checks. It also provides reporting mechanisms that give insight into how emails are being processed across different receiving servers.
By connecting SPF and DKIM into a unified policy, DMARC strengthens overall email authentication and gives domain owners more control over how their emails are treated. The alignment requirement is what makes DMARC particularly important. An email can pass SPF on a technical level, but if the domain used in the SPF check does not align with the domain shown in the "From" header that the recipient sees, DMARC will still fail. This prevents attackers from passing SPF using their own infrastructure while making the email appear to come from someone else's domain.
DMARC policies operate on three levels. A policy of "none" means the domain is only monitoring authentication results without taking action on failures. A policy of "quarantine" tells receiving servers to route failing emails to the spam folder. A policy of "reject" instructs servers to block failing emails entirely. In 2026, deliverability professionals and inbox providers increasingly expect senders to move beyond "none" and implement enforcement level policies of quarantine or reject to provide stronger trust signals.
The reporting function of DMARC is also valuable beyond enforcement. DMARC aggregate reports provide detailed data on every server that sends email using your domain, including unauthorized sources. This visibility allows domain owners to detect spoofing attempts, identify misconfigured services, and ensure that all legitimate sending platforms are properly authenticated.
Key Differences Between SPF, DKIM, and DMARC
Although SPF, DKIM, and DMARC are closely related, their functions are distinct and complementary.
SPF verifies whether the sending server is authorized. It answers the question of where the email came from. DKIM ensures that the email content has not been altered during transmission. It answers the question of whether the message is intact. DMARC defines how authentication results should be interpreted and enforced, while also ensuring domain alignment. It answers the question of what should happen when something fails.
Together, they form a layered system where each protocol addresses a different aspect of trust. Relying on only one of them creates gaps in authentication, while using all three provides a more complete and reliable framework.
A practical way to think about it is this: SPF checks the envelope, DKIM checks the contents inside, and DMARC checks the identity on the return address and decides what to do if something does not match. All three need to be in place for the system to function as intended.
Why These Protocols Matter for Email Deliverability
Inbox providers rely heavily on authentication signals when deciding whether to deliver an email to the inbox, spam folder, or reject it entirely. SPF, DKIM, and DMARC collectively influence how your domain is perceived over time.
A properly configured authentication setup helps establish consistency and credibility. It signals that your domain is legitimate, controlled, and actively managed. This contributes to a stronger sender reputation, which directly impacts inbox placement.
On the other hand, weak or misconfigured authentication can lead to delivery issues, even if your content is well written. Emails may be filtered, delayed, or blocked entirely, making it difficult to achieve reliable performance.
The enforcement landscape has changed significantly. In November 2025, Gmail began rejecting emails outright at the server level when authentication fails, rather than routing them to spam. Microsoft followed with its own enforcement timeline beginning in early 2026. Yahoo implemented comparable requirements. This means that authentication failures no longer result in reduced visibility. They result in complete non-delivery, where the recipient never sees the email in any folder.
For businesses sending at scale across marketing, transactional, and outreach email, the impact of misconfigured authentication compounds quickly. A single broken DKIM record or a missing SPF include can affect thousands of emails per day, and the sender may not realize it until deliverability metrics have already deteriorated significantly.
How to Set Up SPF, DKIM, and DMARC Together
Implementing all three protocols requires coordination between your DNS settings, your email sending platforms, and your domain configuration.
For SPF, you need to identify every service that sends email on behalf of your domain and add them as authorized sources in a single TXT record in your DNS. This includes your primary email provider, marketing platforms, CRM systems, transactional email services, and any internal tools that generate automated messages. The record must stay within the 10 DNS lookup limit to avoid automatic failure.
For DKIM, each sending platform needs to generate a unique key pair. The private key is used by the platform to sign outgoing emails, and the corresponding public key is published in your DNS as a TXT record. Most email platforms provide DKIM setup instructions that include the specific DNS records you need to add. Each platform you send from should have its own DKIM signature configured.
For DMARC, you publish a TXT record in your DNS that specifies your policy (none, quarantine, or reject) and provides an email address where aggregate reports should be sent. Starting with a policy of "none" allows you to monitor authentication results across all sending sources before moving to enforcement. Once you have confirmed that all legitimate sources are properly authenticated, you can move to quarantine or reject to actively protect your domain.
The order of implementation matters. SPF and DKIM should be fully configured and verified before publishing a DMARC policy at the enforcement level. If you enforce DMARC before all sending sources are authenticated, legitimate emails from misconfigured platforms will be quarantined or rejected.
Common Mistakes When Configuring All Three
One of the most frequent mistakes is setting up SPF and DKIM but leaving DMARC at "none" indefinitely. A policy of "none" provides monitoring data but offers no actual protection and sends no enforcement signal to inbox providers. It is meant to be a temporary step during setup, not a permanent configuration.
Another common issue is configuring authentication on the primary domain but forgetting about subdomains. If you send email from subdomains such as mail.yourdomain.com or marketing.yourdomain.com, each subdomain needs its own SPF and DKIM configuration. Authentication records on the root domain do not automatically apply to subdomains.
Failing to update authentication records when changing email platforms is another frequent cause of problems. When a team migrates from one marketing tool to another or adds a new CRM that sends email through the domain, the SPF and DKIM records must be updated to reflect the change. If the old platform is removed from the record but the new one is not added, every email sent from the new platform fails authentication silently.
Inconsistent DKIM signing across platforms is also problematic. If some platforms sign emails with DKIM and others do not, the unsigned emails will fail DKIM checks and weaken the overall authentication profile of the domain. Every platform that sends email on your behalf should have DKIM enabled and properly configured.
Conclusion
SPF, DKIM, and DMARC are not optional components of email infrastructure. They are foundational elements that work together to establish trust, protect your domain, and improve deliverability.
While each protocol serves a different purpose, their combined effect is what enables consistent inbox placement. By understanding how they differ and how they connect, you can build a stronger authentication system and create a more reliable email strategy.
In the current enforcement environment, where inbox providers reject noncompliant emails rather than filtering them, having all three protocols properly configured is no longer a best practice. It is a requirement for reaching the inbox at all.
Other Things You Need to Know About SPF, DKIM, and DMARC
Can an email pass SPF but fail DMARC?
Yes. DMARC requires alignment between the domain used in authentication and the domain visible in the "From" header. An email can technically pass SPF because it was sent from an authorized server, but if the authenticated domain does not match the domain the recipient sees, DMARC will still fail. This is a deliberate design choice that prevents attackers from using their own authenticated infrastructure to impersonate another domain.
What does a DMARC aggregate report actually show me?
DMARC aggregate reports are XML files sent to the email address specified in your DMARC record. They contain data from every receiving server that processed email from your domain, including which servers sent email on your behalf, whether those emails passed or failed SPF and DKIM, the volume of messages from each source, and how each receiving server handled the failures based on your policy. These reports are essential for identifying unauthorized senders, detecting spoofing attempts, and verifying that all legitimate platforms are properly configured.
Is it safe to set DMARC to "reject" immediately?
No. Moving directly to a reject policy without first monitoring your authentication results can cause legitimate emails to be blocked. The recommended approach is to start with a policy of "none" to collect data, review the aggregate reports to ensure all authorized sending sources pass authentication, then move to "quarantine" before eventually advancing to "reject." Each step should be validated with report data before proceeding.
Do I need to configure DKIM separately for every email platform I use?
Yes. Each platform that sends email on behalf of your domain should have its own DKIM key pair configured. The platform generates the private key and uses it to sign outgoing messages, while you publish the corresponding public key in your DNS. If a platform sends email without a DKIM signature, those messages will fail DKIM checks and weaken your overall authentication profile.
What happens if I change email providers but do not update my authentication records?
If you switch to a new email platform without updating your SPF record to include the new provider and adding the new DKIM keys to your DNS, every email sent from the new platform will fail both SPF and DKIM authentication. Depending on your DMARC policy, those emails will either be monitored and delivered with warnings, routed to spam, or rejected entirely. This is one of the most common causes of sudden deliverability drops after a platform migration.
Can email forwarding break DKIM?
Yes. When an email is forwarded through a mailing list or forwarding service, the intermediary server may modify the message body, headers, or both. Because DKIM verifies that the content has not changed since it was signed, any modification will invalidate the DKIM signature. The forwarded email will then fail DKIM even though the original message was legitimate. This is a known limitation of DKIM and one of the reasons DMARC evaluates both SPF and DKIM rather than relying on a single protocol.
Does SPF protect against email spoofing on its own?
SPF alone does not fully prevent spoofing. It verifies that the sending server is authorized, but it does not check whether the visible "From" address in the email matches the actual sending domain. A spoofed email can pass SPF if the attacker uses their own domain with a valid SPF record while making the visible sender name look like someone else. Full spoofing protection requires SPF working together with DKIM and DMARC, where DMARC enforces alignment between the authenticated domain and the visible sender address.