Email Security Beyond Spam Filters: DMARC, DKIM, SPF

SPF (Sender Policy Framework) is a DNS TXT record that lists which mail servers are allowed to send email on behalf of your domain. If a message arrives claiming to be from yourdomain.com but originates from a server not on that list, receiving mail systems can flag or reject it.

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to outgoing messages, tied to a public key published in your DNS. The receiving server checks that signature against the key. If the message was altered in transit, or the signature doesn't match, it fails verification.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties the two together. It tells receiving mail servers what to do when a message fails SPF or DKIM checks — quarantine it, reject it outright, or do nothing but report the failure back to you. Without DMARC, SPF and DKIM exist but nobody's actually enforcing them.

Credential abuse shows up in some form in 39% of breaches, according to the Verizon 2026 Data Breach Investigations Report. A lot of that starts with a convincing spoofed email that gets an employee to hand over a password or approve a fraudulent wire. Spam filtering evaluates content. It's not built to answer the question "is this sender who they claim to be." That's exactly the question SPF, DKIM, and DMARC are designed to answer, and it's why they're standard line items in serious email security audits now, not optional extras.

Here's the sequence we walk clients through, in order, because doing it out of order is how you end up blocking your own legitimate mail.

• Inventory every sending source first. Before touching DNS, list every system that sends mail as your domain — your mail server, Mailchimp, Salesforce, your accounting software, your phone system's fax-to-email gateway. Miss one and DMARC enforcement will silently drop their mail.
• Publish SPF, but watch the 10-lookup limit. SPF records can only perform 10 DNS lookups during validation. Companies that stack Google Workspace, a CRM, a marketing platform, and a helpdesk tool into one SPF record often blow past that limit without realizing it, which causes SPF to fail entirely — a "permerror" that some receivers treat as a hard fail.
• Turn on DKIM signing for every sending platform. Most platforms (Microsoft 365, Google Workspace, Constant Contact, HubSpot) support DKIM but don't enable it by default. Each one needs its own selector and key published in your DNS.
• Start DMARC at p=none. This monitoring-only mode does nothing to your mail flow. It just generates aggregate reports (sent to an address you specify via the rua tag) showing you what's passing and what's failing, and from where. Run this for at least two to four weeks.
• Read the reports before moving to enforcement. DMARC aggregate reports arrive as XML files that are genuinely hard to read raw. Use a free parsing tool or a paid DMARC monitoring service to turn them into something readable. Look for legitimate sources failing authentication — that's your cleanup list.
• Move to p=quarantine, then p=reject. Once your legitimate senders are all passing, tighten the policy. Quarantine sends failures to spam/junk folders. Reject blocks them outright. Reject is the goal, but jumping there without the monitoring phase is how companies accidentally block invoices from their own bank.

The most common failure is a business that sets up SPF and DKIM correctly, then never publishes a DMARC record at all — or publishes one at p=none and leaves it there indefinitely. Monitoring mode with nobody reading the reports gives you zero enforcement and a false sense of coverage.

Second most common: forgetting subdomains. A DMARC policy on yourdomain.com doesn't automatically cover mail.yourdomain.com or a subdomain a marketing team spun up for a campaign, unless you explicitly configure the subdomain policy (the "sp" tag) to match.

Third: not adjusting SPF and DKIM when switching email providers or adding a new sales tool. We've seen companies migrate from an on-premise Exchange server to Microsoft 365 and forget to update SPF, which means legitimate mail starts failing checks the day after the migration.

Texas SB 2610, effective September 1, 2025, shields businesses with 20 to 99 employees from exemplary damages in a data breach lawsuit if they've implemented the CIS Controls Implementation Group 1 safeguard set — 56 specific controls. Email authentication practices like enforcing SPF, DKIM, and DMARC fall squarely into the kind of basic hygiene those safeguards cover. The law doesn't create a new lawsuit right or guarantee you won't get sued; it caps a specific category of damages if you can show you did the baseline work. Locking down email authentication is one of the more straightforward, low-cost pieces of that baseline.

It also matters because ransomware recovery costs, when you exclude any ransom payment, run at a median of $375,000 according to Sophos's 2026 State of Ransomware report — a stat pulled up further by a smaller number of very expensive incidents. A lot of ransomware still starts with a phishing email that a spoofed sender made look legitimate. DMARC enforcement doesn't stop every attack, but it closes off one of the more common entry points cheaply.

A properly configured setup, for most Texas small and mid-sized businesses, means: SPF published and under the lookup limit, DKIM signing active on every platform that sends mail as your domain, and a DMARC policy at p=reject with aggregate reporting still turned on so you catch problems before they become outages. It's not a one-time project. New SaaS tools get added, marketing platforms change, and each one needs to be folded into the authentication setup or it'll either fail silently or open a gap.

Will DMARC block emails my employees send to each other?

No. DMARC evaluates mail based on the sending domain against published DNS records. Internal mail through your normal, properly configured mail server will pass. Problems only show up when a sending source isn't accounted for in your SPF or DKIM setup.

How long does full implementation typically take?

The DNS changes themselves take minutes. The monitoring period before you can safely move to enforcement usually runs two to six weeks, depending on how many sending platforms you have and how quickly you can clean up the legitimate sources showing up as failures in your reports.

Do I need DMARC if I already use Microsoft 365 or Google Workspace?

Yes. Those platforms handle spam filtering and can sign your outbound mail with DKIM, but they don't automatically publish a DMARC policy that tells other mail servers what to do with failures. That configuration is on you.

What happens if I set DMARC to reject too early?

Legitimate email from any sending source you didn't account for — a CRM, a marketing tool, a fax gateway — will get rejected outright, and the sender usually gets a bounce with no clear explanation. That's why the monitoring phase at p=none matters before tightening the policy.

If your domain has never had a DMARC record, start by publishing one at p=none and setting up an inbox to collect the aggregate reports. That single step, done today, starts generating visibility into who's sending mail as your company — and that visibility is the foundation everything else builds on.