Most domains on the internet still let anyone send email that looks like it came from them. That gap is why a vendor-impersonation email or a fake invoice from “your CEO” keeps landing in inboxes in 2026, even at companies that run modern endpoint protection and a full cybersecurity stack. The fix isn’t a product you buy. It’s three DNS records: SPF, DKIM, and DMARC. This tutorial walks through setting up all three from scratch, in 13 steps, with the exact DNS syntax, the rollout order that won’t break your mail flow, and the troubleshooting steps for when a sender you forgot about suddenly stops delivering.
Why Email Spoofing Still Costs Businesses Millions in 2026
Email authentication has had a decade to become standard practice, and the data says it still isn’t. According to Fortra’s Q2 2025 Global DMARC Adoption Trends report, out of 10 million domains analyzed, “Among 10 million domains analyzed in Q2 2025, 36.7% published a syntactically valid SPF record, while 61.9% had no SPF record.” That means roughly six out of ten domains have zero baseline protection against someone sending mail that claims to be from them. DMARC adoption looks even thinner: Fortra found that “Among 10 million domains analyzed in Q2 2025, 18.2% had a valid DMARC record, and only 7.6% had an enforcement policy using quarantine or reject.” Publishing a record isn’t the same as enforcing it, and that distinction is where most of the real-world spoofing risk lives.
There is movement in the right direction. Mailgun’s 2025 State of Email Deliverability report found that “In 2024, 53.8% of surveyed email senders reported using DMARC for email authentication, up from 42.6% in 2023,” a jump largely driven by Google and Yahoo’s bulk-sender requirements that took effect in February 2024. EasyDMARC’s 2025 adoption report tracked similar growth among the web’s most visited sites, noting that “DMARC adoption among the top domains increased from 27.2% in 2023 to 47.7% in 2025, a 75% increase in protected domains.” Adoption is rising, but enforcement, the setting that actually blocks a spoofed message instead of just logging it, is still rare. Fortra’s research puts hard enforcement at just 3.9% of the top 10 million domains once subdomains are included.
That enforcement gap matters more this year because the volume of exploitable software flaws keeps climbing in parallel. Microsoft’s October 2026 Patch Tuesday shipped fixes for a record 1,413 vulnerabilities, and attackers routinely pair a software exploit with a convincing spoofed email to get the first click. If your domain has no DMARC enforcement, anyone can send a message that appears to come from your finance team, your IT helpdesk, or your own CEO, and most mail clients will show it without a warning. Fixing that doesn’t require a new vendor contract. It requires three text records in your DNS zone, set up correctly and in the right order.
Business email compromise follows a predictable pattern once a domain is unprotected: an attacker registers a lookalike domain or simply spoofs the real one, drafts a message that mimics an internal approval chain or a known vendor’s invoice format, and times it around payroll, quarter-end, or a wire transfer window. The same spoofed-email technique is also how a lot of credential theft starts in the first place, the kind of leaked API key or token that tools like TruffleHog and Gitleaks exist to catch after the fact. None of that requires breaching your network. It only requires that the receiving mail server have no way to tell the difference between a message your mail server actually sent and one that merely claims to be from you. SPF, DKIM, and DMARC exist specifically to close that gap, and because they’re DNS records rather than software, there’s nothing to install, patch, or license. The work is almost entirely in the audit and rollout discipline covered in the steps below, not in the DNS syntax itself.
SPF vs DKIM vs DMARC: What Each Protocol Actually Checks
These three protocols get lumped together constantly, but they check different things and fail in different ways. SPF (Sender Policy Framework) is a DNS record that lists which mail servers are authorized to send for a domain. A receiving server checks the envelope sender address, the one in the hidden Return-Path header, against that list. DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each outgoing message, letting the receiver confirm the message wasn’t altered in transit and that it really came from a server holding the matching private key. DMARC (Domain-based Message Authentication, Reporting, and Conformance) sits on top of both. It checks whether the visible “From:” address a human actually sees lines up with the domain that passed SPF or DKIM, and it tells the receiving server what to do when that check fails: do nothing, send it to spam, or reject it outright. DMARC also generates reports, which is the part most tutorials skip and the part that actually tells you whether your setup is working.
The reason all three exist separately, instead of being one protocol, comes down to what each one can survive. SPF breaks the moment a message gets forwarded through a third party, because the envelope sender changes at each hop. DKIM survives forwarding better since the signature travels with the message body, but it breaks if anything along the way rewrites the subject line, adds a footer, or otherwise touches the signed content. DMARC was built to route around both weaknesses at once: as long as either SPF or DKIM passes and aligns with the visible From: domain, the message authenticates. That “either/or” design is why a mature setup runs both protocols rather than picking one, even though DMARC technically only requires one of them to succeed.
| Protocol | What it verifies | Where it’s published | What breaks it |
|---|---|---|---|
| SPF | Which IP addresses may send on behalf of a domain | TXT record at the root/sending domain | Exceeding 10 DNS lookups; publishing more than one SPF record; message forwarding that changes the envelope sender |
| DKIM | Message integrity and signer identity via a cryptographic signature | TXT record at a selector subdomain, e.g. selector1._domainkey.example.com | Key rotation without updating DNS; mailing lists or gateways that modify message body/headers in transit |
| DMARC | Alignment between the visible From: domain and the domain that passed SPF or DKIM, plus policy enforcement | TXT record at _dmarc.example.com | Publishing p=reject before confirming all legitimate senders pass; missing subdomain policy; syntax errors in the record |
Prerequisites: Tools, Access, and Versions You’ll Need
Before touching a single DNS record, get the following lined up. Skipping this step is the single biggest reason SPF/DKIM/DMARC rollouts turn into outages.
- DNS zone edit access at your registrar or DNS host, with TXT record support and a published change log or ticketing process
- Admin access to every platform that sends mail for your domain: Google Workspace Admin Console or Microsoft 365 / Exchange Admin Center, plus any transactional ESP (SendGrid, Mailgun, Postmark, Amazon SES) and marketing platform (Mailchimp, HubSpot, Klaviyo)
- A command line with dig (BIND utilities 9.18 or later) or nslookup for verifying records after you publish them
- A DMARC aggregate-report analyzer. Free tiers from EasyDMARC, dmarcian, or URIports are enough to start; you do not need an enterprise contract for the monitoring phase
- 2048-bit RSA as your DKIM key length target. Current guidance treats 1024-bit keys as legacy-compatibility only, not a default choice
- A dedicated mailbox or inbox rule to receive DMARC aggregate reports (rua) without it getting lost in a shared inbox
- A 2 to 4 week calendar window for the monitoring phase before you touch enforcement. Enterprises with multiple sending vendors should plan for 6 to 8 weeks
None of this requires a security budget. The DNS records themselves cost nothing to publish, dig and nslookup ship with every major operating system or Linux distribution, and the analyzer tools listed above all offer a free tier that covers a single domain’s monitoring needs. The only real cost is time, specifically the time spent on Step 1 and Step 2 below, since an incomplete sender inventory is what turns a routine DMARC rollout into an outage three weeks later.
Phase 1: Lock Down SPF (Steps 1-4)
Step 1: Audit Your Email-Sending Infrastructure
List every system that sends mail using your domain in the From: address. This is almost always more than IT remembers off the top of their head. Common blind spots include marketing automation platforms, the CRM’s automated receipts, a help desk tool like Zendesk or Freshdesk, billing and invoicing software, scanner/MFP devices that email scanned documents, and internal scripts or cron jobs that send alerts. Pull this list from three sources at once: ask every department head directly, read the include: statements already in your current SPF record if one exists, and review 90 days of outbound SMTP relay logs if your mail platform keeps them. Cross-referencing all three catches senders that only appear in logs, not in anyone’s memory.
Step 2: Build a Complete Sender Inventory
Turn the audit into a living spreadsheet or table with columns for sender name, business purpose, sending IP range or SPF include domain, DKIM signing capability, business owner, and current authorization status. This becomes the source of truth for every SPF and DKIM change going forward, and it’s the document an auditor or new hire will actually thank you for. Keep it current; stale inventories are the root cause behind most of the pitfalls later in this guide.
Step 3: Write and Publish Your SPF Record
Publish a single TXT record at the root of your sending domain. A typical record looks like this:
example.com. IN TXT "v=spf1 ip4:192.0.2.10 include:_spf.google.com include:sendgrid.net -all"The v=spf1 tag identifies the record type and must come first. Each include: mechanism authorizes a vendor’s published sender list. The qualifier at the end controls what happens to mail from anything not listed: -all is a hard fail (tell the receiver to reject it), ~all is a soft fail (mark it suspicious but usually still deliver), and ?all is neutral (no real opinion). Start with ~all while you confirm your sender inventory is complete, then switch to -all once DMARC reports (covered in Phase 3) confirm nothing legitimate is missing. Only one SPF TXT record is allowed per domain; publishing a second one causes a permanent SPF error for every sender, including the legitimate ones. Verify the record resolves correctly:
$ dig TXT example.com +short
"v=spf1 ip4:192.0.2.10 include:_spf.google.com include:sendgrid.net -all"Step 4: Fix the SPF 10-Lookup Limit
SPF allows a maximum of 10 DNS lookups per check. Every include:, a, mx, exists, and redirect mechanism counts toward that limit, and nested includes (a vendor’s SPF record that itself includes other vendors) count too. Exceeding it produces a permanent error, and the practical effect is brutal: SPF fails for every sender on the domain, not just the one that pushed the count over, because receiving servers stop evaluating the record once the limit is hit. This is the most common reason a legitimate SPF rollout silently breaks months after launch, usually after a new marketing tool gets added without anyone checking the lookup count.
Fix it by removing unused or redundant include: statements, consolidating multiple similar vendors into fewer authorized senders, and replacing deeply nested vendor includes with direct ip4/ip6 ranges where a vendor publishes them. Treat any third-party SPF-flattening service as an added maintenance dependency rather than a permanent fix, since it introduces a new system that needs its own monitoring. A record that looked like this:
# Before: 12 effective lookups -- over the limit
"v=spf1 include:_spf.google.com include:sendgrid.net include:mailchimp.com
include:salesforce.com include:_spf.hubspot.com include:amazonses.com -all"can usually be brought under the limit by retiring vendors nobody uses anymore and flattening one or two of the heaviest nested includes into direct IP ranges, landing closer to 6 or 7 effective lookups with real headroom for future additions.
Phase 2: Deploy DKIM Signing (Steps 5-6)
Step 5: Generate and Publish DKIM Keys
Most mail platforms (Google Workspace, Microsoft 365, SendGrid, Mailgun) generate the DKIM key pair for you and hand you the public key and selector to publish; you rarely generate raw keys by hand unless you’re running your own mail transfer agent. If you are managing keys directly, generate a 2048-bit RSA pair like this:
openssl genrsa -out dkim_private_2026.pem 2048
openssl rsa -in dkim_private_2026.pem -pubout -out dkim_public_2026.pemPublish the public key as a TXT record under a selector name, which acts as a label letting receivers find the right key among multiple that may exist over time:
sel2026._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."The sending server attaches a DKIM-Signature header to every outgoing message, referencing d=example.com and s=sel2026 so the receiver knows which domain and selector to check against. Current guidance recommends 2048-bit RSA as the standard; 1024-bit keys remain acceptable only for compatibility with older systems that can’t handle the longer key.
Step 6: Verify DKIM Signing and Set a Rotation Schedule
Send a test message to an address you control and inspect the raw message source for the DKIM-Signature header, confirming the d= and s= values match what you published, and that the receiving server’s own authentication results header reports dkim=pass. Most ESPs also expose a DKIM status indicator directly in their admin console once the DNS record propagates.
Rotate DKIM keys on a schedule rather than leaving one key in place indefinitely. Current guidance calls for rotating DKIM keys at least every six months, and sooner if you suspect a private key has been exposed. When rotating, publish the new selector’s public key alongside the old one for a short overlap window, since messages signed before the switch may still be in transit or queued, and you don’t want them failing validation on arrival.
Phase 3: Roll Out DMARC From Monitoring to Enforcement (Steps 7-10)
Step 7: Launch DMARC in Monitoring Mode
Publish your first DMARC record at p=none. This does not block or quarantine anything; it only turns on reporting so you can see, in practice, which senders pass and which ones you forgot about.
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100"v=DMARC1 must be the first tag in the record, or receivers will ignore it entirely. rua tells receiving mail providers where to send daily aggregate reports. pct=100 at this stage simply means the policy (currently “do nothing”) applies to all mail; it has no enforcement effect while p=none. This record alone also satisfies the baseline DMARC requirement in Google and Yahoo’s bulk-sender rules, covered in detail later in this guide.
Step 8: Read Aggregate Reports and Fix Senders
Aggregate reports arrive as gzip-compressed XML files, typically once a day, from every major receiving provider that got mail claiming to be from your domain. Each report breaks results down by source IP and shows pass/fail counts for SPF and DKIM alignment. Reading raw XML by hand doesn’t scale past a handful of reports a day, which is why a free analyzer tier (EasyDMARC, dmarcian, URIports) is worth setting up before you need it. A simplified view of what you’re looking for:
Source IP Messages SPF DKIM Disposition
198.51.100.44 4,210 pass pass none
203.0.113.9 312 fail fail none <-- unidentified sender, investigate
192.0.2.10 18,004 pass pass noneAny source IP showing consistent fail results needs one of two outcomes: either it’s a legitimate sender missing from your SPF/DKIM setup, which you add using your sender inventory from Step 2, or it’s an unauthorized source, which confirms exactly why you’re doing this rollout in the first place. Keep monitoring until two to three consecutive weeks show zero unexplained failures before moving to the next step.
Step 9: Move to Quarantine
Once reports are clean, move to p=quarantine, starting at a partial percentage so a misconfiguration only affects a slice of mail rather than all of it:
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com"Quarantine tells receivers to route failing mail to spam rather than the inbox, instead of rejecting it outright. Watch reports for another one to two weeks at pct=25, then raise to 50, then 100, watching for any new failures at each step before increasing further.
Step 10: Enforce Reject
With pct=100 at quarantine clean for at least a week, move to the policy that actually stops spoofed mail from reaching a recipient’s inbox at all:
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensics@example.com"ruf requests forensic (per-message) failure reports, though many receiving providers restrict or redact forensic report content for privacy reasons, so treat aggregate reports as your primary signal and forensic reports as a bonus when they arrive. Don’t jump from p=none directly to p=reject. Fortra’s research found that only 3.9% of the top 10 million domains enforce reject even including subdomains, and the staged pct rollout above is exactly why: it catches a forgotten sender before it becomes a full outage instead of after.
Step 11: Add BIMI for Logo Display in Inboxes
BIMI (Brand Indicators for Message Identification) displays your logo next to authenticated emails in supporting inboxes. It’s optional, but it’s a visible payoff for doing the enforcement work above, and it requires that work as a prerequisite. Most participating providers require DMARC enforced at p=quarantine or p=reject, generally at pct=100, plus an SVG logo file, and for Gmail specifically, a Verified Mark Certificate (VMC) issued by an authorized certificate authority to confirm the logo matches a registered trademark. Publish the BIMI record at a dedicated selector:
default._bimi.example.com. IN TXT "v=BIMI1; l=https://example.com/brand/logo.svg; a=https://example.com/brand/vmc.pem"If your organization doesn’t send enough consumer-facing mail to justify a VMC purchase, skip BIMI for now; it has zero effect on deliverability or spoofing protection and is purely a brand-visibility add-on once the authentication work above is already done.
Step 12: Automate Ongoing DMARC Monitoring
Enforcement is not a one-time setting. Set a recurring review of aggregate reports: weekly during the first month after reaching p=reject, then monthly as a standing calendar item. Configure your analyzer tool’s alerting so a brand-new, unauthorized sending source triggers a notification instead of waiting for the next manual review. Re-audit your sender inventory from Step 2 every quarter, since marketing and sales teams add new SaaS tools more often than IT gets told about it, and a new unauthorized sender is exactly the kind of gap that quietly breaks DMARC enforcement months later.
Step 13: Document and Hand Off the Setup
Write a short runbook covering: where each DNS record lives and who has edit access, the current DKIM selector name and its last rotation date, login details for the report analyzer, who gets paged if reports show a spike in failures, and a change log of every policy adjustment with dates. This is the step most guides skip, and it’s the reason configurations get forgotten two years later when the person who set it up has moved teams. A domain’s SPF, DKIM, and DMARC setup should survive staff turnover, not depend on one person’s memory.
Google and Yahoo’s Bulk Sender Rules for 2026
Google and Yahoo’s bulk-sender requirements, which took effect in February 2024, are the biggest reason DMARC adoption has climbed over the past two years, and they remain in force through 2026 largely unchanged. Both providers use a 5,000-messages-per-day threshold, measured against mail delivered to their own users specifically, not your total global sending volume. Cross the threshold to either provider and the rules below apply.
| Requirement | Yahoo | |
|---|---|---|
| Bulk-sender threshold | 5,000 msgs/day to Gmail accounts | 5,000 msgs/day to Yahoo accounts |
| SPF and DKIM | Both required | Both required |
| Minimum DMARC policy | p=none is sufficient to comply | p=none is sufficient to comply |
| Spam complaint rate cap | Below 0.3% | Below 0.3% |
| One-click unsubscribe | Required for marketing mail | Required for marketing mail |
Note the gap: both providers only require p=none to be technically compliant, which is why so many domains stop at monitoring mode and never move to enforcement. As Courier’s sender-requirements guide and PowerDMARC’s 2026 breakdown of the rules both note, meeting the bulk-sender bar and actually stopping spoofing are two different projects. Compliance gets you a DMARC record. Enforcement, p=quarantine or p=reject, is what stops an attacker from sending a convincing fake invoice that appears to come from your domain.
Choosing a DMARC Report Analyzer
Reading raw aggregate-report XML is realistic for a single domain with a handful of senders. Past that, a dashboard tool pays for itself in saved time almost immediately. The free tiers from EasyDMARC, dmarcian, and URIports are what most teams reach for during the monitoring phase, and all three parse incoming rua reports automatically, group results by sending source, and flag unauthorized senders without requiring anyone to open a single XML file by hand.
| Tool | Good fit for | Free tier covers |
|---|---|---|
| EasyDMARC | Small to mid-size teams running their first rollout | Single domain, aggregate report parsing, basic SPF/DKIM record checks |
| dmarcian | Teams that want longer-standing community tooling and documentation | Single domain, aggregate reports, record syntax validation |
| URIports | Teams that also want broader DNS and TLS reporting alongside DMARC | Limited report volume per domain, dashboard view of senders |
Pick one before you publish your first p=none record, not after reports start piling up in a mailbox nobody checks. Switching analyzers later is painless since they all just read the same standard rua reports, so there’s no lock-in risk to trying the free tier first.
Common Pitfalls That Break SPF, DKIM, and DMARC
Most of the mistakes below don’t show up as an obvious error message. They show up weeks later as a vendor’s mail quietly landing in spam, or as a sender nobody remembers configuring suddenly failing once enforcement kicks in. Catching them ahead of time is mostly a matter of knowing where they hide.
- Publishing two SPF TXT records. DNS allows multiple TXT records at the same name, but SPF explicitly does not. Two SPF records cause a permanent error that fails every sender, not just the extra one.
- Exceeding the 10-lookup limit without noticing. SPF failures from this cause are silent until someone checks DMARC reports; the record still “looks” valid when you read it.
- Jumping straight to p=reject. Skipping the monitoring and quarantine stages means the first thing you learn about a missing sender is that its mail stopped arriving, after your customers or partners already noticed.
- Forgetting subdomain policy. A DMARC record on example.com doesn’t automatically lock down mail.example.com or an unused subdomain unless you set the sp= tag or publish a record for that subdomain directly, and unused subdomains are a favorite spoofing target precisely because nobody protects them.
- Identifier misalignment. A marketing platform sending as “news@mail.example.com” while your visible From: shows “news@example.com” can fail DMARC alignment even when SPF and DKIM both individually pass, if the alignment mode is set to strict rather than relaxed.
- Letting DKIM selectors go stale. When an ESP migrates its signing infrastructure, it sometimes rotates the selector without clearly flagging it, and DKIM quietly starts failing until someone checks reports.
- Ignoring what forwarding does to SPF. A message forwarded by a user’s inbox rule or an internal mailing list often changes the envelope sender, breaking SPF for a perfectly legitimate message; this is a known limitation, not a misconfiguration, and it’s one of the reasons DMARC weighs DKIM alignment as an alternative path to passing.
- Treating DNS secrets like static text. Private keys, API tokens for your DMARC analyzer, and SMTP credentials for every sender in your inventory deserve the same credential hygiene as the leaked tokens behind incidents like the Discord bot token exposure covered elsewhere on this site; a DKIM private key sitting in an unprotected config file undermines the whole setup just as badly as a missing DNS record.
Troubleshooting Guide: 8 Real Problems and Fixes
| Symptom | Likely cause | Fix |
|---|---|---|
| SPF shows “permerror” in reports | More than 10 effective DNS lookups | Flatten nested includes; remove unused vendors; recount lookups after each change |
| SPF and DKIM both pass individually, but DMARC still fails | Alignment mismatch between the signing/sending domain and the visible From: domain | Switch alignment mode from strict (aspf=s / adkim=s) to relaxed, or correct the sending domain to match the visible From: |
| DKIM signature present but marked invalid | Key was rotated in your mail platform but the old DNS record wasn’t updated, or a selector mismatch | Confirm the selector in the DKIM-Signature header matches a currently published DNS TXT record |
| No aggregate reports ever arrive | rua mailbox isn’t set up to accept external reports, or the receiving domain requires an authorization record | Verify the reporting mailbox exists and check whether the receiving domain needs an external-report authorization TXT record under its own DNS |
| Legitimate marketing mail starts landing in spam after moving to quarantine | pct rollout moved too fast, or a vendor was missing from the sender inventory | Roll pct back to a lower value temporarily; add the missing vendor to SPF and DKIM, then re-raise pct gradually |
| BIMI logo won’t display in Gmail | Missing a Verified Mark Certificate, or DMARC isn’t fully enforced at pct=100 | Confirm p=quarantine or p=reject at pct=100 first; obtain a VMC from an authorized CA if targeting Gmail specifically |
| DMARC record appears to be ignored by receivers | Syntax error, most often v=DMARC1 not appearing as the first tag, or a stray semicolon | Validate the record string character by character before publishing; re-check with dig after any edit |
| Internal mailing lists or forwarders break DKIM | The reflector modifies the message body or subject line, invalidating the original signature | Treat internal reflected mail as a known exception rather than forcing strict DKIM on it; consider ARC-aware handling for high-volume internal forwarders |
Advanced Tips for Multi-Domain and Enterprise Rollouts
Organizations running more than a handful of domains run into problems a single-domain setup never hits. A single compliance team might own the DMARC record, while five different business units each independently sign contracts with new marketing or transactional email vendors, and none of those three groups talk to each other until a quarterly report shows an unexplained spoofing attempt or a dropped campaign. A few practices worth adopting early close that gap before it becomes an incident:
- Centralize reporting, not policy. Point rua at one dedicated mailbox across every subsidiary domain for a single analyzer dashboard, but still publish a separate DMARC record per domain, since policy needs vary by how each domain is used.
- Lock down parked and non-sending domains immediately. A domain that never sends mail has no legitimate reason to pass SPF checks at all. Publish v=spf1 -all and p=reject on day one for these; there’s no monitoring runway needed because there’s nothing to monitor.
- Use the sp= tag to cover subdomains explicitly. Without it, an attacker can register an unused subdomain pattern and spoof it even while your root domain is fully enforced.
- Move to strict alignment only after confirming exact domain matches. Relaxed alignment (the default for both aspf and adkim) is the safer choice for most organizations; strict alignment is for teams that have already verified every legitimate sender uses an exact domain match.
- Support ARC for internal forwarders. If your organization relies on internal mailing lists or security gateways that modify messages in transit, Authenticated Received Chain support lets a downstream receiver trust that an intermediary verified the original message, reducing false DKIM failures on legitimately forwarded mail. Mail security gateways like FortiMail, which patched a critical zero-day earlier this year, are a common place this configuration lives in enterprise environments, so include your gateway vendor in the sender inventory from Step 2.
- Tie key rotation to a change ticket. Rotating DKIM keys on an ad hoc basis leaves no audit trail; rotating against a scheduled ticket gives compliance teams something concrete to point to.
Complete Working Project: A Full DNS Record Set You Can Copy
Here is a complete, enforced DNS configuration for a fictional domain, combining every record from this tutorial into one working set. Swap in your own domain, sender IPs, and public keys before publishing.
# SPF -- primary sending domain
example.com. IN TXT "v=spf1 ip4:192.0.2.10 include:_spf.google.com include:sendgrid.net -all"
# DKIM -- active selector, 2048-bit RSA
sel2026._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
# DMARC -- full enforcement, aggregate + forensic reporting, subdomains covered
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensics@example.com; aspf=r; adkim=r"
# BIMI -- logo display for supporting inboxes
default._bimi.example.com. IN TXT "v=BIMI1; l=https://example.com/brand/logo.svg; a=https://example.com/brand/vmc.pem"
# Parked/non-sending subdomain -- lock down immediately, no monitoring needed
mail-test.example.com. IN TXT "v=spf1 -all"
_dmarc.mail-test.example.com. IN TXT "v=DMARC1; p=reject; pct=100"This set assumes you’ve already run the monitoring and quarantine phases described in Steps 7 through 9 for the primary domain; never publish p=reject on a live sending domain without that groundwork, since the records above represent the end state of the rollout, not the starting point.
Frequently Asked Questions
What’s the actual difference between SPF, DKIM, and DMARC?
SPF authorizes which servers can send for your domain. DKIM cryptographically signs messages so receivers can confirm they weren’t altered. DMARC ties both checks to the visible From: address and tells receivers what to do when a message fails, plus it generates reports showing you what’s actually happening across your domain’s mail traffic.
Do I need all three, or is DMARC alone enough?
DMARC requires at least one of SPF or DKIM to pass and align with the visible From: domain before it can pass at all, so you need SPF, DKIM, or both configured correctly underneath it. Most organizations run both, since DKIM alone survives message forwarding better, while SPF alone is simpler to deploy and audit.
How long does a full SPF/DKIM/DMARC rollout take?
Plan for 2 to 4 weeks for a single-domain setup with a short list of senders, moving from p=none through quarantine to reject. Enterprises with multiple domains and several marketing or transactional vendors should budget 6 to 8 weeks to give the monitoring phase enough time to surface every sender.
What happens if I skip straight to p=reject?
Any legitimate sender missing from your SPF and DKIM configuration gets blocked outright, with no warning before the fact. That typically surfaces as missed invoices, dropped marketing campaigns, or support tickets from customers who stopped receiving your mail, discovered after the damage rather than before it.
Does setting up DMARC cost money?
Publishing the DNS records themselves is free. Reading the aggregate reports by hand is possible but impractical past a handful of reports a day, which is why most teams use a free tier from an analyzer like EasyDMARC, dmarcian, or URIports during monitoring, upgrading to a paid tier only if reporting volume or team size justifies it.
How often should I rotate DKIM keys?
At least every six months under current guidance, sooner if you suspect a private key may have been exposed. Keep the previous selector active briefly during a rotation so messages signed just before the switch still validate on arrival.
What’s the SPF 10-lookup limit, and how do I know if I’ve hit it?
SPF checks stop after 10 DNS lookups triggered by include:, a, mx, exists, and redirect mechanisms, counting nested lookups from vendor records too. You’ll usually spot it as a permanent SPF error in your DMARC aggregate reports rather than anything visible in the record itself, since the record can look perfectly valid while still exceeding the limit in practice.
Do I need BIMI, and what does it require?
BIMI is optional and purely cosmetic, it displays your logo next to authenticated messages in supporting inboxes. It requires DMARC enforced at p=quarantine or p=reject, generally at pct=100, an SVG logo, and for Gmail specifically a Verified Mark Certificate tied to a registered trademark. Skip it until your enforcement setup is stable; it adds nothing to your actual spoofing protection.