SPF, DKIM, and DMARC: The Complete Guide for Business Owners

Back to Blog

Your company's email domain is one of your most valuable digital assets — and one of the most commonly abused. Without proper authentication records in your DNS, anyone on the internet can send email that appears to come from your domain. A phishing email that looks exactly like it came from your CEO's address, an invoice fraud attempt appearing to originate from your accounting department, a spoofed support email that harvests customer credentials — all of these are trivially easy to execute against an unprotected domain.

SPF, DKIM, and DMARC are the three DNS-based email authentication standards that prevent this. They are not optional niceties — since 2024, Google and Yahoo have required DMARC compliance for bulk senders, and enterprise email gateways increasingly reject or quarantine mail from unauthenticated domains regardless of sending volume. This guide explains what each protocol does in plain language, how they work together, and how to implement them correctly without breaking your email delivery.

SPF: Who Is Authorized to Send from Your Domain

Sender Policy Framework (SPF) answers a simple question: which mail servers are authorized to send email claiming to be from my domain?

You publish an SPF record as a DNS TXT record on your domain. When a receiving mail server gets a message claiming to be from you, it looks up your SPF record and checks whether the sending server's IP address is listed. If it is, SPF passes. If it isn't, SPF fails.

A typical SPF record for a Microsoft 365 customer:

Breaking this down: v=spf1 declares this is an SPF record. include:spf.protection.outlook.com authorizes all of Microsoft's Exchange Online sending infrastructure. -all is a hard fail — any server not explicitly authorized should be rejected.

If you also send email through a marketing platform (Mailchimp, Constant Contact, HubSpot), your CRM, or a ticketing system, each of those services needs to be included in your SPF record:

Critical SPF limitation: SPF only checks the envelope sender (the MAIL FROM address used during the SMTP transaction), not the From: header that users actually see. This is why SPF alone is insufficient — an attacker can send spoofed mail with a legitimate From: header while using a domain they control as the envelope sender, and SPF will pass.

DKIM: Cryptographic Proof That Mail Was Not Tampered With

DomainKeys Identified Mail (DKIM) solves a different problem: it proves that a message genuinely originated from your organization and was not modified in transit. DKIM works using public-key cryptography.

When your mail server sends a message, it generates a cryptographic signature of the message content and certain headers, using a private key that only your server knows. This signature is added to the message as a DKIM-Signature header. You publish the corresponding public key in your DNS as a TXT record. When a receiving server gets the message, it retrieves your public key from DNS and uses it to verify the signature. If the signature is valid, the message has not been tampered with and genuinely originated from a server in possession of your private key.

A DKIM DNS TXT record is published at the selector subdomain of your domain. For Microsoft 365, after enabling DKIM signing in the Exchange Admin Center, the records look like:

Microsoft manages the key rotation automatically when you use their CNAME-based DKIM setup, which is the recommended approach for M365 customers.

DKIM limitation: DKIM signs the message but does not specify what should happen when verification fails. A message with a broken or missing DKIM signature might still be delivered — the receiving server makes its own judgment. DKIM tells the receiving server something useful, but it doesn't give your domain any enforcement authority over how that information is used.

DMARC: Policy and Reporting That Ties It Together

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is the policy layer that tells receiving mail servers what to do with messages that fail SPF or DKIM — and critically, it fixes the alignment problem that makes SPF insufficient on its own.

DMARC requires that the domain in the From: header (the one users see) aligns with either the domain that passed SPF or the domain that signed the DKIM signature. An attacker cannot pass DMARC by using a legitimate envelope sender while spoofing your From: header — DMARC requires that the authenticating domain matches your visible From: domain.

A basic DMARC record:

Breaking this down:

• v=DMARC1 — declares this as a DMARC record.
• p=none — the policy: none means "monitor only, take no action." Also available: p=quarantine (send to spam) and p=reject (discard the message).
• rua=mailto:... — aggregate report destination. Receiving servers send daily XML reports showing authentication results for all mail claiming to be from your domain.
• ruf=mailto:... — forensic report destination. Receiving servers (those that support it) send individual failure reports for each message that fails DMARC.
• fo=1 — forensic report options. "1" means send a forensic report if either SPF or DKIM fails (not just when both fail).

