Difference among SPF, DKIM, and DMARC explained for MSPs

Executive summary: MSPs managing client email environments need SPF, DKIM, and DMARC working together to protect against spoofing attacks and meet inbox provider requirements. This guide explains how each protocol functions, why all three are necessary, and how MSPs can efficiently deploy email authentication across their client base.

Key takeaways:

• SPF validates sending server IP addresses, DKIM verifies message integrity through cryptographic signatures, and DMARC enforces policy when authentication fails
• Google and Yahoo now require SPF and DKIM for bulk senders, making email authentication essential for client deliverability
• MSPs should implement SPF first, then DKIM, then DMARC at p=none before progressing to enforcement
• Red Sift OnDMARC's multi-tenant architecture lets MSPs manage authentication across all client domains from a single dashboard, reaching enforcement in 6-8 weeks vs 6-12 months manually

You send what looks like a routine business email on behalf of a client, only to have it bounce back or land in spam. Or worse, your client's customers receive phishing emails that appear to come from their domain, damaging their reputation before anyone knows there's a problem. These scenarios happen because email, by design, lacks built-in verification of sender identity.

The original email protocols from the 1980s assumed trust between mail servers. Anyone could claim to send email from any domain, and receiving servers had no reliable way to verify these claims. This fundamental weakness enables spoofing attacks, where attackers forge the From address to impersonate trusted senders.

Email authentication protocols exist to solve this security gap. SPF, DKIM, and DMARC work together to verify that emails claiming to come from your clients' domains are legitimate. For MSPs managing multiple client environments, understanding how each protocol functions and why all three matter can mean the difference between a secure email infrastructure and one that's vulnerable to spoofing and phishing attacks.

SPF (Sender Policy Framework) is an email authentication standard that allows domain owners to specify which IP addresses are authorised to send email on their behalf. When a receiving mail server gets an email claiming to be from a client's domain, it checks the SPF record to confirm the sending server's IP address is on the approved list.

Think of SPF as a guest list at a secure building. The receiving server checks whether the sending IP address appears on the published list of authorised senders. If it matches, the email passes SPF authentication. If not, it fails.

DKIM (DomainKeys Identified Mail) takes a different approach by adding a digital signature to email headers. This cryptographic signature proves the message hasn't been altered in transit and confirms it originated from a server with access to the private DKIM key. The receiving server validates this signature using the public key published in DNS.

Where SPF focuses on the sending server's identity, DKIM verifies the message itself. The signature covers both the headers and body of the email, so any tampering during transit invalidates the signature.

DMARC (Domain-based Message Authentication, Reporting and Conformance) builds on both SPF and DKIM by adding policy enforcement and reporting capabilities [1]. While SPF and DKIM verify different aspects of an email, DMARC ties these checks to the domain visible in the recipient's inbox and tells receiving servers what to do when authentication fails.

The critical difference is that DMARC gives you control over failed authentication. You decide whether failing emails should be delivered anyway, quarantined to spam, or rejected entirely. For MSPs, this means you can set consistent policies across all client domains.

Red Sift’s email security guide provides additional context on how DMARC coordinates with SPF and DKIM for comprehensive domain protection.

SPF validation happens when the receiving server queries DNS for the domain's SPF record. This TXT record contains a list of authorised IP addresses and includes mechanisms like "include" directives for third-party services. The server compares the sending IP against this list and returns a pass, fail, or neutral result [2].

• SPF: Receiving server queries DNS, compares sending IP to authorised list, returns pass/fail/neutral
• DKIM: Mail server signs message with private key, receiving server retrieves public key from DNS, validates signature
• DMARC: Checks SPF or DKIM results, verifies domain alignment with From header, applies policy based on configuration

DKIM operates through public key cryptography. The mail server signs outgoing messages with a private key, and receiving servers verify the signature using the public key published in DNS. If even one character in the email body changes during transit, the DKIM signature validation fails.

DMARC coordinates these two authentication methods and adds critical functionality. When you publish a DMARC record, you specify a policy (none, quarantine, or reject) that tells receiving servers how to handle emails that fail SPF or DKIM checks. DMARC also requires alignment, meaning the domain in the From header must match the domain authenticated by SPF or DKIM.

The complete guide to DKIM and SPF resource explains the technical details of how these foundational protocols verify email authenticity.

