Set Up SPF, DKIM, and DMARC to Stop Spoofing Without Blocking Real Mail

## Decide Who Approves Email DNS Changes and How to Undo Them Treat email authentication as shared infrastructure. A record change can affect transactional mail, support systems, marketing, internal tools, and third parties that use the same domain. - Identify the sending domains, subdomains, visible From domains, and business-critical mail streams in scope. - Name an accountable domain owner and authorized DNS operator. - Separate who proposes, reviews, approves, publishes, validates, and monitors each change. - Record the current DNS values, time to live, dependencies, and a tested rollback value. - Schedule changes when owners of critical streams can observe results. - Do not edit production DNS without explicit authorization and a recovery plan. - Pause escalation when the sender inventory or ownership evidence is incomplete. ## List Every Service That Sends Email from Your Domain Build the sender inventory before writing authentication records. Missing one legitimate service can cause policy enforcement to block wanted mail, while obsolete authorization enlarges the spoofing surface. - List each platform, application, relay, device, and vendor that sends using the domain. - Record its envelope sender, visible From domain, signing domain, IP ownership, and responsible team. - Distinguish direct senders from forwarding, mailing-list, and gateway paths. - Note which sources can sign with DKIM and which depend on SPF alignment. - Remove retired sources only after confirming they no longer send legitimate traffic. - Consider isolating distinct risk or ownership groups on dedicated subdomains. - Keep the inventory linked to change records and authentication reports. ## Write One Correct SPF Record That Covers All Senders SPF authorizes the systems allowed to use a domain in the envelope sender. It evaluates the connecting source; it does not sign content and does not by itself authenticate the visible From address. - Publish exactly one SPF policy for each hostname that needs one. - Combine all legitimate senders into that policy instead of creating duplicate SPF records. - Use only mechanisms and includes supported by the responsible sending services. - Keep DNS-querying mechanisms within the SPF limit of 10 during evaluation. - Remove redundant includes and unused senders before approaching the limit. - Choose the final all-mechanism deliberately and tighten it only after coverage is proven. - Validate syntax, expansion paths, lookup count, and results from representative senders. ## Turn On DKIM Signing for Each Sending Service DKIM lets a sender sign selected message content with a private key while receivers retrieve the matching public key from DNS. A passing signature shows that signed content survived transit and identifies the signing domain. - Generate a separate selector and key pair according to each sender's supported method. - Prefer strong keys, such as 2048-bit keys, when both the sender and DNS service support them. - Publish the exact public-key record at the selector location specified by the sender. - Protect private keys and never place them in DNS, tickets, shared documents, or logs. - Enable signing only after the public record resolves correctly. - Send a real test and verify the selector, signing domain, signature result, and header coverage. - Plan selector-based key rotation so a new key can be proven before the old key is retired. ## Start DMARC in Monitor-Only Mode and Read Its Reports DMARC evaluates whether the visible From domain aligns with a passing SPF or DKIM identity, then applies the domain owner's published policy. Authentication success without alignment may still fail DMARC. - Confirm that each legitimate stream aligns through SPF, DKIM, or both. - Understand whether relaxed or strict alignment fits the domain structure and risk. - Publish a DMARC record at the required policy hostname with an authorized reporting destination. - Begin with a monitoring policy while discovering legitimate and unauthorized sources. - Protect report mailboxes and limit access because reports can reveal infrastructure details. - Classify failures by source, authentication result, alignment, volume, and business owner. - Do not move to enforcement until important legitimate streams are accounted for. ## Tighten DMARC Step by Step Without Blocking Real Mail Move from observation to quarantine and rejection only when evidence shows that legitimate mail remains aligned. Enforcement is a risk-control decision, not a one-time DNS formatting task. - Define pass-rate, unknown-source, and business-impact criteria for each stage. - Remediate legitimate failures before increasing policy severity. - Use a limited enforcement percentage when supported and useful for risk reduction. - Monitor aggregate reports, delivery errors, support incidents, and critical stream health after each change. - Keep a documented rollback policy ready throughout the transition. - Obtain accountable approval before increasing enforcement or changing alignment mode. - Stop and investigate if legitimate mail is rejected, quarantined, or unexpectedly unauthenticated. ## Check DNS Records and Real Test Emails After Every Change Confirm both record publication and actual mail behavior. A syntactically valid DNS record is not proof that every sender uses it or that DMARC alignment succeeds. - Query authoritative DNS for SPF, DKIM selectors, and DMARC after propagation. - Check for duplicate records, truncated values, wrong hostnames, and unintended inherited policies. - Send tests through every representative production path to multiple receiving environments. - Inspect message headers for SPF, DKIM, DMARC, domains, selectors, and alignment results. - Test both ordinary messages and important variants such as forwarded or relayed mail. - Record the test path, timestamp, result, evidence, and reviewer. - Repeat validation after any sender, DNS, routing, or signing change. ## Find the Cause of SPF, DKIM, or DMARC Failures from Evidence Diagnose from authentication results, DNS responses, message headers, and change history. Do not keep editing records until a test passes by accident. - For SPF permanent errors, inspect duplicate policies, syntax, recursive includes, and the 10-lookup limit. - For DKIM failures, inspect selector names, copied key material, signing status, canonicalization, and message modification. - For DMARC failures, compare the visible From domain with SPF and DKIM identities. - For blocked legitimate mail, identify the exact source before relaxing policy. - Roll back the smallest responsible change when a production stream is harmed. - Retest the failing path and an unaffected control path after each correction. - Preserve evidence of the cause and fix for future changes. ## Watch Bounces and Spam Placement, Not Just Authentication Results SPF, DKIM, and DMARC reduce identity abuse and satisfy important receiver checks, but they do not guarantee inbox placement. Reputation and recipient response remain separate signals. - Monitor authentication pass rates together with rejections, deferrals, spam placement, complaints, and bounces. - Maintain accurate recipient lists and remove invalid or persistently failing addresses. - Keep volume and sending patterns consistent with the domain's established reputation. - Use honest sender identity, relevant content, and a clear way to stop nonessential mail. - Investigate sudden changes by domain, stream, receiver, content, and deployment event. - Avoid treating warm-up activity or a passing authentication check as proof of healthy reputation. - Pause risky streams when evidence shows continuing harm. ## Review Senders and Rotate DKIM Keys on a Regular Schedule Authentication degrades when services change, keys age, owners leave, or new senders bypass review. Maintain it as a recurring control rather than a completed setup project. - Review sender inventory, DNS records, DMARC reports, and ownership on a defined cadence. - Rotate DKIM selectors and keys using an overlap period that preserves valid signatures. - Revalidate SPF lookup count whenever an include or sending service changes. - Track policy changes, approvals, published values, validation evidence, and rollback outcomes. - Alert on new sources, falling pass rates, missing reports, and sudden alignment failures. - Remove obsolete authorization after confirming the related stream is inactive. - Reassess subdomain boundaries and enforcement as risk, volume, or business use changes.