DMARC Reporting: Aggregate vs. Forensic

Aggregate reports (RUA) are XML files sent daily by participating mail receivers (Google, Microsoft, Yahoo, and most enterprise gateways). They summarize all mail claiming to be from your domain: how many messages passed or failed SPF and DKIM, from which IP addresses, and with what DMARC disposition. Aggregate reports are invaluable for discovering unauthorized services sending email on your domain's behalf. They are also the source of truth for validating that your SPF and DKIM configuration is working correctly before you escalate DMARC policy.

Forensic reports (RUF) are individual failure reports — message-level data on each email that failed DMARC. They can include the actual message headers and sometimes partial message content. Forensic reports carry privacy implications and are not universally sent by all receivers. Some privacy-conscious receivers (notably the major European providers) have stopped sending forensic reports entirely.

Aggregate reports are best consumed through a DMARC reporting platform (dmarcian, Postmark DMARC, Valimail, or similar) that parses the XML and presents trends in readable form. Raw DMARC XML is not human-readable in any practical sense.

The Policy Progression: None → Quarantine → Reject

The correct approach to DMARC is a gradual progression that avoids breaking legitimate mail before you understand everything sending from your domain:

1. Start at p=none (monitor only). Collect aggregate reports for at least 2–4 weeks. Use reporting to identify all legitimate sending sources: your primary mail server, marketing platforms, CRM, ticketing system, cloud applications, copiers, anything sending as your domain.
2. Fix SPF and DKIM for all legitimate sources. Add every legitimate sender to your SPF record. Enable DKIM signing for every service that supports it. Verify in aggregate reports that all legitimate sources are passing both SPF and DKIM with DMARC alignment.
3. Escalate to p=quarantine once aggregate reports show only legitimate sources, and all legitimate sources are passing. Quarantine sends failing mail to spam/junk rather than rejecting it outright. Monitor for 1–2 weeks to catch anything you may have missed.
4. Escalate to p=reject. This is the goal state. Receiving servers are instructed to discard any mail claiming to be from your domain that fails DMARC. Spoofed email using your domain is effectively neutralized.

Common Mistakes That Break Email Delivery

Too many DNS lookups in SPF. SPF allows a maximum of 10 DNS lookups during evaluation. Each include: mechanism counts as one lookup, and those includes can chain to additional lookups. Exceeding 10 lookups causes SPF to return a PermError, which DMARC treats as an SPF failure. Use an SPF flattening tool to stay within the limit.

Multiple SPF records on the same domain. You can only have one SPF TXT record per domain. If a second SPF record is added (perhaps by a different administrator or a third-party service), SPF evaluation fails entirely. Merge all mechanisms into a single record.

Using -all before discovery is complete. Publishing -all in your SPF record before you've identified all legitimate senders causes legitimate mail from undiscovered sources to fail. Start with ~all (soft fail) during the discovery phase.

Forgetting subdomain policy in DMARC. Your DMARC record at _dmarc.yourcompany.com covers your main domain but subdomains are covered separately with the sp= tag. If you send email from subdomains (newsletters.yourcompany.com, support.yourcompany.com), ensure those subdomains have their own authentication configuration or that the subdomain policy in your parent DMARC record covers them appropriately.

DKIM key length below 1024 bits. DKIM keys below 1024 bits are considered cryptographically weak and are rejected by some receivers. Use 2048-bit keys where your provider supports them.

How IT Center Manages Email Authentication

IT Center configures and manages SPF, DKIM, and DMARC for Southern California businesses as part of our email security services. We conduct a full sending source discovery, build and consolidate SPF records within lookup limits, enable DKIM on all sending platforms, configure DMARC at p=none with reporting, monitor aggregate reports until ready, and manage the policy escalation to p=reject. We also manage the ongoing DNS hygiene as new services are added — ensuring your email authentication stays current as your business adds cloud tools. Businesses using IT Center's business email services receive authentication configuration as a standard included service.