SPF, DKIM and DMARC are three separate DNS-based mechanisms that, together, let a receiving mail server judge whether an incoming message claiming to be from a given domain is actually legitimate. They get mentioned together so often that they can start to sound like interchangeable options, but each one verifies something genuinely different, and DMARC specifically doesn't function without the other two already in place.

SPF: which servers are allowed to send for this domain

Sender Policy Framework (SPF) is a DNS TXT record that lists which mail servers are authorized to send email on behalf of a domain, specified as a set of IP addresses or included references to a provider's own SPF record. When a receiving server gets a message claiming to be from a given domain, it checks the sending server's IP address against that domain's published SPF record. If the sending IP isn't on the list, the message fails SPF — which doesn't automatically mean it's rejected, but it's a strong signal used in spam-filtering decisions. SPF only checks the sending server's identity; it says nothing about whether the message content was altered in transit, which is what DKIM covers.

DKIM: proving a message wasn't altered in transit

DomainKeys Identified Mail (DKIM) attaches a cryptographic signature to outgoing messages, generated using a private key the sending mail system holds, with the corresponding public key published in a DNS TXT record for the sending domain. A receiving server can use that published public key to verify the signature on an incoming message — if it checks out, the message's key content genuinely came from a system holding the matching private key and wasn't altered after signing. DKIM verifies integrity and origin at the message level, independent of which server relayed it, which is a meaningfully different guarantee than SPF's server-level check.

DMARC: the policy that ties the other two together

Domain-based Message Authentication, Reporting and Conformance (DMARC) is also a DNS TXT record, and it does two things SPF and DKIM don't do on their own: it specifies what a receiving server should actually do with a message that fails authentication (quarantine it, reject it outright, or take no action beyond monitoring), and it requires alignment — checking that the domain in the visible "From" address actually matches the domain that passed SPF or DKIM, not just any domain that happened to pass. A message can technically pass SPF using one domain while displaying a completely different domain in the From field a recipient sees; DMARC alignment is specifically what closes that gap. Alignment itself comes in two modes — strict, requiring an exact domain match between the From header and the domain that passed SPF or DKIM, and relaxed, allowing a match at the organizational domain level (so a message from a subdomain can still align with the parent domain's authentication). Most DMARC deployments start with relaxed alignment, since it accommodates legitimate subdomain variation without requiring every sending subdomain to be separately, exactly authenticated. DMARC also enables aggregate reporting, so a domain owner can see, in summary, which servers are sending mail claiming to be from their domain and whether those messages are passing or failing authentication — useful for noticing unauthorized use of a domain in spoofed messages.

What these records actually look like

All three are published as DNS TXT records, which makes them easy to find and read once you know the shape to look for. A typical SPF record looks something like v=spf1 ip4:203.0.113.10 include:_spf.example-provider.com ~all — it starts by declaring the SPF version, lists authorized sources (a specific IP, or an include reference to a third-party provider's own SPF record, common when using an external email or marketing platform), and ends with a qualifier (~all marks unlisted sources as a soft fail, while -all marks them as a hard fail — a stricter setting). A DKIM record is published under a selector-specific subdomain (something like selector1._domainkey.example.com) and contains the public key itself, which is why DKIM setup always involves a selector name provided by whatever system is doing the signing. A DMARC record lives at _dmarc.example.com and looks like v=DMARC1; p=quarantine; rua=mailto:reports@example.com — the p tag is the policy (none, quarantine, or reject), and the rua tag specifies where aggregate reports get sent. None of these need to be memorized to use them correctly, but recognizing the shape makes it possible to actually check a domain's own records rather than taking a tool's pass/fail summary on faith.

How the three work together

DMARC's policy only has something to evaluate because SPF and DKIM already ran their checks — DMARC passes a message if it passes SPF or DKIM (ideally both) and the aligned domain check succeeds, and it's the DMARC policy record that determines what happens to a message that fails that evaluation. Publishing a DMARC record with no SPF or DKIM records in place for the domain doesn't provide protection, because there's nothing for DMARC to align against; getting meaningful protection from all three requires SPF and DKIM configured and passing first, with DMARC layered on top specifying enforcement.

A worked example: switching email providers

A business moves from one email provider to another, migrating mailboxes over a weekend. Monday morning, outgoing mail starts landing in recipients' spam folders or bouncing entirely — a classic symptom of the SPF record still listing only the old provider's sending servers, with no inclusion for the new provider's. The new provider's servers aren't on the authorized list, so messages sent through them fail SPF, and depending on the domain's DMARC policy, that failure can mean outright rejection rather than just a spam-folder landing. The fix is updating the SPF TXT record to include the new provider's servers (typically via an "include" mechanism the new provider documents) and configuring DKIM signing with the new provider's keys, ideally completed and verified before the mailbox migration itself, not discovered after the first bounce-back arrives.

A checklist for verifying all three

  • SPF record exists and lists every current sending source — including any third-party service that sends on the domain's behalf (a CRM, a transactional email service, a marketing platform), not just the primary mailbox provider.
  • DKIM is configured and actively signing outgoing mail — having a DKIM DNS record published is only half of it; the sending system also has to be actively signing with the matching private key.
  • DMARC record is published, with alignment confirmed passing — not just present, but actually evaluating as pass for legitimate outgoing mail, which is visible in DMARC aggregate reports.
  • DMARC policy matches the business's risk tolerance — starting at a monitoring-only policy before moving to quarantine or reject avoids accidentally blocking legitimate mail during setup.
  • Every legitimate third-party sender is accounted for — a CRM, a helpdesk tool, a marketing platform, an invoicing system — each one sending on the domain's behalf needs to be included in SPF and, ideally, configured to sign with DKIM, or its mail risks failing authentication even though it's entirely legitimate.

Moving a DMARC policy from monitoring to active enforcement is worth doing gradually rather than all at once: a few weeks at p=none collecting aggregate reports surfaces any legitimate sending source that isn't yet properly authenticated, before switching to p=quarantine and eventually p=reject risks that source's mail being blocked outright.

Misconfiguration in any one of these is one of the more common, specific causes behind legitimate business email landing in spam — see Why Business Emails Go to Spam for a broader troubleshooting workflow when authentication alone doesn't explain it, and Common Website Security Mistakes for where email authentication sits among other frequently-skipped basics.