Understanding DKIM, SPF and DMARC email authentication

How SPF, DKIM and DMARC stop email spoofing: what each DNS record does, how DMARC reports expose spoofers, and a rollout order that won't break your mail.

published on 7 Jun 2025 in email-securityweb-security

Someone has probably already sent an email pretending to be your domain. You would not know: spoofed messages never touch your server. The attacker writes [email protected] in the From field, a victim's mail server accepts it, and your name does the phishing for them.

Three DNS-based technologies exist to shut this down: SPF, DKIM and DMARC. They are usually explained as an acronym soup. They make far more sense as three answers to three different questions.

The three questions

SPF: which servers may send for this domain?

SPF (Sender Policy Framework) is the guest list. You publish a DNS TXT record naming the mail servers authorized to send on behalf of your domain. A receiving server looks up that record and checks whether the connecting IP is on the list.

  • Published as a DNS TXT record on your domain
  • Lists your approved IP addresses and mail servers
  • Receivers compare the actual sending IP against it

DKIM: was this message really written by that domain, unaltered?

DKIM (DomainKeys Identified Mail) is the tamper-evident seal. Your mail server signs each outgoing message with a private key; the matching public key sits in your DNS. If the message is modified in transit, or never came from you at all, the signature fails.

  • Public-key cryptography, applied per message
  • The signature travels in the email headers
  • Receivers verify it against the public key in your DNS

DMARC: and what should happen when those checks fail?

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the enforcement layer. It publishes your policy for failures: none (deliver anyway), quarantine (spam folder), or reject (refuse outright). Crucially, it also tells every major mailbox provider to send you reports about mail claiming to be from your domain.

The reports are the point

Most write-ups treat DMARC reporting as a footnote. In practice it is the feature that changes how you operate, because it is the only mechanism that shows you your domain's email traffic from the receiving side. Two kinds arrive:

Aggregate reports (RUA)

XML summaries with statistics: which servers send mail claiming to be you, how many messages pass or fail each check, and where the traffic originates geographically and organizationally.

Forensic reports (RUF)

Per-message detail on individual failures. This is where you catch exact spoofing attempts, spot patterns of malicious activity, and discover the legitimate service someone in marketing signed up for last quarter that nobody told IT about.

When spoofers actually attack

Once reports start flowing, an attack against your domain stops being invisible. You see the IP addresses sending the fraudulent mail, the volume over time, which providers received it, and whether it failed on SPF, DKIM or both. That intelligence identifies compromised systems, exposes phishing campaigns aimed at your organization, and tells you precisely what to fix in your own setup.

Reading the reports without losing your weekend

There is a catch, and it is the reason I built DMARC Aide: the reports are raw XML, and nobody should be reading raw XML on a Monday. DMARC Aide parses the report files into human-readable form, draws dashboards of your authentication trends, flags the legitimate senders you still need to authorize, and highlights the traffic that looks hostile. The hours it saves are hours you were going to spend in a text editor squinting at <source_ip> tags.

A rollout that will not break your mail

  1. Start with SPF. Publish a record listing your authorized senders.
  2. Add DKIM. Generate keys and configure your server to sign outgoing mail.
  3. Deploy DMARC at p=none. Monitoring mode: nothing is blocked yet, but reports start arriving.
  4. Analyze the reports. Find every legitimate sender, including the forgotten ones.
  5. Tighten gradually. Move to quarantine, then reject, once the reports show only traffic you recognize.

The order matters. Jumping straight to reject is how companies discover, loudly and all at once, which invoices were being sent by a system nobody documented.

Spoofing works because unauthenticated email is trusted by default. SPF, DKIM and DMARC withdraw that default trust for your domain, and the reports show you exactly who was exploiting it. DMARC Aide turns those reports into something you can act on before your coffee gets cold.

Share this on

Comments

What do you think?

  • Darlene Atkins
    Darlene Atkins
    This helped a lot in my new job. Thank you very much.
  • Carl
    Carl
    What's the difference between ~all and -all at the end of the SPF record?