Twenty-four billion credentials surfaced in a single leaked-data compilation this year, the kind of record dump tech-insider.org broke down in detail. A large share of those stolen logins end up doing the same job: feeding phishing campaigns that spoof a bank, a vendor, or a company’s own finance team. Verizon’s 2026 Data Breach Investigations Report found that exploited vulnerabilities have now overtaken stolen credentials as the top entry point into breaches, at 31% of incidents, but phishing and pretexting through email remain close behind. None of that risk goes away until your domain can tell a receiving mail server, in a way the server actually trusts, “this message did not come from us.”
That is the gap SPF, DKIM, and DMARC close. Configured correctly, the three protocols let Gmail, Outlook, and every other inbox verify that a message claiming to be from your domain really did originate from a server you authorized, and they hand you a paper trail the moment someone tries to fake it anyway. Skip them, and your domain sits open to business email compromise (BEC), a fraud category the FBI’s Internet Crime Complaint Center (IC3) folds into the $16.6 billion in annual US cybercrime losses it now tracks, with BEC consistently ranked among its costliest categories. Skip them and you also risk your legitimate mail landing in spam, since Google and Yahoo have required authentication from bulk senders since 2024 and kept enforcing it through 2026.
This tutorial walks through a full build: 13 steps, about 75 minutes of hands-on work plus a waiting period for DNS propagation and report collection. You will publish an SPF record, generate and publish a DKIM key pair, and roll out a DMARC policy from safe monitoring through full enforcement. By the end you will have a working configuration for a real domain, a reference table for every DMARC tag, and fixes for the errors that trip up almost every first attempt.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
Why Email Authentication Is Non-Negotiable in 2026
Email authentication used to be optional hygiene. It stopped being optional once Google and Yahoo started enforcing bulk-sender rules: any domain sending more than 5,000 messages a day to Gmail addresses must authenticate with SPF or DKIM and publish a DMARC TXT record, even at the minimal monitoring policy. Microsoft 365 and other major providers followed with their own authentication expectations. Miss the bar and your mail gets throttled, marked as spam, or rejected outright, regardless of how clean your sending reputation used to look.
The security case is just as direct. “DMARC combines SPF and DKIM, providing a more complete email authentication service to protect against spoofing, spam, and phishing,” according to Coalition, a cybersecurity insurer that underwrites breach claims tied to exactly this kind of attack. Spoofed vendor invoices, fake wire-transfer requests from a “CEO,” and cloned password-reset emails all rely on the same weakness: a domain that never told anyone what a legitimate message from it is supposed to look like. A published, enforced DMARC policy closes that weakness at the DNS layer, before a filter or a human ever has to make the call.
None of this is theoretical for readers of this site. This year alone brought breach disclosures at Instructure Canvas, Eastman Kodak, EY’s vendor network, Suno, Conduent, Charter Spectrum, and One Medical, each one adding fresh stolen data to the pool attackers use for convincing spoofed mail. Locking down your own domain will not undo any of those breaches, but it removes your organization as the next easy spoofing target sitting in that same pool.
What SPF, DKIM, and DMARC Actually Do
The three protocols solve different pieces of the same problem, and none of them works well alone.
SPF (Sender Policy Framework), defined in RFC 7208, is a DNS TXT record listing which mail servers are allowed to send on behalf of your domain. A receiving server checks the connecting IP address against that list. It is fast and simple, but it only checks the invisible “envelope sender,” not the From: address a human actually reads, and it breaks the moment a message gets forwarded through a third party.
DKIM (DomainKeys Identified Mail), defined in RFC 6376, attaches a cryptographic signature to each outgoing message using a private key, and publishes the matching public key in DNS. A receiving server recalculates the signature and confirms the message was not altered in transit. Unlike SPF, DKIM survives forwarding, because the signature travels with the message itself rather than depending on the connecting IP.
DMARC (Domain-based Message Authentication, Reporting, and Conformance), defined in RFC 7489, is the layer that ties the other two together and gives them teeth. As Digital Applied puts it, “SPF authorizes sending IPs, DKIM cryptographically signs messages, and DMARC ties both back to the visible From domain and sets a policy for failures.” DMARC checks that either SPF or DKIM passed, confirms that the passing check is aligned with the domain in the visible From: address, and then tells the receiving server what to do with mail that fails: do nothing, quarantine it, or reject it outright. It also asks receiving servers to email you a daily report of everything they saw claiming to be from your domain, which is how you find unauthorized senders you did not know existed.
DMARC’s full form is Domain-based Message Authentication, Reporting, and Conformance.
DuoCircle, email security blog
Put simply: SPF authorizes servers, DKIM proves integrity, and DMARC enforces the outcome while reporting back. You need all three published and aligned before a mailbox provider treats your domain as fully authenticated.
Prerequisites: What You Need Before You Start
This is a DNS and mail-platform configuration project, not a software install, so “versions” mostly means the tools you will use to generate and verify records. Confirm you have each of the following before starting the clock on the 75-minute estimate.
| Requirement | Notes |
|---|---|
| DNS access | Admin login to your registrar or DNS host (Cloudflare, Route 53, GoDaddy, etc.) with permission to add TXT records |
| Mail platform admin access | Google Workspace Admin console, Microsoft 365 Defender portal, or root/sudo access to a self-hosted mail transfer agent |
| OpenSSL | Version 3.0 or later recommended (1.1.1 also works); run openssl version to confirm |
| DNS lookup tools | dig (BIND utilities) or nslookup, available by default on macOS/Linux; installable on Windows via WSL or BIND tools |
| OpenDKIM (self-hosted only) | Version 2.11 or later, if you run Postfix or Exim instead of a hosted platform |
| A mailbox for reports | A dedicated address such as [email protected] to receive aggregate report data |
| Time budget | ~75 minutes of active work, spread across a 2 to 6 week rollout while DNS propagates and reports accumulate |
One access note before you begin: if you use Google Workspace or Microsoft 365, DKIM and DMARC setup both include a platform-side step in addition to the DNS record. Google’s own guidance is explicit that DKIM and SPF need to be authenticating messages for at least 48 hours before you turn on DMARC, so do not compress the phases below into a single afternoon even if the DNS changes themselves take minutes.
Phase 1: Publish Your SPF Record
Step 1: Audit every system that sends mail from your domain. Before writing anything, list every service authorized to send as you: your mail platform, your CRM, your support desk, your marketing tool, your invoicing software, your monitoring alerts. Missing one here is the single most common cause of legitimate mail breaking later. Check billing dashboards and admin panels for anything with an “SMTP” or “send email” setting, since these are the senders people forget.
Step 2: Write and publish the SPF TXT record. SPF records use include: mechanisms to authorize each provider’s sending infrastructure, plus a qualifier at the end that tells receivers what to do with anything not on the list. A domain sending through Google Workspace and SendGrid looks like this:
# TXT record at the root of example.com
v=spf1 include:_spf.google.com include:sendgrid.net ~allThe ~all at the end is a softfail: mail from unlisted servers gets flagged but still delivered. That is intentional during setup. Current 2026 guidance from both Red Sift and TheInboxLedger recommends starting with ~all specifically so a missed sender from your Step 1 audit does not silently start bouncing mail before you have verified the list is complete. Publish only one SPF TXT record per domain. Two separate SPF records on the same host is invalid per RFC 7208 and causes a PermError that fails authentication for every sender, not just the unlisted ones.
Step 3: Validate the SPF record before moving on. Query the record directly to confirm it published and propagated:
$ dig TXT example.com +short
"v=spf1 include:_spf.google.com include:sendgrid.net ~all"If that comes back empty, give it 30 to 60 minutes for propagation and check again. While you wait, count your DNS lookups. SPF has a hard ceiling of 10 DNS lookups during evaluation, a limit written into RFC 7208 and reiterated in 2026 guidance from Valimail and Red Sift alike. Each include, a, mx, ptr, and exists mechanism counts against that ceiling, and nested includes count their own lookups too. dmarcian’s SPF Surveyor tool will walk the chain and tell you exactly how many lookups your record consumes, which matters because a domain that exceeds 10 lookups fails SPF entirely, for every sender, with no partial credit.
Phase 2: Generate and Publish a DKIM Record
Most hosted platforms generate and rotate DKIM keys for you, so start there before reaching for OpenSSL.
Step 4: Generate a DKIM key pair. If you use Google Workspace, Microsoft 365, or Salesforce, the platform generates the key pair internally and gives you a DNS record to publish. Monday.com’s product guidance for its own senders puts the platform-side step plainly: “Enable DKIM in each email platform.” If you run your own mail transfer agent through Postfix and OpenDKIM instead, generate the key pair yourself:
$ openssl genrsa -out example.com.dkim.private.pem 2048
$ openssl rsa -in example.com.dkim.private.pem -pubout -out example.com.dkim.public.pem
$ openssl rsa -in example.com.dkim.private.pem -pubout -outform der 2>/dev/null | openssl base64 -AUse 2048-bit RSA keys at minimum. That figure is not arbitrary: it is the current baseline recommendation across 2026 deployment guides from DmarcReport and datainnovation.io, and it balances signature strength against the practical limits of what fits cleanly in a DNS TXT record. Keep the private key on the mail server only. It never goes in DNS.
Step 5: Publish the DKIM DNS record. DKIM records live at a selector-based hostname, not the domain root, so multiple keys and multiple senders can coexist. The format is selector._domainkey.yourdomain.com:
# TXT record at google._domainkey.example.com
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7v...(truncated)...N1QIDAQABThe selector name (google in this example) comes from your mail platform’s DKIM setup page, or from whatever you choose yourself on a self-hosted server. Copy the public key value exactly as provided. DNS hosts sometimes wrap or truncate long TXT values, so if your host has a character limit per line, split the key into quoted segments per your provider’s TXT record documentation rather than shortening it.
Step 6: Turn on DKIM signing. Publishing the DNS record does not sign anything by itself. In Google Workspace, this is a separate “Start authentication” toggle in the Admin console’s Gmail authentication settings. In Microsoft 365, it is the Enable-DkimSigningConfig step in Defender for Office 365. On a self-hosted server, it means pointing OpenDKIM’s KeyTable and SigningTable at the private key you generated in Step 4 and confirming the milter is active in your mail transfer agent’s configuration.
Step 7: Confirm DKIM signing is live. Send a test message to a Gmail account you control and open “Show original” from the message menu. You are looking for a header line reading dkim=pass. You can also query the DNS record directly to confirm it resolves:
$ dig TXT google._domainkey.example.com +short
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7v...N1QIDAQAB"Do not move on to DMARC until both SPF and DKIM have been authenticating live mail for at least 48 hours. That waiting period, straight from Google’s own DMARC setup documentation, gives you a clean baseline before DMARC starts evaluating and reporting on your traffic.
Phase 3: Roll Out Your DMARC Record From Monitoring to Enforcement
This is the phase most tutorials rush, and the one most likely to break real mail if you rush it too. DMARC rollout is a multi-week process by design, not a single DNS edit.
Step 8: Publish your first DMARC record at p=none. A DMARC record is a TXT record at _dmarc.yourdomain.com. Start in monitoring mode, which asks receiving servers to report on your mail without taking any enforcement action:
# TXT record at _dmarc.example.com
v=DMARC1; p=none; rua=mailto:[email protected]; fo=12026 setup guidance from EasyDMARC, Red Sift, and TheInboxLedger converges on the same advice: always start with p=none. It costs you nothing in deliverability while you collect real data on who is actually sending mail as your domain, including senders you forgot in Step 1 and anyone actively spoofing you.
Step 9: Turn on aggregate reports and read them. The rua= tag you just published tells every major receiving server to send you a daily XML report summarizing what it saw. Reports typically arrive gzipped. A short script gets you readable output fast:
import gzip
import xml.etree.ElementTree as ET
with gzip.open("[email protected]!1749340800!1749427200.xml.gz") as f:
root = ET.parse(f).getroot()
for record in root.findall(".//record"):
ip = record.find("row/source_ip").text
disposition = record.find("row/policy_evaluated/disposition").text
spf = record.find("auth_results/spf/result").text
dkim = record.find("auth_results/dkim/result").text
print(f"{ip:<15} disposition={disposition:<10} spf={spf:<8} dkim={dkim}")Running that against a week of reports produces output like this:
203.0.113.12 disposition=none spf=pass dkim=pass
198.51.100.44 disposition=none spf=fail dkim=none
203.0.113.201 disposition=none spf=pass dkim=passThat second line is what you are hunting for: an IP address failing both checks while claiming to be your domain. Manually reading raw XML gets old fast at any real volume, so most teams move to a free-tier report dashboard such as Red Sift OnDMARC or dmarcian's report analyzer once the volume of daily reports grows past a handful of source IPs.
Step 10: Track down and fix unauthorized senders. For every failing source IP, work out whether it is a legitimate sender you missed in Step 1 (fix: add it to your SPF record and enable DKIM on that platform) or genuine spoofing (fix: nothing to add, since this is exactly what DMARC enforcement will block later). Plan on at least one to two weeks in this step alone. Real organizations routinely discover forgotten senders here, from an old marketing tool nobody decommissioned to a support ticketing system sending on a shared IP block.
Step 11: Move to a quarantine policy. Once your reports run clean for at least a week, ramp enforcement gradually using the pct= tag rather than flipping straight to full enforcement:
# TXT record at _dmarc.example.com
v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=s; aspf=sStarting at pct=25 applies quarantine to a quarter of failing mail, sent to spam instead of the inbox, while you confirm nothing legitimate gets caught. Step the percentage up toward 100 over one to two weeks, watching reports after each change. The adkim=s and aspf=s tags switch alignment from relaxed to strict, requiring an exact domain match rather than a subdomain match, tightening the policy further.
Step 12: Enforce with p=reject. Once quarantine has run clean at 100%, move to full rejection:
# TXT record at _dmarc.example.com
v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]; adkim=s; aspf=s; sp=rejectThis is the policy Google and Yahoo's bulk-sender enforcement is ultimately steering the ecosystem toward, and it is the only DMARC policy that actually stops spoofed mail from reaching an inbox rather than just flagging it. The added sp= tag sets a separate policy for subdomains, closing a gap attackers exploit by spoofing mail.example.com or billing.example.com instead of the root domain.
Step 13: Automate monitoring and key rotation. DMARC is not a one-time project. Keep rua= reports flowing to a dashboard so a newly added sender does not silently start failing months from now, and rotate DKIM keys on a schedule. 2026 operational guidance from TheInboxLedger and other current setup guides recommends rotating DKIM keys somewhere between every 6 months and annually, generating a new key pair with the Step 4 commands and publishing it under a new selector before retiring the old one.
A Complete Working DMARC, SPF, and DKIM Setup
Here is what a finished, enforced configuration looks like end to end for a domain sending through Google Workspace and SendGrid, with all three records in one place as you would see them in a DNS zone file:
; SPF - authorizes Google Workspace and SendGrid to send as example.com
example.com. TXT "v=spf1 include:_spf.google.com include:sendgrid.net ~all"
; DKIM - Google Workspace selector, public key only (private key stays on Google's servers)
google._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7v...N1QIDAQAB"
; DKIM - SendGrid selector, generated during SendGrid domain authentication
s1._domainkey.example.com. CNAME s1.domainkey.u1234567.wl123.sendgrid.net.
s2._domainkey.example.com. CNAME s2.domainkey.u1234567.wl123.sendgrid.net.
; DMARC - fully enforced, with subdomain policy and aggregate reporting
_dmarc.example.com. TXT "v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]; adkim=s; aspf=s; sp=reject"Notice that DKIM shows up twice, once as a native Google Workspace TXT record and once as SendGrid's CNAME-based delegation, which is how SendGrid and several other transactional-email providers manage key rotation for you automatically. Both are valid at the same time because DKIM records live at unique selector hostnames rather than competing for the same DNS name the way a second SPF record would. This is also why the Step 1 audit matters so much: every additional sending platform typically adds its own DKIM selector to this file, and missing one means that platform's mail will fail DKIM even after everything else is enforced correctly.
DMARC Tag Reference: Every Field Explained
Keep this table open in another tab while you write your own record. Every tag below is optional except v= and p=, but the others are what turn a bare-minimum record into one you can actually operate.
| Tag | Purpose | Example value |
|---|---|---|
| v= | Protocol version; must be first and always DMARC1 | v=DMARC1 |
| p= | Policy for the domain: none, quarantine, or reject | p=quarantine |
| sp= | Separate policy applied to subdomains only | sp=reject |
| pct= | Percentage of failing mail the policy applies to | pct=25 |
| rua= | Mailto address(es) for daily aggregate XML reports | rua=mailto:[email protected] |
| ruf= | Mailto address(es) for per-message forensic/failure reports | ruf=mailto:[email protected] |
| adkim= | DKIM alignment mode: r (relaxed, default) or s (strict) | adkim=s |
| aspf= | SPF alignment mode: r (relaxed, default) or s (strict) | aspf=s |
| fo= | Forensic report triggers, e.g. 1 = report on any failure | fo=1 |
| ri= | Requested report interval in seconds (default 86400) | ri=86400 |
Alignment mode is the tag most tutorials skip and most misconfigurations trip over. Relaxed alignment (the default) accepts a match between the organizational domain, so mail.example.com aligns fine with example.com. Strict alignment requires an exact match between the signing or sending domain and the visible From: header, with no subdomain flexibility at all. Move to strict only after your reports confirm every legitimate sender already matches exactly.
SPF vs. DKIM vs. DMARC at a Glance
| Protocol | What it checks | Survives forwarding? | What failure does |
|---|---|---|---|
| SPF | Connecting server IP against an authorized list | No | Flags or fails, depending on the record's qualifier (~all, -all) |
| DKIM | Cryptographic signature proving message integrity | Yes | Signature simply does not validate; no built-in enforcement |
| DMARC | Alignment between SPF/DKIM results and the visible From: domain | Uses whichever of SPF/DKIM survives | Applies the domain's own policy: none, quarantine, or reject |
The practical takeaway: SPF alone breaks on forwarded mail, DKIM alone has no enforcement mechanism, and neither one checks the address a human actually reads in their inbox. DMARC needs at least one of the other two to pass and align, which is why it always comes last in setup order, never first.
Common Pitfalls That Break Email Authentication
These mistakes show up often enough in real deployments that they are worth checking for by name before you consider the job finished.
- Publishing two SPF TXT records instead of one merged record. DNS allows it technically, but RFC 7208 does not, and the result is a PermError that fails SPF for every sender, not just the newest one added.
- Blowing past the 10-DNS-lookup ceiling. Nested includes add up fast, and a domain that exceeds the limit fails SPF completely rather than partially. Recent industry research from dmarcguard's 2026 DMARC Adoption report puts the share of SPF-enabled domains that exceed this limit at 4.8%, a small but entirely avoidable failure mode.
- Jumping straight to p=reject on day one. Skipping the monitoring period means finding out about a forgotten sender when its mail starts bouncing in production, not from a report.
- Forgetting the sp= subdomain tag. A root domain locked down at p=reject with no sp= tag still leaves every subdomain open to spoofing.
- Mismatched DKIM selectors or key length. A DNS record published under the wrong selector name, or a key shorter than 2048-bit RSA, will fail validation even though a DKIM record technically exists.
- Treating alignment as automatic. SPF or DKIM passing is not enough by itself; DMARC also checks that the passing domain aligns with the visible From: header, and relaxed-mode assumptions do not always hold once you move to strict.
- Never reading the aggregate reports. Publishing rua= and then ignoring the mailbox it points to defeats the entire point of the monitoring phase. SpamCipher's 2026 review of email authentication at scale found 1.6% of SPF-publishing domains carry a multiple-record error alone, the kind of problem aggregate reports surface immediately if anyone actually reads them.
Troubleshooting DMARC, SPF, and DKIM Errors
Work through this table top to bottom whenever a check fails. Most authentication problems trace back to one of these eight patterns.
| Symptom | Likely cause | Fix |
|---|---|---|
| SPF shows PermError | Two SPF TXT records published, or the DNS lookup count exceeds 10 | Merge into a single record; run it through dmarcian's SPF Surveyor to count lookups |
| SPF passes but DMARC still fails | SPF domain is not aligned with the visible From: header domain | Check whether adkim/aspf is set to strict when it should be relaxed, or vice versa |
| DKIM signature present but invalid | Wrong selector published, key mismatch, or message body modified in transit (e.g. by a mailing list footer) | Re-verify the selector name matches exactly; some list servers require ARC instead |
| No DKIM signature at all | Signing was never enabled on the sending platform after the DNS record was published | Check the platform's authentication settings, not just DNS; DNS alone does not sign mail |
| DMARC record not found | Record published at the wrong host, e.g. dmarc.example.com instead of _dmarc.example.com | Confirm the leading underscore and exact subdomain with dig TXT _dmarc.example.com +short |
| No aggregate reports arriving | rua= mailbox does not exist, or the receiving mailbox is silently dropping the reports as spam | Confirm the mailbox exists and check its own spam folder; some providers also require a verification TXT record on the destination domain |
| Legitimate mail suddenly quarantined | A sender was missed during the audit, or pct= was ramped up too fast | Drop pct= back down, add the missing sender to SPF/DKIM, then resume the ramp |
| Forwarded mail fails DMARC | Forwarding strips or breaks SPF, and the forwarder does not re-sign with DKIM | Ask the forwarding service if it supports ARC (Authenticated Received Chain); otherwise this is an accepted limitation, not a misconfiguration |
Tools for Checking and Monitoring Your DMARC Record
You do not need a paid platform to get through initial setup, though most teams end up on one for ongoing monitoring once report volume grows.
- MXToolbox: the fastest free way to check whether SPF, DKIM, and DMARC records are published and syntactically valid, and a common first stop in 2026 setup guides.
- dmarcian's SPF Surveyor: walks nested SPF includes and reports the exact DNS lookup count, which is the only reliable way to confirm you are under the 10-lookup ceiling.
- Red Sift OnDMARC: turns raw aggregate XML reports into a readable dashboard, useful once you are past the handful of source IPs a manual script can track.
- dig and nslookup: free, built into every major operating system, and the fastest way to confirm a record actually propagated before you go looking for a bug that is really just DNS caching.
- Your mail platform's own admin console: Google Workspace and Microsoft 365 both surface authentication status and setup wizards directly, and per Valimail's current guidance, both platforms (along with Salesforce) ship built-in DKIM support that removes the manual OpenSSL steps entirely.
Advanced Tips: BIMI, ARC, and Subdomain Policy
Once your domain sits at a clean p=reject, four refinements are worth the extra effort. None of them are required to call the setup finished, but each one closes a gap that only shows up after the basic rollout has already been running for a while.
BIMI: turning enforcement into a visible brand signal
BIMI (Brand Indicators for Message Identification) lets your logo appear next to authenticated mail in supporting inboxes, but it has a hard prerequisite: BIMI will not activate until DMARC is enforced at p=reject, or at p=quarantine with pct=100, across the whole domain. Treat BIMI as a reward for finishing DMARC enforcement properly, not a shortcut around it. Most BIMI setups also require a Verified Mark Certificate for the logo itself, an added cost and paperwork step worth budgeting for separately once enforcement is stable.
ARC: keeping forwarded and mailing-list mail alive
ARC (Authenticated Received Chain) addresses the forwarding gap described in the troubleshooting table above. Mailing lists and forwarding services that support ARC add a signed chain of custody as a message passes through, letting a final receiving server trust the original authentication results even after SPF broke and DKIM's body hash changed along the way. If your organization runs its own mailing lists, check whether your list software (Mailman, Google Groups, and similar tools) supports ARC before you lock subdomain policy down too tightly, since a strict policy with no ARC support can quietly start dropping list traffic nobody intended to block.
Subdomain policy: closing the gap attackers look for first
Subdomain policy (sp=) deserves its own audit, separate from your root domain review. Marketing platforms, ticketing systems, and staging environments frequently send from subdomains like news.example.com or support.example.com that nobody remembers to include in the original Step 1 inventory. Query each known subdomain's own inheritance before assuming sp=reject on the root record covers everything safely, and treat any subdomain you are not actively using for mail as a candidate for its own locked-down policy rather than leaving it unaddressed.
Plan DNS TTL changes before you start, not during
Lower your TXT record TTL (time to live) to something short, such as 300 to 600 seconds, a day or two before you expect to make changes during the ramp from monitoring to enforcement. A record published with a default 24-hour TTL will still be cached by resolvers around the internet long after you have edited it, which makes troubleshooting a "why is my new policy not applying" problem far harder than it needs to be. Set the TTL back to a longer value only once the domain has settled at its final enforcement policy.
How Google and Yahoo's Bulk Sender Rules Change the Calculus
Google and Yahoo's bulk-sender authentication requirements, in force since 2024 and still the baseline enforcement mechanism through 2026, are the reason this setup stopped being a nice-to-have for a lot of organizations. Cross the 5,000-message-per-day threshold to Gmail addresses and the platform requires SPF or DKIM authentication plus a published DMARC policy, at minimum at p=none, before it will reliably deliver your mail to the inbox instead of spam or outright rejection. Yahoo applies matching requirements for high-volume senders to its own user base.
That threshold catches more organizations than it sounds like it should. A single marketing send, a password-reset flow at moderate signup volume, or a transactional-email integration can all cross 5,000 messages a day well before a company would describe itself as a "bulk sender." Google's Workspace admin documentation frames DMARC setup as a standard step in the Security & data protection section of the Admin console for exactly this reason: it is no longer an advanced-user feature, it is table stakes for reliable delivery.
The practical implication for this tutorial: even if your organization has no immediate security incident driving the project, deliverability alone now justifies working through all 13 steps. A domain stuck at p=none with no enforcement plan is compliant with the bare minimum, but it captures none of the anti-spoofing benefit and leaves reports sitting unread in a mailbox nobody checks.
Frequently Asked Questions About DMARC, SPF, and DKIM
What is a DMARC record and do I actually need one?
A DMARC record is a DNS TXT record at _dmarc.yourdomain.com that tells receiving mail servers how to handle messages that fail SPF and DKIM alignment. You need one if you send any business email at all, and it is mandatory in practice if you cross Google or Yahoo's bulk-sender thresholds.
What is the difference between SPF, DKIM, and DMARC?
SPF authorizes which servers can send as your domain. DKIM cryptographically signs messages to prove they were not altered. DMARC checks that SPF or DKIM passed and aligns with your visible From: address, then enforces a policy on anything that fails.
Will DMARC break my email if I set p=reject too early?
Yes, that is the single most common failure mode in this tutorial. Skipping the p=none monitoring period means you find out about a missed legitimate sender when its mail starts bouncing, instead of from a report. Always ramp through none, then quarantine, then reject.
How long does full DMARC rollout actually take?
Budget 2 to 6 weeks from first publishing p=none to reaching p=reject at 100%, not counting the roughly 75 minutes of hands-on configuration time. The gap is deliberate: it is time spent reading reports and fixing unauthorized senders, not DNS propagation.
Do I still need this if I only send through Google Workspace or Microsoft 365?
Yes. Hosted platforms handle DKIM signing for you and usually simplify SPF, but neither one publishes a DMARC record automatically. You still have to create and roll out that record yourself.
What happens if I exceed the SPF 10-lookup limit?
SPF fails entirely for the domain, not just for the mechanisms past the limit. Use a tool like dmarcian's SPF Surveyor to count lookups before publishing, and flatten or consolidate includes if you are close to the ceiling.
Can a domain have more than one DMARC record?
No. Exactly one DMARC TXT record belongs at _dmarc.yourdomain.com. Multiple records, like multiple SPF records, produce undefined or failed evaluation rather than a merged policy.
How often should DKIM keys be rotated?
Current 2026 operational guidance recommends somewhere between every 6 months and annually. Generate a new key pair under a new selector, publish it, confirm it is signing correctly, then retire the old selector.