Email spoofing attacks cost organizations an average of $1.6 million per incident, according to FBI data. Without authentication protocols, attackers can easily forge client domains in the From header to impersonate executives, customers, or partners. These business email compromise attacks succeed because standard email protocols have no built-in sender verification.

For MSPs, the stakes multiply across your entire client base. A single spoofing incident affecting one client can damage your reputation and trigger questions from every other client about their own security posture. And the financial impact extends beyond direct losses. Clients face costs from incident response, forensic investigation, legal fees, regulatory fines, and customer notification. Reputational damage can persist long after the immediate crisis ends.

Authentication protocols protect domain reputation and deliverability across your client portfolio. Major email providers like Google, Microsoft and Yahoo now require SPF and DKIM for bulk senders, and they use DMARC compliance as a signal when determining whether emails reach the inbox or spam folder [3].

Beyond protecting outbound email, these protocols defend your clients' customers and partners from receiving spoofed messages. DMARC reporting gives you visibility into who's sending email on behalf of each client domain, including both legitimate services and potential attackers. For MSPs, this centralised visibility across all client domains is a powerful differentiator.

SPF and DKIM serve complementary roles in the authentication stack. SPF validates the sending server's authorisation based on IP address, but it doesn't verify message content or the visible From header. DKIM confirms message integrity and cryptographic authentication, but it doesn't require the signing domain to match the From header domain.

This is where DMARC becomes essential. DMARC requires "alignment" between the domain authenticated by SPF or DKIM and the domain shown in the From header. This alignment check prevents a common spoofing technique where attackers pass SPF by using their own domain in the mail-from address while displaying a client's domain in the visible From header.

• Layer 1: Infrastructure validation (SPF) Validates sending server IP address. Quick validation through a single DNS lookup. Breaks during email forwarding.
• Layer 2: Message validation (DKIM) Validates message hasn't been altered. Uses cryptographic signature. Survives forwarding intact.
• Layer 3: Policy enforcement (DMARC) Requires alignment with From header. Enforces pass/quarantine/reject policies. Coordinates SPF and DKIM results.

MSPs typically implement all three protocols in stages across client environments. You start by publishing SPF and DKIM records, then add a DMARC record with a policy of "none" to collect data without affecting mail flow. As you identify and authorise legitimate sending sources for each client, you gradually move to stricter policies.

The protocols also provide different value for different mail flows. SPF works well for direct sending from client infrastructure but has limitations with email forwarding. DKIM survives forwarding because the signature travels with the message.

Setting up SPF starts with identifying every service and server that sends email using each client's domain. This includes email servers, marketing platforms, CRM systems, and any third-party services. Each legitimate sender needs to be included in the SPF record through IP addresses or "include" mechanisms.

The discovery phase often reveals unexpected sending sources. MSPs typically find that clients are using more email services than they realised, from automated notification systems to help desk platforms to HR tools. Documenting these across your client base helps identify common patterns you can template.

The SPF record lives as a TXT record in DNS and follows a specific syntax. A basic record might look like "v=spf1 ip4:192.0.2.1 include:_spf.google.com -all" where "-all" means unauthorised IPs should fail authentication. The record must stay under 255 characters and avoid exceeding 10 DNS lookups or it will break.

The 10 DNS lookup limit is a common stumbling block that silently breaks email authentication. Each "include" mechanism counts as a lookup, and some services chain multiple includes together. When an SPF record exceeds this limit, receiving servers treat it as permanently failed, potentially blocking all legitimate email. You may need to flatten SPF records by converting includes to IP addresses or consolidate services to stay within the limit. For MSPs managing multiple client domains, tracking lookup counts becomes a critical operational task.

DKIM implementation requires generating a public-private key pair and configuring the mail server to sign outgoing messages with the private key. You publish the public key in a DNS TXT record at a selector subdomain like "selector1._domainkey.clientdomain.com". Most email platforms provide tools to generate keys and configure DKIM signing.

SPF setup phase

• Audit all email-sending services for each client
• Document IP addresses and include mechanisms
• Create SPF record with v=spf1 prefix
• Verify lookup count stays under 10
• Test with SPF validator tool
• Publish to DNS and verify propagation

DKIM setup phase

