Security
Publish DMARC at reject, then keep the callback rule anyway
SPF, DKIM, and DMARC in plain terms, a sequence for reaching enforcement without breaking mail, and the fraud none of them touch.
Email authentication is three DNS records and the habit of reading the reports they generate. The work is unglamorous, and it sits between an attacker and a redirected vendor payment.
The fraud it addresses is ordinary. A message arrives in accounts payable, apparently from a known vendor, saying the banking details on file have changed and the next payment should go to a new account. The contract number is correct and the timing matches a real invoice. If nothing in the mail path challenges the sending domain, the remaining defense is a clerk's instinct.
Public agencies make that message easy to write. Agendas list contract awards, directories give names and titles, and procurement portals name the contracting officer. Invoice cycles are predictable and approval chains are documented.
SPF names the servers allowed to send
Sender Policy Framework (RFC 7208) is a DNS record listing the hosts permitted to send mail for your domain. The receiving system compares the connecting server against that list and records a pass or a fail.
SPF checks the envelope sender used in the SMTP transaction, not the From address displayed in the mail client, so SPF alone does nothing about a spoofed From line. The specification also limits an evaluation to ten DNS-querying mechanisms. A record that chains through enough third-party includes exceeds that limit and returns a permanent error, a failure that arrives quietly. Every system that sends as the domain belongs in the inventory: payroll, mass notification, the permit portal, utility billing, the help desk.
DKIM shows the message was not altered
DomainKeys Identified Mail (RFC 6376) attaches a cryptographic signature to outbound mail. The private key stays with the sending platform, the public key is published in DNS under a selector name, and the receiver verifies that the signed headers and body arrived unchanged. DKIM survives simple forwarding, which SPF does not, though a relay that rewrites the subject or appends a footer, as some mailing lists do, breaks the signature. Ask each sending platform what key length it uses and whether it supports rotation.
DMARC is the record that decides
Domain-based Message Authentication, Reporting and Conformance (RFC 7489) adds two things the other records cannot supply.
The first is alignment. DMARC passes only when a domain that passed SPF or DKIM matches the domain in the From header the reader actually sees. Without that requirement, an attacker can pass SPF using a domain they control while displaying yours.
The second is policy and reporting. The record tells receiving systems what to do with mail that fails: none, quarantine, or reject. It also names an address for aggregate reports, which are the only broad view of who sends mail as your domain. A starting record is short: v=DMARC1; p=none; rua=mailto:dmarc@example.gov. A policy of none changes nothing about delivery; it turns on the reporting that usually reveals senders nobody remembered. Subdomains inherit the organizational policy unless the sp tag says otherwise. Reports arrive as XML, so expect to need a parsing tool or service.
Reaching enforcement without breaking legitimate mail
Treat it as a sequence.
- Inventory every service that sends as the domain, including subdomains and domains kept only for old program names.
- Publish DMARC with a policy of none and a reporting address, then read the results until the sending picture stops changing.
- Fix SPF and DKIM for each legitimate sender the reports reveal, and retire the senders nobody can account for.
- Move to quarantine, then to reject, watching delivery and reports at each step.
- Close the parked domains: DMARC at reject, an SPF record of v=spf1 -all, a null MX record (RFC 7505), and a DKIM record with an empty public key. A domain that never sends mail is a free identity until you close it.
- Put SPF, DKIM, and DMARC requirements into vendor and hosting language, and apply them to contractors that send mail on your behalf.
CISA Binding Operational Directive 18-01 required federal civilian executive branch agencies to publish DMARC with a policy of reject, alongside related mail and web changes. It does not bind state, local, tribal, or territorial governments, but it is the language a federal partner is likely to use. We publish reject on our own domains, including the ones that exist only to hold a name, and we read the aggregate reports rather than filing them.
What it does not stop
Authentication protects domains you own. It says nothing about a lookalike domain differing from a vendor's by one character, nothing about a display name that reads as your finance director over a webmail address, and nothing about mail from a vendor mailbox an attacker controls. Those messages authenticate because they are authentic.
So the process control stays. Any change to banking details is verified by a second person calling a number from the contract file rather than from the message, with a notice to the previously known contact. On the inbound side, confirm your mail platform honors other senders' DMARC policies, mark external senders visibly, and alert on mailbox rules that auto-forward or auto-delete.
Three questions are enough to start. Does the domain publish a DMARC policy, and at what setting. Who reads the aggregate reports. Can accounts payable change a bank account on the strength of an email alone. If nobody owns the answers, that is the first assignment.