Verify SPF and DKIM Order

Why the order of SPF and DKIM checks matters for deliverability

You send a perfectly legitimate email. It passes DKIM validation. But it still lands in spam. Why?

Because email servers don’t check authentication in any order they like. They follow a strict sequence: SPF first, DKIM second. If that order is disrupted—whether by misconfiguration or flawed validation logic—a real message can be flagged as spoofing.

How you verify SPF and DKIM checks are performed in proper order isn’t just technical jargon. It’s the difference between inbox placement and deletion.

Key takeaways

SPF is evaluated before DKIM in standard email validation pipelines; reversing this order risks false spoofing flags.
Misordered or mismatched authentication checks are a common cause of reduced deliverability and increased spam filtering.
Proper verification requires confirming both SPF and DKIM are checked in the correct sequence, not just individually.

How SPF and DKIM work together in the email delivery chain

SPF checks if the sending IP is authorized by the domain’s DNS records; DKIM verifies that the message content hasn’t been altered since signing. Most mail systems process SPF first, then DKIM, because SPF validates the sender’s identity before validating the message integrity. If SPF fails, DKIM results are often ignored — authentication cascades fail early.

SPF: The Sender’s Identity Check

When an email arrives, the receiving server first looks up the sending domain’s SPF record in DNS. This record lists the IP addresses or ranges permitted to send emails on behalf of that domain. If the sending IP isn’t on the list, SPF fails — and the email may be rejected or marked as suspicious. SPF is strictly about source authorization, not message content.

DKIM: The Message Integrity Seal

DKIM uses a digital signature attached to the email headers and body. The receiving server retrieves the public key from the sender’s DNS record and re-computes the hash of the message. If the two match, the content hasn’t changed in transit — a critical safeguard against tampering. DKIM doesn’t care who sent the mail, only that it’s unchanged since signing.

Why order matters: SPF must precede DKIM in most systems because an email failing SPF is likely forged. If SPF passes, the server proceeds to DKIM, which confirms the message is intact. If both pass, the message is more likely to reach the inbox. But if SPF fails, the server may discard the email before even checking DKIM — a common reason why even well-signed emails fail delivery.

Let’s be clear: both are needed for strong authentication. SPF validates the “who,” DKIM validates the “what.” But SPF must be processed first — not because DKIM is less important, but because the system checks sender legitimacy before integrity. This order is defined in the email delivery stack and enforced by most major providers, including Google, Microsoft, and Apple.

For teams building or managing email workflows, verifying both SPF and DKIM alignment is non-negotiable. Tools like MailTester’s inbox placement checker help spot failures in real time by simulating how your emails are evaluated across major inboxes.

Understanding the sequence isn’t just theory — it’s operational. Misconfigured SPF or DKIM settings delay delivery, increase bounce rates, and hurt sender reputation. The process is standardized in RFC 7208 (SPF) and RFC 6376 (DKIM), both maintained by the IETF — the governing body for internet protocols.

What happens when SPF and DKIM checks are performed out of order

When SPF and DKIM checks are processed in the wrong sequence, legitimate emails can be rejected even if they pass authentication. Some servers validate DKIM first and skip SPF if DKIM passes, which can mask alignment issues. Others fail messages immediately on SPF failure, ignoring valid DKIM signatures. This misordering can lead to false positives, where real senders are wrongly flagged as spammers due to policy misalignment.

Order matters because of SMTP validation flow

Most mail servers perform SPF checks early in the SMTP dialogue, before accepting the message body. If SPF fails — meaning the sending IP isn’t authorized by the domain’s SPF record — the server may reject the email outright, regardless of DKIM status. DKIM validation, which requires parsing the full message, often happens after the envelope is accepted, so it may never be reached if SPF fails.

But in some setups, especially with advanced filtering or third-party gateways, DKIM is validated before SPF. This can create a false sense of security. For example, if a domain uses a legitimate DKIM signature but sends from an unauthorized IP, a DKIM-first system might accept the message while ignoring the SPF failure. This misalignment can result in messages being delivered but later flagged as spam or rejected by reputation systems.

Why misordering hurts sender reputation

Senders relying on DKIM alone may assume their messages are trustworthy. But if SPF isn’t properly validated, they risk sending from unapproved IPs — a red flag to anti-spam systems. Even one misconfigured sender can trigger automatic blocks or blacklisting at the receiving end.