• Generate 2048-bit key pair
• Configure mail server with private key
• Publish public key to DNS
• Enable DKIM signing for all outbound mail
• Send test messages and verify headers
• Coordinate with third-party services

DMARC setup phase

• Start with p=none policy (monitoring only)
• Configure aggregate report address (rua=)
• Publish DMARC record to DNS
• Monitor reports for 2-4 weeks
• Identify and fix authentication failures
• Progress to p=quarantine, then p=reject

Key length matters for DKIM security. Use at least 1024-bit keys, though 2048-bit keys provide better security against future attacks. Some MSPs rotate DKIM keys periodically as a security best practice across all client environments.

For DMARC, you create a TXT record at "_dmarc.clientdomain.com" that specifies policy and reporting preferences. Start with "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourmsp.com" to collect data without blocking mail. The rua tag directs aggregate reports to your inbox so you can monitor authentication results across all clients from a single location.

Reports arrive as XML files that show authentication results for every email sent from each client domain. Without automated parsing, these reports are difficult to interpret at scale. You'll see data on which sending sources passed or failed SPF and DKIM, which helps you identify configuration problems before enforcing stricter policies.

The complete DMARC implementation guide walks through each stage of deployment, from initial setup through reaching enforcement at p=reject.

The question isn't which protocol to choose but rather in which order to implement them. All three protocols are necessary for comprehensive email security. SPF and DKIM provide the authentication mechanisms, while DMARC ties them together with policy enforcement and visibility.

Start with SPF because it's the most straightforward to implement. You can typically deploy SPF in a few hours by identifying sending sources and publishing a DNS record. SPF alone provides basic protection and improves deliverability with major email providers.

Add DKIM next because it provides stronger authentication than SPF alone. DKIM's cryptographic signatures can't be easily spoofed, and unlike SPF, DKIM survives email forwarding. The combination of SPF and DKIM gives you two independent authentication mechanisms that DMARC can use.

Implement DMARC last because it requires SPF and DKIM to function effectively. Begin with a monitoring-only policy (p=none) to identify legitimate sending sources, then progressively move to quarantine and reject policies as you gain confidence in your configuration.

Some MSPs wonder if they can skip protocols or rely on just one to save time across client deployments. This approach leaves significant gaps. SPF alone can't prevent certain spoofing attacks. DKIM alone doesn't enforce From header alignment. Only DMARC provides the policy enforcement that actually blocks spoofed emails from reaching recipients.

Implementing email authentication manually across dozens or hundreds of client domains means tracking multiple DNS records, parsing complex XML reports, and coordinating with third-party email services for each client. Red Sift OnDMARC platform automates this process, helping MSPs reach DMARC enforcement across their client base in 6-8 weeks compared to the 6-12 months typical for manual implementation.

The platform starts by monitoring the email ecosystem and automatically identifying all sources sending email on behalf of each client. Instead of parsing raw DMARC reports, you get a visual dashboard showing which sending sources are authenticated and which need attention across your entire client portfolio.

OnDMARC categorises sending sources automatically, distinguishing between corporate email servers, authorised third-party services, and potentially malicious sources. The platform shows you exactly which services are passing authentication and which need configuration updates for each client.

The platform detects configuration errors in SPF, DKIM, and DMARC records and offers clear remediation steps. When you're ready to enforce DMARC, OnDMARC monitors the impact and alerts you to any legitimate mail that would be affected. The system can predict the impact of policy changes before you implement them, reducing the risk of blocking legitimate email for your clients.

For MSPs with multiple clients and complex environments, OnDMARC provides centralised management and reporting. You can see authentication status across your entire client domain portfolio and ensure consistent security policies. The multi-tenant architecture means you can manage all clients from a single interface while maintaining proper data separation.

The Red Sift OnDMARC platform scales from small MSPs to large managed security service providers with hundreds of client domains.

[1] "DMARC vs SPF vs DKIM - The Ultimate Comparison." courier.com. https://www.courier.com/guides/dmarc-vs-spf-vs-dkim

[2] "What are DMARC, DKIM, and SPF?" Cloudflare. https://www.cloudflare.com/learning/email-security/dmarc-dkim-spf/

[3] "SPF, DKIM, DMARC: The 3 Pillars of Email Authentication." higherlogic.com, 2024-01-01. https://www.higherlogic.com/blog/spf-dkim-dmarc-email-authentication/