What is the correct order for SPF, DKIM, and DMARC checks?
Matthew Whittaker
Co-founder & CTO, Suped
Published 9 May 2025
Updated 17 Aug 2025
8 min read
Understanding the correct order for SPF, DKIM, and DMARC checks can be a bit like untangling a complex network. Many people assume a straightforward, sequential process, but in reality, it's more nuanced and dependent on how individual email recipient servers are configured. This often leads to confusion, especially when trying to diagnose email deliverability issues or explain authentication failures to a client's IT team. My goal here is to demystify this process and provide clarity on how these essential email authentication protocols work together when an email arrives at its destination.
It's not always a simple 1-2-3 sequence, and this flexibility is by design, allowing different systems to prioritize checks based on their specific needs and security postures. However, there's a logical flow that's generally followed, particularly concerning DMARC's reliance on the outcomes of SPF and DKIM. Let's dive into the specifics.
Before we discuss the order, it's helpful to briefly reiterate the role of each protocol. Each serves a distinct, yet complementary, purpose in verifying an email's legitimacy and preventing various forms of email abuse, such as phishing and spoofing. These protocols are the bedrock of modern email security, and their proper implementation is critical for maintaining a good sender reputation.
You can think of these as a set of digital safeguards that help prove an email truly came from the domain it claims to be from. Without them, it would be much easier for malicious actors to impersonate legitimate organizations, leading to widespread trust issues and a significant increase in spam and fraudulent messages. Implementing these correctly is the first step toward boosting your email domain reputation.
SPF (Sender Policy Framework): This protocol specifies which mail servers are authorized to send email on behalf of a domain. It does this by checking the IP address of the sending server against a published SPF record in the domain's DNS. SPF primarily validates the envelope MAIL FROM address, which is typically hidden from the end user.
DKIM (DomainKeys Identified Mail): DKIM adds a digital signature to email headers. This signature is encrypted with a private key by the sending server and can be decrypted by the receiving server using a public key published in the domain's DNS records. DKIM verifies that the email content hasn't been tampered with in transit and that it originates from the claimed domain. It checks the d= tag in the DKIM signature, which should align with the From: header domain.
DMARC (Domain-based Message Authentication, Reporting & Conformance): This protocol builds upon SPF and DKIM. Its primary function is to instruct receiving mail servers on how to handle emails that fail SPF or DKIM checks, particularly when those failures involve alignment issues. DMARC also provides domain owners with aggregated DMARC reports from Google and Yahoo, offering visibility into their email authentication status.
For an email to pass DMARC, it needs to pass at least one of the SPF or DKIM checks with alignment. This means the domain used for SPF (the Return-Path or Mail From domain) or the domain used for DKIM (d= tag) must match the domain in the From: header that the recipient sees.
The actual order of checks
This is where it gets a little more complex. There isn't a universally fixed, linear order for SPF, DKIM, and DMARC checks across all mail servers. Each recipient server (such as Microsoft 365 or Google Workspace) implements its own process, and some even perform checks in parallel or based on certain conditions. However, there's a general understanding of when certain checks can and must occur due to the nature of the protocols themselves.
The key distinction lies in when the necessary information for each check becomes available during the SMTP (Simple Mail Transfer Protocol) transaction. SPF can be verified very early in the process, sometimes even before the full email content is sent. This is because it primarily relies on the sending IP address and the MAIL FROM domain, which are part of the initial connection and envelope data.
In contrast, DKIM and DMARC require the full email message, including headers and body, to be transmitted before they can be fully evaluated. DKIM needs to access the signed headers and potentially the body to verify the digital signature. DMARC, in turn, depends on the outcomes of both SPF and DKIM authentication, including their alignment with the From: header. This means DMARC must logically be the last check performed.
General processing flow
Connection phase: Recipient server receives the email. SPF checks often begin here, analyzing the sending IP against the MAIL FROM domain's SPF record.
Data transmission phase: The full email message (headers and body) is sent. DKIM can only be checked once this data is available, as it involves cryptographic verification of the message content.
Authentication & policy phase: After SPF and DKIM checks are performed, DMARC evaluates their results, including alignment, to determine the final authentication outcome. It then applies the domain's DMARC policy (p=none, quarantine, or reject).
Common misconceptions and the nuance of DMARC
A common misconception, and one I've encountered with various IT vendors, is that DMARC is checked first or that both SPF and DKIM must always pass for an email to be delivered. This isn't true. DMARC's role is to act as an overarching policy layer that uses the results of SPF and DKIM to make a decision. If DMARC were checked first, it would have no authentication results to act upon.
Furthermore, a message only needs to pass either SPF or DKIM (with alignment) to pass DMARC. This flexibility is important, as it accounts for various email sending scenarios, like email forwarding or specific ESP configurations. For example, if DKIM fails but SPF passes, the email can still pass DMARC if the SPF alignment holds.
Some email systems might also employ advanced techniques where they don't necessarily perform checks in a strict, linear fashion but rather analyze the mailstream. This means they might use aggregated data or predictive analysis to make rapid decisions about an email's legitimacy, even if the underlying authentication steps are still being processed. However, at the core, the foundational checks of SPF and DKIM still need to occur for DMARC to function as intended.
Recommended implementation order
While the exact order of checks at the receiving server can vary, there's a widely accepted and logical order for implementing SPF, DKIM, and DMARC on your sending domain. This order ensures that you build your email authentication foundation correctly, minimizing potential issues and maximizing deliverability.
Implementation order
1. Implement SPF first: SPF is generally the easiest to set up and manage. Ensure your SPF record includes all authorized sending IP addresses and services. Remember to only have one SPF record per domain.
2. Implement DKIM second: Once SPF is stable, proceed with DKIM. This involves generating DKIM keys and publishing the public key in your DNS. Many ESPs will provide the DKIM records you need to add. Ensure you understand how to use DKIM selectors.
3. Implement DMARC last: Only after SPF and DKIM are properly configured and emails are consistently passing their respective checks should you deploy DMARC. Start with a p=none policy to monitor authentication results, then gradually move to quarantine or reject policies as you gain confidence.
This phased approach allows you to identify and fix any authentication issues (like DKIM body hash mismatch failures) without immediately impacting your email deliverability. Once DMARC is in place, continue to monitor your DMARC reports to catch any new issues that might arise. You can also use a free online email testing tool to verify your setup.
Views from the trenches
Best practices
Always consolidate your SPF records into a single record per domain to avoid errors and ensure all legitimate senders are covered.
Regularly monitor your DMARC reports to identify authentication failures and gain insights into your email ecosystem.
Ensure SPF and DKIM domains align with your "From" header domain for DMARC to pass, even if one check passes.
Common pitfalls
Assuming DMARC is checked first; it requires SPF/DKIM results to make a policy decision.
Believing both SPF and DKIM must pass for DMARC success; only one needs to pass with alignment.
Having multiple SPF records for a single domain, which breaks SPF and impacts deliverability.
Expert tips
DNS admin interfaces should be smarter about preventing conflicting SPF records and guiding users.
Automated tools for DNS configuration can help users correctly merge new SPF records with existing ones.
Beyond basic checks, monitor for excess SPF lookups and DKIM key validity for optimal performance.
Expert view
Expert from Email Geeks says that SPF can be checked during the connection or pre-data phase of email transmission.
2024-02-13 - Email Geeks
Expert view
Expert from Email Geeks states that DKIM and DMARC cannot be checked until after the full email data (headers and body) has been received.
2024-02-13 - Email Geeks
Key takeaways
While there isn't one strict universal order for SPF, DKIM, and DMARC checks by recipient mail servers, the logical flow is that SPF can be checked earliest (at connection time), followed by DKIM (once full message data is available), and finally DMARC (which relies on the outcomes of the first two). DMARC acts as the policy layer, dictating how an email should be handled based on its authentication results and alignment.
For domain owners, the most important takeaway is to implement these protocols in a sensible order: SPF first, then DKIM, and finally DMARC. This ensures that your email authentication is robust, providing the necessary signals to receiving servers and protecting your brand from spoofing and phishing attempts. Regular monitoring of your DMARC reports is key to ensuring ongoing compliance and optimal email deliverability.
