SPF, DKIM and DMARC

Email authentication is one of those foundational pillars of internet infrastructure that most people never think about—until something goes horribly wrong. Whether it’s a phishing email that lands in a CEO’s inbox or a legitimate newsletter dumped into spam, the mechanics behind what makes an email “trustworthy” are absolute, unforgiving, and deeply technical. At the heart of this system sit three critical protocols: SPF, DKIM, and DMARC. They work in concert like a security triad, and if you manage a domain, send bulk email, or simply care about deliverability, you need to understand how they interact—not just what each one does in isolation.

Let’s start with SPF, or Sender Policy Framework. Think of SPF as a bouncer checking a guest list at a club. The domain owner publishes a DNS record that lists the IP addresses authorized to send mail on its behalf. When an incoming mail server receives a message, it looks up that SPF record and checks the sending IP against the list. If the IP isn’t on the list, the server can flag the message as suspicious. The key limitation here is that SPF only validates the envelope sender—the address used during the SMTP transaction, not the “From” header that the recipient actually sees. This is a classic loophole. An attacker can easily spoof the visible From address while using their own domain in the envelope, and SPF will pass. Worse, SPF breaks when emails are forwarded. When a message is relayed through another server, the original sending IP is replaced by the forwarding server’s IP, causing SPF to fail even for legitimate senders. This is why SPF alone is insufficient for modern email security.

Next comes DKIM, or DomainKeys Identified Mail. DKIM flips the script by using cryptographic signatures rather than IP allowlisting. The sending server signs the email with a private key, and the corresponding public key is published in the DNS as a TXT record. The receiving server retrieves that public key, decrypts the signature, and verifies that the email’s content hasn’t been tampered with during transit. This is powerful because DKIM doesn’t care about IP addresses or forwarding chains—the signature travels with the email itself. However, DKIM has its own set of subtle pitfalls. The signature covers only specific headers (like From, To, Subject) and the body, but if an intermediate server modifies any of those signed elements—for example, by adding a subject tag like “[External]”—the signature breaks. Also, DKIM signatures do not inherently prove ownership of the From domain. A malicious sender can sign their email with their own domain’s DKIM key, and while that signature passes, it does nothing to stop the visible From address from being spoofed. DKIM answers the question “Is this email exactly as the sender intended?” but not “Who is the intended sender?”

That’s where DMARC enters the room. DMARC, which stands for Domain-based Message Authentication, Reporting, and Conformance, is the policy layer that binds SPF and DKIM together. It lives in DNS as a TXT record and tells receiving servers what to do if an email fails authentication: none (take no action but send reports), quarantine (send to spam), or reject (block outright). Crucially, DMARC also enforces alignment. This means the domain in the From header must match the domain used in either SPF or DKIM. For example, if your emails are sent from the domain `yourcompany.com` but your SPF record authorizes a third-party sender like `sendgrid.net`, that’s an alignment failure. DMARC requires that the legitimate sender’s domain align with the visible sender domain. This is the critical piece that closes the loopholes we discussed earlier. With DMARC in place, an attacker cannot simply use their own DKIM key while spoofing your From domain—the alignment check will fail, and the policy you set will dictate the outcome.

Now, here’s the subtle but essential nuance: DMARC does not make your email more trusted, it makes your email more predictable. Before you publish a DMARC policy of `reject`, you must first run in `none` mode and analyze the aggregate reports it generates. These reports, typically XML files, show you which sources are legitimately sending mail on your behalf and whether they pass SPF and DKIM. This is often the hardest part of implementation. You might discover that legacy marketing tools, ticketing systems, or even your finance department’s CRM are sending emails with misaligned domains. If you jump straight to `reject`, you’ll silently drop legitimate emails—which is arguably worse than the phishing problem you’re trying to solve. The proper rollout path is: start with `none`, monitor for several weeks, fix authentication failures for all legitimate senders, then move to `quarantine`, and finally `reject` once you’re confident everything is aligned.

There’s also the often-overlooked other half of DMARC: reporting. The `rua` and `ruf` tags in your DMARC record define where aggregate and forensic reports are sent. If you ignore these, you’re flying blind. Aggregate reports give you a bird’s-eye view of your email ecosystem—which IPs are sending, how many messages pass SPF/DKIM, and what the alignment status is for each. Forensic reports, when available, contain the full email headers of failed messages. This is a goldmine for security teams, as it provides direct evidence of ongoing phishing attempts against your domain. In a professional setting, DMARC reporting should be integrated into your SIEM or a dedicated email security dashboard, not left as static data files.

In practice, these three protocols work as a chain. SPF authenticates the messenger, DKIM verifies the message’s integrity, and DMARC enforces the identity link between them. But they are not a silver bullet. They do nothing to stop impersonation where an attacker uses a visually similar domain like `yourcompany-security.com`. They also can’t protect against compromised legitimate accounts—if an attacker steals a password and sends from a real account, authentication passes with flying colors. That requires behavioral analysis and user training. What SPF, DKIM, and DMARC do provide is a robust, standards-based defense against domain spoofing, and in doing so, they preserve the single most important thing in email: trust. Without trust, every inbox becomes a minefield, and every well-intentioned automated notification becomes a potential threat. So, audit your DNS records today. If you don’t have a DMARC record yet, that’s your first task. If you do, check your reports and push toward `reject`. The internet’s safety depends on ordinary professionals like you taking these three acronyms seriously.