Industry standards, like those from the IETF (RFC 5321), define the SMTP handshake and encourage SPF checks early, but enforcement varies. Some receivers skip SPF if DKIM passes, which can undermine the entire authentication framework. This inconsistency means even well-intentioned senders can suffer delivery issues.

Let’s say you use a mailing platform where your IP isn’t in the SPF record. If your server processes DKIM first and the signature is valid, the message gets accepted. But later, the receiver's anti-abuse system flags it for SPF misalignment — even though DKIM passed. That’s a false negative on deliverability, triggered by the wrong check order.

Proper check sequencing protects both senders and receivers. The best approach is to align SPF, DKIM, and DMARC policies, and to validate both mechanisms in the correct order. You can test your setup using tools like inbox placement tests or verify your domain's alignment with bulk verification. Consistent, correct validation reduces bounce rates and protects sender reputation.

How to verify that SPF and DKIM checks are performed in proper order

You can verify SPF and DKIM are checked in the correct order by sending a real email through a service that captures full headers and traces the authentication process end-to-end. The order matters: SPF is checked first, then DKIM—so the header trace must show both results in sequence, with DKIM validation only occurring after SPF fails. Use a test that includes both checks and logs their execution order via the full email header.

Run a real delivery test with full header capture

Send a test email from your sending domain using a service that preserves the full header trace, like MailTester’s inbox placement tester.
Ensure the test simulates real-world delivery—include your actual sending IP, domain, and message content.
Download the full email headers after delivery; don’t rely on simplified summaries from tools that mask low-level details.

Check authentication order in the full header trace

Look for the Authentication-Results header line, which documents SPF and DKIM outcomes, including the order they were evaluated.
Verify SPF is listed first: spf=pass or spf=fail should appear before dkim=pass or dkim=fail in the header chain.
Use RFC 5322 and RFC 6376 as reference: the receiving server must evaluate SPF before DKIM, as DKIM relies on the envelope sender (from the SMTP transaction), which SPF validates via the envelope sender address.
Confirm both checks are present. If one is missing, your test didn't cover the full stack—this is common with lightweight API tools.

Let’s be clear: you can’t trust a tool that skips the full header trace or only shows pass/fail indicators. The real test is in the header sequence. For example, if DKIM passes but SPF fails, and DKIM is listed first in the header, something is wrong with the receiving server's logic or your testing process. This is why testing with MailTester’s real-time API or bulk verification gives you reliable, traceable data.

“SPF must be evaluated before DKIM, as DKIM’s signing domain depends on the envelope sender validated by SPF.” — RFC 6376, Section 3.3

Remember: ordering isn’t optional. It’s core to how authentication works. If you’re not verifying the actual header sequence, you’re not verifying the process at all.

The exact sequence of checks in a modern email server

When an email arrives, modern servers perform a strict, ordered sequence: first, they check the sender’s SPF record in DNS, then validate the sending IP against it. Next, they verify the DKIM signature using the public key from DNS. After that, they confirm the signature matches the message content. Then they compare the From domain to the authenticated domains. Finally, they score the message based on these results. This order ensures only properly authenticated emails proceed.

Step-by-step: the authentication workflow

Look up the SPF record in DNS for the sending domain. This is the first step because SPF defines which IPs are authorized to send on behalf of that domain. Without this, no further checks can proceed.
Validate the sending IP against the SPF record. If the IP is not listed in the SPF record, the message fails authentication. This check happens before DKIM to enforce sender identity early in the pipeline.
Fetch the DKIM public key from DNS. The receiving server retrieves the public key using the selector and domain specified in the DKIM-Signature header. This key is needed to verify the signature’s authenticity.
Verify the DKIM signature using the public key. The server uses the public key to decrypt the signature and validate it against the signed parts of the message (headers and body). If the cryptographic check fails, DKIM fails.
Confirm the signature matches message content. The server recomputes the hash of the signed headers and body, comparing it to the hash in the DKIM signature. A mismatch means tampering occurred or the message was altered in transit.
Compare the 'From' domain with authenticated domains from SPF and DKIM. If the 'From' domain doesn’t match either the SPF-authenticated domain or the DKIM-signed domain, the message is treated as potentially spoofed. This is critical for anti-phishing defense.
Apply filtering and scoring based on authentication results. Messages that pass both SPF and DKIM receive a positive score. If only one passes, a neutral or negative score may apply. This influences inbox placement and spam filtering.

