SPF, DKIM and DMARC Explained

Email was designed without any way to verify who sent a message. The From address is just text, and anyone can set it to your domain. Attackers use this to send phishing and payment fraud that appears to come from your organization, to your staff, your customers and your partners.

Three DNS-based standards address the problem: SPF, DKIM and DMARC. Together they let receiving mail servers check whether a message claiming to be from your domain really is, and tell them what to do when it is not. Federal agencies have been required to deploy DMARC at an enforcing policy under CISA Binding Operational Directive 18-01, and major email providers now expect it from bulk senders.

SPF: who is allowed to send

Sender Policy Framework is a DNS record that lists the servers and services authorized to send mail for your domain. The receiving server checks whether the sending server's IP address is on the list.

• It checks the envelope sender, the technical return address, not the From address users see.
• It has a limit of ten DNS lookups. Each include for a third-party service counts, and exceeding the limit causes SPF to fail.
• It breaks on forwarding, because the forwarding server is not on your list.

DKIM: a signature on the message

DomainKeys Identified Mail adds a cryptographic signature to outgoing messages. The sending service signs with a private key, and the receiving server checks the signature using a public key published in your DNS. A valid signature shows the message was sent by someone holding the key and that signed parts of the message were not altered in transit. DKIM usually survives forwarding, which makes it the more reliable of the two checks.

DMARC: alignment and policy

SPF and DKIM on their own do not protect the From address. An attacker can pass SPF for their own domain while displaying yours. Domain-based Message Authentication, Reporting and Conformance closes that gap with two ideas.

Alignment. DMARC passes only if SPF or DKIM passes for a domain that matches the domain in the visible From address. Relaxed alignment allows subdomains of the same organizational domain to match. Strict alignment requires an exact match.

Policy. Your DMARC record tells receivers what to do with messages that fail: none (deliver and report), quarantine (treat as suspicious, usually the spam folder), or reject (refuse the message).

Reporting. Receivers send aggregate reports to the address in your record, showing which sources sent mail using your domain and whether it passed. These reports are how you find every legitimate sender before enforcing.

Moving from none to reject

• Start at p=none with aggregate reporting enabled. Use a reporting tool, since the raw XML reports are hard to read at volume.
• Identify every legitimate sender: your mail platform, marketing tools, ticketing systems, HR and payroll services, and anything else that sends as your domain.
• Fix each one so it passes aligned SPF or, preferably, aligned DKIM using your domain.
• Move to quarantine, optionally applying it to a percentage of failing mail at first, and watch for problems.
• Move to reject once legitimate mail consistently passes. Only reject provides full protection against direct spoofing.

Many organizations stop at p=none and never move on. Monitoring alone tells you about spoofing but does not stop it.

Common mistakes

• Stale senders. SPF records accumulate includes for services you stopped using years ago, wasting lookups and authorizing systems you no longer control. Review them regularly.
• Old DKIM keys. Keys that are never rotated, or are shorter than current recommendations, weaken the signature. Rotate keys on a schedule and remove keys for retired services. Use 2048-bit keys where your provider supports them.
• Forgotten domains. Parked and unused domains can be spoofed too. Publish an SPF record that authorizes no senders and a DMARC reject policy for every domain that does not send email.
• Ignoring subdomains. Set a subdomain policy so attackers cannot spoof made-up subdomains.
• Nobody reads the reports. Assign an owner, because new senders appear whenever a department adopts a new tool.

What DMARC does not do

DMARC protects your exact domain. It does not stop look-alike domains that differ by a character, or compromised accounts at a real supplier. Those threats need user awareness, mail filtering and the payment verification controls covered elsewhere in this series. Our social engineering assessments test how staff respond to convincing look-alike messages.

How CDT can help

CDT reviews email authentication as part of broader hardening engagements, helping organizations inventory senders, fix alignment and reach an enforcing DMARC policy without disrupting legitimate mail.