A domain with no SPF, DKIM, or DMARC record is an open invitation for scammers to send email that looks like it came from you. Business email compromise remains one of the costliest categories of cybercrime tracked by the FBI’s Internet Crime Complaint Center, and most of those attacks start with a spoofed or look-alike sender address. In May 2026 the IETF also replaced the decade-old DMARC specification, RFC 7489, with a new three-document standard known as DMARCbis: RFC 9989 for the core protocol, RFC 9990 for aggregate reports, and RFC 9991 for failure reports. At the same time, Google, Yahoo, and Microsoft have all locked in hard authentication requirements for anyone sending more than 5,000 messages a day to their users. If your domain isn’t authenticated correctly, your mail doesn’t just risk landing in spam. It can be rejected outright.
This tutorial walks through setting up SPF, DKIM, and DMARC from a bare domain to full enforcement, in 12 concrete steps, using the DNS record syntax mailbox providers expect in 2026. You’ll write real records, fix the SPF lookup limit that trips up most teams, rotate DKIM keys the right way, and read your first DMARC aggregate reports before flipping your policy to reject. Budget about 90 minutes for the initial setup, plus a monitoring period of two to four weeks before you enforce.
What SPF, DKIM, and DMARC Actually Do
SPF, DKIM, and DMARC solve three different pieces of the same problem: proving that an email claiming to be from your domain really is. Sender Policy Framework (SPF) publishes a list of IP addresses and services authorized to send mail for your domain in a DNS TXT record. When a receiving mail server gets a message, it checks the sending IP against that list. DomainKeys Identified Mail (DKIM) takes a different approach: it cryptographically signs outgoing messages with a private key, and receivers verify that signature against a public key published in your DNS. Unlike SPF, DKIM survives forwarding, because the signature travels with the message body and headers rather than depending on the connecting IP.
Domain-based Message Authentication, Reporting, and Conformance (DMARC) ties the other two together. It tells receiving servers what to do when a message fails SPF or DKIM, and it requires “alignment,” meaning the domain in the visible From: header has to match the domain that passed SPF or DKIM, not just any domain in the authentication chain. DMARC also gives you a reporting channel: mailbox providers send back daily XML reports showing every server that sent mail claiming to be your domain, which is how you catch spoofing attempts and misconfigured internal systems you didn’t know existed.
The May 2026 DMARCbis update, published as RFC 9989, formally obsoletes RFC 7489 and RFC 9091. The core tags you’ll use in your DNS records are unchanged: p= for policy, rua= for aggregate report addresses, ruf= for forensic report addresses, pct= for the percentage of mail subject to the policy, adkim= and aspf= for alignment strictness, and sp= for subdomain policy. What DMARCbis mainly does is formalize reporting behavior into its own documents (RFC 9990 for aggregate XML reports and RFC 9991 for failure reports) and clarify ambiguous edge cases that caused inconsistent enforcement across mailbox providers for a decade.
Prerequisites: What You Need Before You Start
You don’t need special software to set up SPF, DKIM, and DMARC, but you do need access to a few systems. Confirm you have the following before starting step 1.
- Admin access to your domain’s DNS zone (Cloudflare, Route 53, GoDaddy, Namecheap, or your registrar’s panel), with the ability to add TXT records.
- Admin access to every platform that sends mail on your domain’s behalf: your primary mail provider (Google Workspace, Microsoft 365, Zoho), your transactional email provider (SendGrid, Postmark, Amazon SES, Mailgun), and any marketing platform (HubSpot, Klaviyo, Mailchimp).
- A mailbox or shared inbox to receive DMARC aggregate reports, or a free DMARC report parser account (Cloudflare’s free DMARC Management tool, dmarcian’s free tier, or a self-hosted parser like parsedmarc are common choices in 2026).
- A DNS lookup tool for verification: dig or nslookup on the command line, or a web-based checker like MXToolbox.
- DKIM key generation capability. Most mail providers (Google Workspace, Microsoft 365, SendGrid) generate the key pair for you inside their admin console; if you’re running your own mail transfer agent, you’ll need OpenSSL, version 3.0 or newer, to generate a 2048-bit RSA key pair manually.
- Roughly 90 minutes for the initial DNS work, plus two to four weeks of monitoring time before you move DMARC to full enforcement. Do not skip the monitoring period; it’s the difference between a smooth rollout and your own marketing emails silently disappearing.
Step 1 and Step 2: Audit Your Current Setup and Map Every Sending Source
Step 1: Check what’s already published
Before touching DNS, find out what’s already there. Run these lookups against your domain to see your current state:
dig TXT example.com +short
dig TXT _dmarc.example.com +short
dig TXT selector1._domainkey.example.com +shortMany domains already have a partial SPF record from a previous mail migration, often with stale includes from a mail provider they stopped using years ago. Note every include and mechanism you find, because you’ll need to decide whether to keep or remove it in step 3. If there’s no DMARC record at all, you’re starting from zero, which is actually the simpler case: you’ll publish a monitoring-only record in step 7 rather than untangling someone else’s misconfiguration.
Step 2: Inventory every service that sends as your domain
This is the step teams most often skip, and it’s the one that causes the most support tickets later. Make a list of every system that sends mail using your domain in the From: address: your email hosting provider, transactional email APIs used by your application, your CRM or marketing automation tool, your help desk or ticketing system, invoicing software, and any internal scripts or cron jobs that send notification emails through an SMTP relay. If you skip a sending source now, its mail will start failing SPF and DKIM the moment you enforce DMARC, usually discovered only when a customer complains an invoice never arrived.
A practical way to build this list without relying purely on memory: publish a permissive monitoring DMARC record first (covered in step 7) and let two weeks of aggregate reports show you every IP address currently sending as your domain. Cross-reference unfamiliar IPs against your vendor list before you assume something is malicious; plenty of “unknown” senders turn out to be a forgotten marketing tool or a contractor’s automation script.
Step 3 and Step 4: Write Your SPF Record and Fix the 10-Lookup Limit
Step 3: Write your base SPF record
SPF is published as a single TXT record at your domain’s root. It starts with the version tag v=spf1, followed by mechanisms describing authorized senders, and ends with a qualifier telling receivers what to do with everything else. Here’s a realistic starting record for a company using Google Workspace for staff mail and a transactional provider for application email:
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 ~all"Two things matter here. First, you can only have one SPF TXT record per domain; if you have two, both are treated as invalid by most receivers, which is one of the most common SPF mistakes. If you already have a record, edit it rather than adding a second one. Second, the trailing qualifier controls enforcement: ~all means “soft fail” (mark as suspicious but usually still deliver, often to spam), while -all means “hard fail” (reject outright). Most guides recommend starting with ~all while you’re still discovering sending sources, then tightening to -all only once you’re confident your SPF record is complete and DMARC is already handling alignment decisions.
Step 4: Fix the SPF 10-DNS-lookup limit
SPF evaluation is capped at 10 DNS lookups total across every include, a, mx, ptr, exists, and redirect mechanism in your record, including nested lookups inside included records. Go over that limit and SPF returns a permerror, which most receivers treat as a fail, exactly the outcome you were trying to avoid. This is the single most common SPF misconfiguration, and it gets worse over time as teams bolt on one more include for every new tool without ever removing old ones.
Count your lookups manually by walking each include chain, or use a lookup-counting tool (MXToolbox and dmarcian both offer free SPF record checkers that count this for you). If you’re near or over the limit, your options are: remove includes for services you no longer use, replace a records with direct ip4/ip6 ranges where the IPs are static, or consolidate multiple third-party senders behind one flattened include if your DNS provider supports SPF macro flattening. Avoid manually “hard-flattening” your SPF record into a giant list of raw IPs unless you have an automated process to keep it in sync. Mail providers rotate sending IPs, and a manually flattened record goes stale within months, silently breaking delivery.
Step 5 and Step 6: Generate DKIM Keys and Enable Signing
Step 5: Generate a 2048-bit DKIM key pair
If your mail provider generates DKIM keys for you (Google Workspace, Microsoft 365, and every major transactional provider do this from their admin dashboard), use that flow instead of generating keys manually; it guarantees the private key stays on their signing infrastructure and reduces setup error. If you’re running your own mail server, generate a 2048-bit RSA key pair with OpenSSL:
openssl genrsa -out dkim_private.pem 2048
openssl rsa -in dkim_private.pem -pubout -out dkim_public.pemUse 2048-bit keys, not the older 1024-bit default some legacy tutorials still show. 2048-bit is the current baseline recommendation across major providers and deliverability guides, and 1024-bit is now treated as a legacy minimum at best. Plan to rotate your DKIM keys at least annually, generating a new key pair under a new selector name (more on selectors below) rather than reusing the old one.
Step 6: Publish the DKIM record and turn on signing
DKIM public keys are published as a TXT record at a specific subdomain pattern: selector._domainkey.yourdomain.com. The “selector” is an arbitrary name you or your provider chooses, often something like google, s1, or a date-based string like oct2026, which lets you run multiple DKIM keys simultaneously during rotation.
oct2026._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB..."The p= value is your Base64-encoded public key, truncated in the example above for readability, don’t truncate it in your actual DNS record. Once the TXT record is live and has propagated (check with the dig command from step 1, swapping in your selector), go back to your mail provider’s admin console and flip DKIM signing to enabled. Send a test message to a Gmail address and check the “show original” view for a dkim=pass result before moving on.
Step 7 and Step 8: Publish a Monitoring DMARC Record and Route Reports
Step 7: Publish DMARC in monitor-only mode
Once SPF and DKIM are live, publish your first DMARC record at _dmarc.yourdomain.com with p=none. This does not affect mail delivery at all; it simply tells receivers to start sending you reports on every message claiming to be from your domain, authenticated or not.
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100"Skipping this monitoring phase is the single most common reason DMARC rollouts break production mail. Jumping straight to p=reject before you’ve seen a single report means you’re enforcing a policy against sending sources you don’t fully know about yet.
Step 8: Route and parse aggregate reports
The rua= address you published in step 7 will start receiving daily gzipped XML reports from every major mailbox provider within 24 to 48 hours, each listing the sending IPs, message volumes, and SPF/DKIM pass-fail results they observed for your domain. Reading raw XML by hand does not scale past a handful of messages a day, so route these reports into a parser. Free options that support a single domain include Cloudflare’s DMARC Management tool (built into Cloudflare DNS), dmarcian’s free tier, and self-hosted open-source parsers like parsedmarc that ingest the XML and give you a dashboard. Point your rua= mailto address (or a dedicated inbox that forwards to your chosen tool) and let reports accumulate for at least two weeks before acting on them.
Step 9 and Step 10: Read Your Reports and Move to Quarantine
Step 9: Fix alignment failures before tightening policy
After two weeks of reports, you’ll typically see a mix of clean passes and a handful of surprises: a help desk tool sending as your domain without DKIM configured, an old marketing platform still authorized in your SPF record that you forgot to decommission, or an internal script sending through a relay that isn’t in your SPF include list at all. For each failing source, decide whether it’s legitimate (fix its authentication) or illegitimate (leave it failing, since that’s exactly the spoofing DMARC is designed to catch).
Pay close attention to alignment, not just pass/fail. A message can pass SPF and still fail DMARC if the SPF-authenticated domain doesn’t match the visible From: domain, which happens often with third-party senders that authenticate against their own domain rather than yours. Set adkim= and aspf= to r (relaxed) initially, which allows subdomain matches, then tighten to s (strict) only if your setup requires exact domain matches.
Step 10: Move to p=quarantine gradually
Once your legitimate sending sources are all passing and aligned, move from p=none to p=quarantine, but ramp it gradually using the pct= tag rather than flipping straight to 100%.
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r"Start at pct=25, watch reports for a few days, then raise to 50, then 100, over one to two weeks. This staged rollout limits blast radius if something you missed in step 9 turns out to be a legitimate sender that starts landing in spam.
Step 11 and Step 12: Enforce with Reject and Add BIMI
Step 11: Move to p=reject
Once quarantine at pct=100 has run clean for a week or two with no unexpected failures in your reports, move to full enforcement:
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensics@example.com; adkim=s; aspf=s; sp=reject"At p=reject, any message that fails SPF or DKIM alignment is refused outright by the receiving server rather than delivered to spam. This is the policy state that actually stops spoofed mail from reaching inboxes, and it’s also the minimum bar Google and Yahoo effectively expect from any domain sending meaningful volume in 2026. The sp= tag applies the same policy to subdomains that don’t have their own DMARC record, which matters because attackers often spoof unused subdomains specifically because organizations forget to lock them down.
Step 12: Add BIMI once you’re at enforcement
Brand Indicators for Message Identification (BIMI) displays your logo next to authenticated mail in supporting inboxes. It’s optional, but it’s a natural capstone once you’re at p=reject or p=quarantine near 100%, since BIMI explicitly requires DMARC enforcement to work at all; a p=none policy won’t qualify. BIMI is published as its own TXT record:
default._bimi.example.com. 3600 IN TXT "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/vmc.pem"The l= tag points to an SVG Tiny PS logo file, and a= optionally points to a Verified Mark Certificate. Some providers, including Gmail, currently require a VMC for the logo to actually display; others don’t. Treat BIMI as a nice-to-have layered on top of a solid DMARC deployment, not a substitute for one.
Meeting Google, Yahoo, and Microsoft’s 2026 Bulk Sender Requirements
Since February 2024, Google and Yahoo have enforced baseline authentication requirements on any domain sending more than 5,000 messages a day to their users, and Microsoft has since rolled out equivalent requirements for high-volume senders to Outlook.com and Hotmail consumer mailboxes. These rules are still the operative baseline in 2026, and they’re stricter than what many domains had in place even a year ago. The table below summarizes what each provider currently requires.
| Requirement | Google (Gmail) | Yahoo | Microsoft (Outlook.com) |
|---|---|---|---|
| SPF aligned with From: domain | Required | Required | Required |
| DKIM signing with aligned d= domain | Required | Required | Required |
| DMARC record published (minimum p=none) | Required | Required | Required |
| One-click List-Unsubscribe for marketing mail | Required | Required, RFC 8058 POST recommended | Best practice, not formally mandated |
| Spam complaint rate ceiling | ~0.3% | ~0.3% | Not publicly specified as a fixed number |
| Bulk sender threshold | 5,000 msgs/day | 5,000 msgs/day | 5,000 msgs/day |
The one-click unsubscribe requirement deserves its own callout, since it trips up teams focused purely on DNS records. It requires two headers on every marketing message: a List-Unsubscribe header with an HTTPS URL, and a List-Unsubscribe-Post header set to List-Unsubscribe=One-Click, which triggers RFC 8058-compliant POST behavior so Gmail and Yahoo can show a one-click “Unsubscribe” button directly in their interface without redirecting the user anywhere. Most transactional and marketing email platforms (SendGrid, Postmark, Mailchimp, HubSpot) add these headers automatically once you enable unsubscribe handling in their settings; verify it’s turned on rather than assuming it is.
Even if you send well under 5,000 messages a day, treat these requirements as the floor rather than a threshold you can ignore. Deliverability engines increasingly use authentication status as a general trust signal for every sender, not just high-volume ones, so an unauthenticated domain sending 200 emails a day can still land in spam more often than an authenticated one sending the same volume.
DMARC Tag Reference
Keep this table handy while you’re writing and editing DMARC records; it covers every tag used in the steps above plus a couple you’ll encounter in more advanced configurations.
| Tag | Purpose | Common values |
|---|---|---|
| v= | Protocol version, always first | DMARC1 |
| p= | Policy applied to your domain’s mail | none, quarantine, reject |
| sp= | Policy applied to subdomains without their own record | none, quarantine, reject |
| pct= | Percentage of failing mail the policy applies to | 1-100 |
| rua= | Where aggregate (summary) XML reports are sent | mailto:address@domain |
| ruf= | Where failure (forensic) reports are sent | mailto:address@domain |
| adkim= | DKIM alignment mode | r (relaxed), s (strict) |
| aspf= | SPF alignment mode | r (relaxed), s (strict) |
| fo= | Failure reporting options, controls when ruf reports fire | 0, 1, d, s |
Complete Working Example: A Full Multi-Provider DNS Configuration
Here’s what a finished, enforced setup looks like end to end for a company using Google Workspace for staff mail, SendGrid for transactional email, and HubSpot for marketing, with a static office relay IP for internal notifications.
; SPF - one record only, root domain
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net include:_spf.hubspotemail.net ip4:203.0.113.10 ~all"
; DKIM - Google Workspace selector
google._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."
; DKIM - SendGrid selector
s1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."
; DMARC - full enforcement, subdomains included
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensics@example.com; adkim=s; aspf=s; sp=reject; fo=1"
; BIMI - optional, requires enforcement above
default._bimi.example.com. 3600 IN TXT "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/vmc.pem"Notice the SPF record has four lookup-consuming mechanisms (three includes plus one ip4, which doesn’t count against the limit), comfortably under the 10-lookup ceiling from step 4. If this company later adds a fourth or fifth sending platform, they’ll need to recount lookups before adding another include blindly.
Common Pitfalls When Deploying Email Authentication
Most email authentication failures trace back to a small set of repeated mistakes. Watch for these specifically.
- Publishing two SPF records instead of editing the existing one. DNS allows multiple TXT records at the same name, but SPF explicitly requires exactly one. Two records make SPF evaluation fail entirely, even if each individual record is valid on its own.
- Jumping straight to p=reject without a monitoring period. Skipping p=none entirely means you enforce a policy against sending sources you haven’t verified, which typically breaks something in production, discovered only when a customer or partner reports missing mail.
- Exceeding the SPF 10-lookup limit through accumulated includes. Every new SaaS tool your team adds over the years tends to add another include mechanism, and almost nobody removes the old ones when a tool is retired. Recheck your lookup count any time you add a new sending platform.
- Forgetting DKIM selector rotation entirely. Teams set up DKIM once and never revisit it. Left unrotated for years, a compromised or weak key stays valid indefinitely. Rotate on a schedule (at least annually) using a new selector name so the old and new keys can overlap safely during transition.
- Ignoring subdomains. A DMARC record on your root domain doesn’t automatically protect subdomains unless you set sp= explicitly. Attackers specifically target unused or forgotten subdomains (like an old staging or marketing subdomain) precisely because organizations assume the root policy covers them.
- Missing the one-click unsubscribe headers on marketing mail. This is a Gmail and Yahoo delivery requirement independent of SPF/DKIM/DMARC, and it’s easy to assume your marketing platform handles it automatically when the setting is actually off by default.
- Not routing DMARC reports anywhere useful. Publishing rua= to a mailbox nobody checks means you’re generating data you never act on, which defeats the entire point of the monitoring phase.
Troubleshooting Guide
Work through these checks in order when authentication isn’t behaving as expected.
- SPF shows permerror. You’re almost certainly over the 10-lookup limit, or you have duplicate SPF records. Recount every include, a, mx, ptr, exists, and redirect mechanism, including nested lookups inside third-party includes.
- DKIM shows neutral or fail despite a correct-looking record. Check for line-wrapping or truncation in your DNS provider’s TXT record editor; long DKIM public keys sometimes get cut off or split incorrectly across multiple quoted strings, which some DNS panels handle differently.
- DMARC shows fail even though SPF and DKIM both pass. This is almost always an alignment problem: the domain that passed SPF or DKIM doesn’t match your visible From: domain. Check whether a third-party sender is authenticating against its own domain instead of yours.
- DNS changes aren’t taking effect. TTL caching means old records can persist in resolver caches well past when you updated them. Wait out the TTL you set (3600 seconds in the examples above equals one hour), or query an authoritative nameserver directly with dig to bypass cached resolvers.
- Aggregate reports show an unfamiliar sending IP. Cross-reference it against every vendor on your list from step 2 before assuming it’s malicious. Many “unknown” IPs turn out to be a forgotten tool, a contractor’s script, or a cloud provider’s outbound relay you didn’t realize was in use.
- Legitimate mail starts landing in spam after moving to quarantine. Roll pct= back down to a lower percentage immediately, identify the failing source from your reports, fix its authentication, then resume the ramp.
- BIMI logo isn’t displaying in Gmail. Confirm your DMARC policy is actually at enforcement (quarantine or reject, not none) and that you have a valid Verified Mark Certificate; Gmail specifically requires a VMC even though some other providers don’t.
- DMARC reports stopped arriving. Confirm the rua= mailbox still exists and isn’t silently rejecting or auto-deleting the incoming XML attachments; some spam filters flag automated report emails from mailbox providers as suspicious.
- One-click unsubscribe isn’t showing in Gmail’s interface. Verify your List-Unsubscribe-Post header is present and returns an actual HTTP 200 on POST; a broken or missing endpoint means Gmail won’t display the one-click button even if the List-Unsubscribe header itself looks correct.
Advanced Tips: DMARCbis, Key Rotation, and Automation
Once your baseline setup is stable at p=reject, a few refinements are worth the extra effort. First, automate DMARC report ingestion rather than reading raw XML by hand indefinitely; tools like parsedmarc can run on a schedule and alert you the moment a new, unrecognized sending source appears, turning DMARC from a one-time project into ongoing monitoring. Second, build DKIM key rotation into a recurring calendar task rather than leaving it as a one-off; generate a new selector, publish it alongside the old one, switch signing over, confirm passes in reports, then remove the old selector’s DNS record after a safe overlap window of a few weeks.
Third, treat DMARCbis as informational rather than something requiring immediate action on your existing records. RFC 9989 obsoletes RFC 7489, but the DNS record syntax and core tags you publish are unchanged; the update mainly formalizes reporting behavior (split into RFC 9990 for aggregate and RFC 9991 for failure reports) and clarifies ambiguous edge cases that caused inconsistent handling across providers. Existing DMARC records continue to work without modification.
Fourth, if your organization uses multiple brand domains or regional subdomains, don’t assume a parked or unused domain is safe from spoofing just because nobody sends mail from it. Publish a locked-down DMARC record (p=reject, no SPF senders authorized) on every domain and subdomain you own, including ones you never intend to send mail from. An unprotected parked domain is a common target precisely because it’s easy to spoof and nobody is watching for reports on it.
Finally, revisit your SPF record every time you onboard or offboard a SaaS tool that sends email, not just when something breaks. A quarterly SPF and DKIM audit, checking lookup count and removing includes for retired tools, prevents the slow accumulation that eventually forces an emergency fix under pressure.
Why This Matters: The Cost of Getting It Wrong
Business email compromise and domain spoofing remain among the highest-loss categories of cybercrime tracked in annual reports from the FBI’s Internet Crime Complaint Center, with billions of dollars in reported losses and consistent year-over-year growth. Security vendors including Proofpoint have repeatedly pointed to domain impersonation as a central mechanism in these attacks, which is exactly why SPF, DKIM, and DMARC enforcement are treated as baseline mitigations rather than optional hardening. A properly enforced DMARC record doesn’t stop every phishing attempt (attackers can still register look-alike domains you don’t own), but it closes off the specific tactic of sending mail that appears to come directly from your own domain, which is the version of the attack most likely to fool an employee, partner, or customer who already trusts your brand.
The deliverability upside is just as real as the security one. Mailbox providers increasingly treat authentication status as a general trust signal that affects inbox placement even for mail that isn’t malicious at all. A fully authenticated domain at DMARC enforcement tends to see better inbox placement across the board, not just for the specific volume thresholds Google, Yahoo, and Microsoft formally enforce. For a broader look at how mailbox providers and attackers are adapting in parallel, Google’s official email sender guidelines, Yahoo’s sender best practices, and Microsoft’s email authentication documentation are worth bookmarking, since all three update their enforcement details periodically. The DMARC.org overview page is also a useful reference for the underlying specification itself.
Frequently Asked Questions
Do I need SPF, DKIM, and DMARC if I send fewer than 5,000 emails a day?
Yes. The 5,000-message threshold only determines when Google, Yahoo, and Microsoft formally enforce these requirements; it doesn’t mean smaller senders are exempt from spoofing risk or deliverability penalties. Authentication status increasingly functions as a general trust signal regardless of volume.
What’s the difference between p=none, p=quarantine, and p=reject?
p=none only requests reports and takes no action on mail delivery. p=quarantine tells receivers to treat failing mail as suspicious, typically routing it to spam. p=reject tells receivers to refuse failing mail outright. Move through them in that order, never starting at reject on a domain you haven’t monitored first.
How long should I stay in DMARC monitoring mode before enforcing?
Two to four weeks at p=none is a reasonable minimum for most organizations, long enough to capture weekly and monthly sending patterns like invoicing cycles or scheduled newsletters that don’t send daily. Larger organizations with more sending sources may need longer.
Can I use the same DKIM selector for multiple sending providers?
No. Each sending provider needs its own selector name and key pair, since they each hold their own private key. Reusing one selector across providers isn’t technically possible unless they’re all signing with the exact same key, which isn’t how any major provider operates.
What happens to my SPF record if I exceed the 10-lookup limit?
SPF evaluation returns a permerror, which most receiving servers treat as a failure. This can affect all of your mail, not just messages from the sending source that pushed you over the limit, since the entire record fails to evaluate.
Is DMARCbis something I need to change my existing records for?
No. DMARCbis (RFC 9989, 9990, and 9991) formally replaces RFC 7489 as of May 2026, but the DNS record syntax and core tags are unchanged. Existing DMARC records continue to function without any required edits.
Do free DMARC report tools have limits I should know about?
Most free tiers, including Cloudflare’s built-in DMARC Management and dmarcian’s free plan, limit you to a single domain and a shorter report history than paid tiers. That’s usually sufficient for the initial monitoring and enforcement rollout described in this tutorial; organizations managing many domains at once typically outgrow the free tier faster.
Does BIMI work without DMARC enforcement?
No. BIMI requires your DMARC policy to be at enforcement, meaning p=quarantine or p=reject with meaningful coverage via pct=. A policy of p=none does not qualify for BIMI logo display at any major mailbox provider.