MailTester’s inbox placement tester simulates this exact sequence across real mail providers, giving you a real-world view of how your messages are evaluated. You can test whether your SPF and DKIM checks are properly aligned before sending.

The 7 steps described in “Step-by-step: the authentication workflow”, in order.

Understanding this sequence isn’t just theoretical. It directly impacts deliverability. According to RFC 7208 (the SPF specification), servers perform these checks in a defined order, and misconfigurations in sequence or setup are common causes of failed delivery. If you’re using a platform like SendGrid, Mailchimp, or HubSpot, ensure your configuration respects this flow—otherwise, your messages risk landing in spam or being rejected outright.

Common misconfigurations that disrupt the correct check order

SPF and DKIM checks must run in sequence: SPF first (to validate the sending IP), then DKIM (to verify the message signature). When misconfigured, the order breaks down—leading to false fails, blocked emails, or undetected spoofing. You might see bounces even with correct DNS records if the checks aren’t processed in the right order. Let’s go over the top pitfalls that disrupt this flow.

DKIM and SPF alignment fail when multiple keys are used improperly

Using multiple DKIM signing keys without aligning them to the correct From domain causes DKIM to pass but SPF to fail—especially if the keys don’t match the sender’s domain.
Each DKIM signature must be tied to its own selector and domain; having mismatched or overlapping selectors can confuse receiving servers about which key applies.
Let’s say you sign outbound emails with a key from mail.example.com but the From domain is company.com. Without proper alignment, the receiving server sees DKIM as valid but SPF’s sender IP check may still fail, breaking the trust chain.

SPF directives that delay or short-circuit the IP check

Using include or redirect in SPF can introduce multiple DNS lookups, which delays the final IP evaluation and increases the chance of a soft fail or timeout.
Some receivers impose a lookup limit (e.g., 10 lookups), so overloading SPF with multiple includes (even from trusted services) can trigger a SoftFail if the limit is reached before the IP check finishes.
Third-party services like email marketing tools might use include to reference your domain. If their configuration is incorrect or outdated, your IP might be silently excluded, even if the service is legitimate.

Third-party services without full DNS chain verification

If you use a third-party sending service (e.g., SendGrid, Mailchimp), you’re relying on their authentication chain. But a weak or misaligned setup can break SPF/DKIM order.
These services should use their own domain for DKIM (not yours) and set up SPF to include their IP range. If the service is misconfigured or uses a shared IP pool without proper alignment, your emails may fail SPF even if DKIM passes.
Use tools like MXToolbox or RFC 7208 to test the full path of SPF and DKIM checks before sending. A real-time test can catch issues early.
Verify your entire chain with inbox placement testing—it checks both SPF and DKIM in context, simulating real-world delivery.

Why automated verification tools like MailTester are essential for checking order

Automated tools like MailTester simulate real email delivery by sending test messages through actual production mail servers, revealing the precise order in which SPF and DKIM checks are performed. Unlike manual testing, they capture full header data showing exactly when and how each authentication check runs—critical for spotting misconfigurations before they cause bounces or inbox placement issues. This visibility is standard in email deliverability best practices, as outlined in RFC 7208 and RFC 6376.

What real-world delivery reveals

Most email providers apply SPF and DKIM checks in a defined sequence: SPF first, then DKIM alignment. If a domain's SPF record is misconfigured—say, it allows an IP that doesn’t actually send messages—the message might pass SPF but still fail DKIM alignment. Tools like MailTester catch this early by mimicking the behavior of ISPs like Gmail and Outlook, showing whether the checks are applied in order and with correct results.

Detecting misalignments before they break deliverability

Even small misalignments between the sender domain (From) and the authenticated domains (SPF or DKIM) can trigger filters. For example, if your SPF validates a sending IP but your domain isn’t aligned in the DKIM header, many providers will flag the message as suspicious. MailTester’s inbox placement tests reveal these issues in real time across real servers, not just in a lab environment.

By using MailTester’s inbox placement tester, you’re not just checking if an email can be sent—you’re verifying whether it reaches the inbox under real-world conditions. The report shows the exact check order, header values, and why a message passed or failed.

For teams managing large lists, bulk verification with full header analysis helps identify entire segments at risk due to inconsistent SPF/DKIM alignment. The real-time API integration lets you verify domain alignment during onboarding or sync processes, ensuring only properly aligned emails are sent.

