SPF, DKIM and DMARC: Why Your Domain Needs All Three

SPF, DKIM, DMARC: What they are and why your domain needs all three?

Business email compromise remains one of the most damaging online crimes. The FBI’s Internet Crime Complaint Center reported victims lost billions in 2023, illustrating how costly email spoofing and fraudulent messages can be. A common root cause is a domain that provides no clear instructions to receiving mail servers about which senders are authorized. That gap is what SPF, DKIM, and DMARC are designed to close.

Many IT teams recognize the acronyms, but fewer fully understand how each protocol functions and why deploying all three together is important. Implemented as a set, they dramatically reduce the chance that attackers can impersonate your domain and deceive recipients.


What each one actually does

DMARC, SPF and DKIM

SPF (Sender Policy Framework) lets you publish a DNS record listing which mail servers are permitted to send email on behalf of your domain. When a receiving mail server gets an incoming message, it can check the SPF record to see whether the sending server is authorized. SPF is the simplest to configure, and provides a baseline layer of trust, but it verifies only the sending server — not the integrity of the message itself.

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to outgoing messages. The signature is generated with a private key held by the sender and validated against a public key published in DNS. That mechanism proves the message content hasn’t been altered in transit and that it legitimately originated from the domain that signed it. DKIM verifies the message integrity and origin but does not indicate which server actually delivered the message.

DMARC (Domain-based Message Authentication, Reporting & Conformance) acts as the policy and reporting layer that connects SPF and DKIM. DMARC instructs receiving servers what to do when a message fails SPF or DKIM checks: monitor and report, quarantine, or reject. DMARC also provides reports back to domain owners so they can see who is sending mail on their behalf, identify misconfigurations, and detect abuse across their email ecosystem.

Type Verifies Doesn’t cover
SPF The sending server is on your authorized list Whether the message itself was altered
DKIM The message wasn’t altered and came from your domain Which server actually sent it
DMARC Ties SPF and DKIM together, sets the enforcement policy Has nothing to enforce without SPF/DKIM configured underneath

Why one isn’t enough

Each protocol addresses a different aspect of email authentication. SPF confirms the sender’s infrastructure, DKIM confirms message integrity, and DMARC combines the two and defines what to do when checks fail. Relying on only one leaves exploitable gaps: SPF alone can be bypassed if an attacker sends from an unauthorized server and receiving systems are not instructed to act; DKIM alone can validate legitimate mail but do nothing to prevent parallel abuse from other senders; DMARC without valid SPF or DKIM records provides no enforcement capability. To achieve meaningful protection, implement all three and ensure they are configured to work together.

In practice, many organizations stop after publishing a DMARC record in monitoring mode (p=none). While monitoring produces useful visibility, it does not block spoofed messages. Moving to stricter DMARC policies, such as p=quarantine (which sends failing mail to spam) or p=reject (which blocks failing mail), significantly improves protection but requires careful staging to avoid unintentionally disrupting legitimate delivery.


What to do next

Start by auditing your domain’s DNS for existing SPF, DKIM, and DMARC records. Verify that:

  • Your SPF record accurately lists all legitimate sending services and is not overly permissive.
  • DKIM signing is enabled for each outbound mail source, with keys rotated periodically and selectors organized so you can manage multiple senders.
  • DMARC is publishing a reporting address so you receive aggregate and forensic reports, and that you review those reports to identify unauthorized senders or configuration issues.

When you move DMARC from monitoring to enforcement, proceed gradually. First confirm that every legitimate sending system is authenticated via SPF and/or DKIM. Use the reports to resolve failures, add missing senders to your SPF record, and enable DKIM signing where needed. Only after legitimate mail consistently passes checks should you transition to p=quarantine and, later, p=reject. This staged approach preserves legitimate email flow while progressively reducing the risk of successful spoofing.

Common pitfalls include overly long SPF records that exceed DNS lookup limits, missing DKIM signatures from third-party services, and ignoring DMARC reports. Addressing these issues improves deliverability and reduces the chance that attackers will successfully impersonate your brand.


Checking and maintaining SPF, DKIM, and DMARC is an ongoing process, not a one-time task. Regular reviews, key rotation for DKIM, and attention to DMARC reports ensure your domain remains protected as your email ecosystem changes.

If you need a clear checklist: audit records, consolidate and authorize all legitimate senders, enable DKIM where possible, publish DMARC reporting, and move enforcement gradually after confirming legitimate traffic passes authentication checks.