Email was designed in an era when trust was assumed and abuse was theoretical. The core protocol, SMTP, has no built-in mechanism to verify that the sender of a message is who they claim to be. Without additional controls, anyone can open a terminal and send an email that appears to come from your company’s domain — your CEO, your bank, your HR department. The three standards that close this gap are SPF, DKIM, and DMARC, and understanding how they fit together is the foundation of any serious email security posture.

These aren’t new technologies. SPF was formalized in RFC 7208 in 2014, DKIM in RFC 6376 in 2011, and DMARC in RFC 7489 in 2015. Yet misconfigured or missing records remain among the most common findings in domain audits. Getting them right requires understanding not just what each record does, but the specific ways they interact — and how they can fail.

SPF: Telling Receivers Who Can Send for You

SPF, or Sender Policy Framework, works by publishing a DNS TXT record that lists the IP addresses and mail servers authorized to send email on behalf of your domain. When a receiving mail server gets a message claiming to be from yourcompany.com, it queries the DNS for an SPF record and checks whether the sending IP appears on the authorized list.

A typical SPF record looks like this:

v=spf1 include:_spf.google.com include:mailchimp.com ip4:203.0.113.45 ~all

Breaking this down: v=spf1 identifies the record type, include: statements delegate authorization to third-party sending services, ip4: explicitly authorizes a single IP, and the final qualifier (~all, -all, or ?all) tells receivers what to do with mail that doesn’t match. A tilde (~all) is a soft fail — the message is accepted but marked suspicious. A hard fail (-all) instructs receivers to reject non-matching mail outright. Most operators start with ~all and tighten once they’re confident they’ve captured all legitimate sending sources.

SPF has a significant architectural limitation: it breaks when email is forwarded. When a message is forwarded from one mailbox to another, the intermediate server’s IP is not in your SPF record, so the check fails even though the original message was legitimate. This is one reason SPF alone is insufficient — it needs to work alongside DKIM.

DKIM: Cryptographic Proof That Content Wasn’t Altered

DKIM, or DomainKeys Identified Mail, takes a different approach. Instead of checking the sending IP, it uses asymmetric cryptography to sign outgoing messages. Your mail server holds a private key and uses it to generate a signature that gets added to the email’s headers. The corresponding public key is published in DNS. When a receiving server gets the message, it retrieves your public key and uses it to verify the signature.

The DKIM signature covers selected headers and the message body. If either is modified in transit — even a single character — the signature verification fails. This makes DKIM useful not only for proving the message came from an authorized source but also for detecting tampering.

A DKIM DNS record lives at a selector subdomain:

selector1._domainkey.yourcompany.com

The “selector” allows you to publish multiple DKIM keys simultaneously — useful when rotating keys or using different keys for different sending services. Google Workspace, for example, uses selectors like google._domainkey while a separate email marketing tool might use k1._domainkey. Critically, DKIM survives forwarding because the signature travels with the message headers, not the sending IP.

DMARC: Connecting SPF and DKIM to a Policy

SPF and DKIM operate independently, but DMARC ties them together and adds something neither provides alone: reporting and enforcement. DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It instructs receiving mail servers on what to do when a message fails both SPF and DKIM checks, and it directs those servers to send you reports about what’s happening with mail claiming to use your domain.

DMARC introduces the concept of “alignment.” A DMARC check passes only when the domain in the message’s visible From: header aligns with the domain that passed SPF or DKIM. This is the key distinction — it’s not enough for SPF to pass on some technical envelope address that users never see. The authenticated domain must match what appears in the user’s email client.

A DMARC record also lives in DNS as a TXT record:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourcompany.com; ruf=mailto:forensics@yourcompany.com; pct=100; adkim=r; aspf=r

Each tag has a specific function. p= sets the policy: none (monitor only), quarantine (send to spam), or reject (block entirely). rua= specifies where aggregate reports go — XML digests sent daily by participating receivers. ruf= requests forensic reports on individual failures, though many large providers no longer send these due to privacy concerns. pct= applies the policy to a percentage of failing messages, useful for gradual rollouts. adkim=r and aspf=r set alignment to “relaxed,” meaning subdomains are permitted to align; strict mode (s) requires exact domain matches.

The Right Deployment Order

Start with p=none and collect aggregate reports for at least two to four weeks before enforcing anything. Tools like Dmarcian, Postmark’s DMARC Digests, or the open-source parsedmarc can parse the XML reports into readable summaries. During this phase, you’ll almost certainly discover sending sources you forgot about — an old CRM, a ticketing system, a partner integration. Every legitimate source needs either an SPF include or a DKIM signature before you move to enforcement.

Once your reports show that nearly all legitimate mail is passing authentication, move to p=quarantine with pct=25, then increase the percentage over time. Only after sustained clean reports should you move to p=reject. Jumping directly to reject on a misconfigured domain can cause legitimate mail to be silently dropped.

What Attackers Actually Encounter

Without DMARC at enforcement, an attacker can register a lookalike domain or simply forge your From: header and send convincingly branded phishing email. Passing SPF on a completely unrelated envelope domain is trivial. DMARC at p=reject removes that entire attack surface for your exact domain — receiving servers will refuse to deliver the message.

It doesn’t prevent subdomain abuse unless you add sp=reject to cover subdomains, or publish individual DMARC records for each subdomain. A common oversight is assuming a root domain DMARC record covers mail.yourcompany.com or invoices.yourcompany.com under strict policy. Attackers who discover an organization has p=reject on the root domain but uncovered subdomains will shift to spoofing those instead.

Ongoing Maintenance Is Not Optional

DKIM keys should be rotated periodically — a common recommendation is every six to twelve months, though the actual rotation frequency depends on your threat model and the sensitivity of your mail. Rotating means generating a new key pair, publishing the new public key under a new selector in DNS, updating your mail server or SaaS platform to sign with the new private key, and then removing the old selector record only after confirming the new one is active.

SPF records need updating whenever you add or remove a sending service. The SPF specification caps DNS lookup chains at ten — exceed this limit and the entire SPF record returns a permerror, effectively disabling SPF for your domain. Services like mxtoolbox.com/spf can count your lookup depth. Flattening tools exist to inline IP addresses and reduce lookups, though they require re-flattening whenever an included service changes its IP ranges.

The detail that catches most organizations is the gap between publishing records and actually verifying them end-to-end. Sending a test message to mail-tester.com or using Google’s MXToolbox DMARC test tool after every configuration change remains one of the most reliable ways to confirm the records are working as intended before real mail — or an attacker — finds out they aren’t.