While SPF and DKIM alignment are defined in RFCs, implementation varies. A tool that can trace the actual flow of checks—like MailTester—offers clarity you can’t get from logs alone. It’s not about guessing. It’s about seeing.

How MailTester helps confirm SPF and DKIM checks are in the right order

You can verify SPF and DKIM checks are performed in the correct sequence by sending real emails through production servers and inspecting full delivery headers. MailTester captures the exact validation flow—SPF first, then DKIM—showing pass/fail status at each step. This reveals misconfigurations, like SPF passing but DKIM failing, which can trigger rejection even if alignment is correct.

Test real delivery chains with inbox placement tools

Run inbox placement tests using real email addresses and your actual SMTP server setup—no simulators, no proxies.
Each test sends messages through real infrastructure, replicating production delivery paths.
MailTester delivers reports showing what happens post-delivery, including how SPF and DKIM are validated in sequence.

Inspect full headers to catch misalignment issues

Access complete email headers after delivery to see the real-time validation order: SPF always comes before DKIM in the chain.
Identify when SPF passes but DKIM fails (or vice versa)—a common sign of incorrect DNS records, domain misalignment, or signing errors.
Look for headers like Authentication-Results and Received-SPF to trace each step of the validation flow.
Use inbox placement testing to validate how your messages perform across real inboxes and spam filters.
For deeper analysis, the in-app AI assistant parses header logs and points to likely configuration errors—like mismatched domains in SPF vs DKIM.
You can verify SPF and DKIM in proper sequence without guessing. The full log is available right within the dashboard.

“Proper alignment between SPF and DKIM is not optional—it’s required in almost all major email provider reject decisions.” — Email deliverability best practices, RFC 7001

MailTester doesn’t just check if SPF and DKIM exist. It shows whether they’re tested in the right order and whether the results align. This is critical for avoiding false positives. A single failed check at any point in the chain can lead to delivery failure, even if the message is technically valid.

Want to see how your sending setup performs in real-world conditions? Verify your list with full header insight, or integrate with our real-time API for automated checks in your workflow. No expiration on purchased credits—use them when you need them.

What to test when validating SPF and DKIM order

You must verify that SPF checks pass for the sending IP, DKIM signatures validate against the published public key, both checks occur in the correct sequence (SPF before DKIM), the From domain aligns with both SPF and DKIM domains, and there are no discrepancies in the DKIM-Signature field or SPF mechanism. Let’s walk through each step.

Core checks for SPF and DKIM validation

Does the test message pass SPF for the sending IP? Use RFC 7208 to confirm the IP is authorized in the sender’s SPF record.
Does the DKIM signature validate against the published public key? Check the DNS TXT record for the DKIM selector and ensure the signature hashes the message correctly.
Are both checks executed in the correct order? The receiving server must perform SPF first, then DKIM. If DKIM is checked before SPF, alignment can fail unexpectedly.
Is the From domain aligned with both SPF and DKIM domains? It must match the domain used in the SPF mechanism and the DKIM-Signature’s "d=" tag.
Are there any discrepancies in the DKIM-Signature field or SPF mechanism? Validate that all parameters (e.g., "v=DKIM1", "a=rsa-sha256", "q=relaxed") are present and correctly formatted.

When things go wrong

Even small errors break alignment. For example, a mismatched domain in "d=" or a missing "h=" tag can cause DKIM to fail. SPF may pass, but if the From domain doesn’t match the SPF domain identity, the message risks being marked as spoofed.

MailTester’s inbox placement testing shows how real inboxes react, including rejection patterns tied to SPF/DKIM failures. You can also use our real-time verification API to test individual addresses with full header analysis.

The role of domain alignment and DMARC in final authentication

Even if SPF and DKIM are validated in the correct order, your email still fails DMARC if the domains in those records don’t align with the From domain. DMARC requires either SPF or DKIM to pass, but only if the signing domain matches the visible From domain. Misalignment—like sending from yourcompany.com with a DKIM signature from mailer.yourcompany.com—triggers DMARC rejection, even if technical checks pass.

Why domain alignment is non-negotiable

DMARC doesn’t just check if SPF or DKIM passed—it checks if they match the From domain. If they don’t, it’s treated as a failure. For example, using a third-party service’s domain in the DKIM signature without proper alignment breaks DMARC. This is intentional: it prevents spoofing where a fake domain looks plausible but isn’t the real source.

Let’s say your email passes SPF and DKIM, but the SPF record comes from a different domain than the From address. DMARC sees this as a mismatch and blocks the message. So even flawless technical execution fails due to alignment gaps. This is why RFC 7052 and the DMARC specification explicitly tie policy enforcement to alignment.

Some systems let you set different alignment modes (strict vs lax), but strict alignment is industry best practice. It ensures the sender’s domain in the email actually owns or approves the delivery path. It’s a small rule with big consequences: one mismatched domain can mean your email is blocked by Gmail, Yahoo, or other major providers.

How to test DMARC alignment in practice

Testing SPF and DKIM order alone won’t tell you if your emails will land in the inbox. You need to verify alignment and DMARC evaluation together. That’s where inbox placement testing comes in.

MailTester’s inbox placement test analyzes real-world behavior across major email providers. It shows you whether SPF, DKIM, and DMARC are aligned—and if DMARC policy enforcement is active. You can run the test on a sample email to see how your setup performs before sending at scale. It captures the full chain: from SMTP handshake to final inbox delivery.

Use this to catch alignment issues early. For example, if your DKIM selector is set to default._domainkey but the signing domain is mail.yourcompany.com, and your From domain is yourcompany.com, alignment fails—but only test tools like MailTester will expose it. You can run a test at inbox-tester.com or integrate verification into your workflow with the API or bulk list validation at email-list-verify.com.

The real check isn’t just whether SPF and DKIM passed—it’s whether they did so under the right domain. DMARC makes that the final gate.

Conclusion: Correct order is non-negotiable for inbox placement

SPF must be checked before DKIM in the vast majority of email systems. Skipping or reversing this sequence leads to authentication failures, even if both records are technically valid.

Incorrect ordering causes deliverability drops and harms sender reputation over time. Automated systems do not tolerate misaligned authentication steps — and inbox placement will suffer as a result.

Header analyzers alone cannot confirm real-world behavior. Only full delivery tests, simulating actual email reception across major providers, reveal whether SPF and DKIM are processed in the correct order.

MailTester provides the only full-stack verification workflow that checks the sequence, alignment, and actual delivery of emails — ensuring your authentication setup works as intended. No guesswork. No false positives.

Sources

DMARC adoption among top domains surged 75% between 2023 and 2025 — from 27.2% to 47.7% — in the wake of Google and Yahoo's bulk-sender authentication requirements. — EasyDMARC 2025 DMARC Adoption Report (2025)
Since May 5, 2025, Microsoft Outlook requires SPF, DKIM, and DMARC from domains sending 5,000+ emails per day, rejecting non-compliant mail outright at the SMTP level with error 550 5.7.515. — Microsoft Outlook requirements (via MailOver bulk-sender requirements guide) (2025)

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Can DKIM pass if SPF fails?

Yes, but only if the server checks DKIM before SPF. In most systems, SPF must pass first. Misordering can cause misleading results.

Does the order of SPF and DKIM vary by email provider?

Yes — some providers prioritize DKIM, others SPF. But the standard sequence is SPF first. Consistent testing across providers is required.

How do I test if my email provider checks SPF and DKIM in the correct order?

Send test emails through tools like MailTester and inspect the full header trace. Look for the authentication order in the reported results.

What does 'DKIM and SPF alignment' mean?

It means the domain in the From header matches the domain used in SPF and DKIM. Misalignment causes DMARC failure even if both checks pass.

Can I fix the check order on my email server?

No — the order is defined by the receiving mail server’s policy. You must configure SPF and DKIM properly to align with standard sequences.

Why do some verification tools show SPF and DKIM as both valid but still fail deliverability?

Because the order of checks matters, and some tools don’t simulate real delivery. Misalignment or DMARC failure can cause rejection even with pass results.

Does MailTester test check order in real email servers?

Yes — MailTester sends real test emails to production mail servers and returns full headers showing the exact order and result of SPF and DKIM checks.

How accurate is MailTester’s deliverability testing?

MailTester’s verification accuracy is 98.9%. It uses real SMTP delivery, not just DNS checks, to validate SPF and DKIM behavior in actual inbox environments.

Can I test SPF and DKIM order for multiple domains at once?

Yes — MailTester supports bulk verification and inbox-placement testing across multiple domains and configurations.

Is there a free way to test SPF and DKIM check order?

Yes — MailTester offers 100 free verifications to start. Use them to send test emails and review full headers for authentication order.