SPF, DKIM, and DMARC in 2026: The Email Security Stack That Still Actually Works

# SPF, DKIM, and DMARC in 2026: the email security stack that still actually works

$2.9 billion. That's the FBI IC3 number for business email compromise losses in 2024 alone. One attack category. One year. Bigger than the entire ransomware line item.

The defense has existed for 30 years. SPF since 2003. DKIM since 2007. DMARC since 2012. Every client we've run an email authentication audit on in the last year has had at least one of the three misconfigured or missing. Usually DMARC set to p=none, which is "we watch the reports roll in but enforce nothing." That's the setting that lets attackers keep spoofing your domain.

This post is what we actually check on audits. Exact DNS records you need. How Gmail and Microsoft 365 enforce. What breaks when you rush p=reject. BIMI setup for the brand logo Gmail and Apple Mail show alongside authenticated messages. And the specific mistakes we find on almost every audit.

#The three records you need

What we actually see in the field diverges from what the vendors describe. Here's the unvarnished version.

#SPF (Sender Policy Framework)

RFC 7208. Tells receiving servers which IP addresses are authorized to send email for your domain.

Published as a TXT record at the root of your domain:

valtikstudios.com. IN TXT "v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:203.0.113.5 -all"

Breakdown:

• v=spf1. Version
• include:_spf.google.com. Delegates to Google Workspace SPF record (resolves to current Gmail sending IPs)
• include:servers.mcsv.net. Mailchimp
• ip4:203.0.113.5. Specific IP authorized to send
• -all. Hard fail everything else (reject unauthorized senders)

Qualifiers:

• -all hard fail. Reject
• ~all soft fail. Mark as spam but deliver
• ?all neutral. Take no action
• +all pass everything. Catastrophic, never use

Critical SPF limits

SPF has a hard limit of 10 DNS lookups per evaluation (including nested include: and redirect= chains). Exceeding it results in a PermError that makes the SPF record non-functional.

You can hit 10 fast:

• include:_spf.google.com. 1
• include:servers.mcsv.net. 1 + nested lookups
• include:spf.protection.outlook.com. 1 + nested
• include:sendgrid.net. 1 + nested
• include:mailgun.org. 1 + nested
• include:_spf.salesforce.com. 1 + nested

Check your lookup count with dig or with tools like mxtoolbox SPF Survey (https://mxtoolbox.com/spf.aspx) or dmarcian SPF Survey.

When you exceed 10, the fix is SPF flattening. Resolve the includes yourself and publish static IP addresses. Or SPF macro tricks. Automated tools: EasyDMARC SPF Flattener, Scrub SPF.

#DKIM (DomainKeys Identified Mail)

RFC 6376. Cryptographic signature of the email itself. Receiving server verifies the signature against a public key in DNS.

Published as TXT records at a selector subdomain:

s1._domainkey.valtikstudios.com. IN TXT "v=DKIM1. K=rsa. P=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA[...long base64 public key...]"

The s1 is the selector. Picked when the sending service generates the key. Google Workspace uses google._domainkey. Microsoft 365 uses selector1._domainkey and selector2._domainkey. Mailchimp uses k1._domainkey or similar.

Key size: RSA 2048-bit is the 2026 standard. 1024-bit is deprecated. Ed25519 is supported by modern receivers but not universally. Run both as redundant selectors if deploying Ed25519.

Rotation: rotate DKIM keys at least annually. Google Workspace auto-rotates if you use the built-in DKIM setup (recommended). Microsoft 365 supports automatic rotation since 2024.

#DMARC (Domain-based Message Authentication, Reporting and Conformance)

RFC 7489. Ties SPF and DKIM together with a policy on what to do when both fail, and provides reporting back to the domain owner.

Published as TXT at _dmarc:

_dmarc.valtikstudios.com. IN TXT "v=DMARC1. P=reject. Rua=mailto:dmarc-rua@valtikstudios.com. Ruf=mailto:dmarc-ruf@valtikstudios.com. Fo=1. Adkim=s. Aspf=s. Pct=100"

Key tags:

• v=DMARC1. Version (required first)
• p=. Policy for the primary domain: none, quarantine, or reject
• sp=. Policy for subdomains (if omitted, inherits from p=)
• rua=. Aggregate report URI (JSON-like reports every 24h from participating receivers)
• ruf=. Failure report URI (individual failure forensic reports. Most big receivers don't send these anymore for privacy reasons)
• fo=. Failure reporting options (1 = report on any auth failure)
• adkim=. DKIM alignment mode: s (strict, exact domain match) or r (relaxed, organizational domain match)
• aspf=. SPF alignment mode: same
• pct=. Percentage of messages the policy applies to (used during rollout)

Alignment is what catches BEC

Without DMARC, an attacker can:

1. Pass SPF by sending from their own domain's authorized IP
2. Pass DKIM by signing with their own domain's key
3. Put From: ceo@yourcompany.com in the visible header

SPF and DKIM check the envelope sender and signing domain. DMARC adds the check that those must align with the visible From: header. That's the BEC killer.

#The staged rollout that doesn't break production

The #1 mistake: someone reads about DMARC, goes to DNS. And publishes p=reject on a domain that has had third-party senders going out unauthenticated for years. An hour later, marketing, support tickets, and transactional email all start bouncing.

Do it in this order.

#Stage 1: audit senders

You need to know every legitimate sender of email from your domain. The list is always longer than you think.

Common senders:

• Primary email provider (Google, Microsoft)
• Marketing automation (Mailchimp, HubSpot, Klaviyo, Marketo, Iterable)
• Transactional email (SendGrid, Postmark, Mailgun, Amazon SES)
• CRM-sent emails (Salesforce, HubSpot, Pipedrive)
• Customer support (Zendesk, Intercom, Front, Help Scout)
• Invoicing/billing (Stripe, QuickBooks, Xero, FreshBooks, Chargebee)
• Calendaring (Calendly, SavvyCal, Cal.com)
• Ticketing (Linear, Jira Service Management)
• HR (BambooHR, Gusto, Rippling)
• Recruiting (Greenhouse, Lever, Ashby)
• Forms (Typeform, Jotform, Google Forms)
• Surveys (SurveyMonkey, Qualtrics)
• eSign (DocuSign, HelloSign, PandaDoc)
• Notifications from SaaS tools (Slack, Asana, Notion, Figma, GitHub, Linear, etc.)
• Internal tooling (alerting systems, CI/CD notifications)

Cross-reference this list with your existing SPF record and DKIM selectors. Then publish DMARC in monitoring mode.

#Stage 2: DMARC monitoring

_dmarc.valtikstudios.com. IN TXT "v=DMARC1. P=none. Rua=mailto:dmarc-rua@dmarcreports.valtikstudios.com. Pct=100"

p=none tells receivers: "I am not asking you to change how you deliver email. Just send me reports." The reports start flowing within 24 hours from Gmail, Microsoft, Yahoo, and most major providers.

Use a DMARC report processor:

• dmarcian (https://dmarcian.com/). Established, good UI, priced by volume
• EasyDMARC (https://easydmarc.com/). Aggressive pricing, solid feature set
• Valimail (https://www.valimail.com/). Enterprise, integrates with SEGs
• URIports (https://uriports.com/). Budget option
• Postmark DMARC Monitoring. Free, DMARC (not TLS-RPT or MTA-STS reports)

Run monitoring for at least 30 days. You want to see:

• All legitimate senders show "fully aligned" (both SPF and DKIM pass and align)
• Any legitimate senders that fail alignment. These need to be fixed (usually by enabling DKIM on the sending service or by using a subdomain with its own SPF record)
• All the unauthorized senders attempting to impersonate your domain

#Stage 3: quarantine with ramping pct

Once all legitimate senders are fully aligned, move to quarantine:

_dmarc.valtikstudios.com. IN TXT "v=DMARC1. P=quarantine. Pct=10. Rua=mailto:dmarc-rua@dmarcreports.valtikstudios.com"

Starts with 10% of failing messages going to spam. If no legitimate mail gets trapped over 2-3 days, bump to 25%, then 50%, then 100%. Monitor reports the whole time.

#Stage 4: reject

_dmarc.valtikstudios.com. IN TXT "v=DMARC1. P=reject. Rua=mailto:dmarc-rua@dmarcreports.valtikstudios.com. Adkim=s. Aspf=s"

At this point unauthorized senders get outright rejected by compliant receivers (which is most of the inbox volume in 2026). Alignment bumped to strict. No subdomain tricks.

#What Gmail and Microsoft enforce in 2026

#Gmail (Google's bulk sender requirements, in effect since Feb 2024)

For senders sending more than 5,000 emails per day to Gmail:

• SPF required. Must pass
• DKIM required. Must pass
• DMARC required. Must have a record (even p=none counts, but strongly recommend quarantine or reject)
• Alignment required. From domain must align with SPF or DKIM
• One-click unsubscribe required for marketing email
• Spam rate under 0.3% reported through Postmaster Tools. Above 0.3% is warning, above 0.5% is throttling/blocking

Non-compliance for Gmail bulk senders doesn't mean spam folder. It means hard blocks.

#Microsoft 365 / Outlook.com (in effect since May 2025)

Microsoft mirrored Google's requirements with phased rollout:

• SPF, DKIM, DMARC required for bulk senders (>5,000 per day)
• Temporary soft failures for non-compliant senders since May 2025
• Hard rejections phased in through 2025-2026

#Yahoo and AOL

Aligned with Gmail's requirements as part of the original Yahoo/Google joint announcement in 2023.

#Apple Mail (iCloud)

Doesn't publish a hard block threshold but honors DMARC policies as set. Apple Mail Privacy Protection adds complexity for marketers (pre-fetches images, obscures open tracking).

#BIMI: the logo in the inbox

Brand Indicators for Message Identification. When properly configured, your company logo appears next to messages in Gmail, Apple Mail, Yahoo Mail, and Fastmail.

Requirements:

1. DMARC at p=quarantine or p=reject (pct=100)
2. Logo in SVG Tiny PS format (specific subset of SVG, not any SVG)
3. Logo hosted on HTTPS
4. VMC (Verified Mark Certificate). Issued by DigiCert or Entrust, based on trademark verification

Costs:

• VMC from DigiCert or Entrust: ~$1,200-$1,600/year
• Logo conversion to SVG Tiny PS: handled by VMC issuer or in-house
• Trademark must be registered in USPTO, EUIPO, or other major registry

BIMI DNS record:

default._bimi.valtikstudios.com. IN TXT "v=BIMI1. L=https://assets.valtikstudios.com/bimi-logo.svg; a=https://assets.valtikstudios.com/bimi-vmc.pem"

Apple Mail added BIMI support in iOS 16 (2022). Gmail has shown BIMI logos since 2021. Yahoo since 2020. Apple requires VMC; Gmail previously allowed CMC (Common Mark Certificate) for unregistered marks but tightened to VMC in 2024.

#Related protocols worth knowing about

#MTA-STS (Mail Transfer Agent Strict Transport Security)

RFC 8461. Policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt tells sending MTAs to use TLS when delivering to your domain and which certificates to trust.

# mta-sts.txt
version: STSv1
mode: enforce
mx: *.yourdomain.com
mx: mail.yourdomain.com
max_age: 86400

DNS record:

_mta-sts.valtikstudios.com. IN TXT "v=STSv1. Id=20260415000000"

#TLS-RPT (SMTP TLS Reporting)

RFC 8460. Reports on TLS failures from sending MTAs.

_smtp._tls.valtikstudios.com. IN TXT "v=TLSRPTv1. Rua=mailto:tls-rpt@valtikstudios.com"

#DNSSEC

Without DNSSEC your SPF, DKIM, and DMARC records can be tampered with by DNS attackers. All modern email authentication assumes the DNS responses are authentic. If your domain doesn't have DNSSEC, the whole chain is weaker.

#Common mistakes we find on audits

Multiple SPF records. DNS returns two TXT records both starting with v=spf1. Receivers treat this as a PermError. Only one SPF record per domain. If you need to authorize multiple sources, they all go in the one record with include: directives.

SPF record exceeding 10 lookups. Silent failure. Emails start soft-failing SPF. DMARC alignment breaks. BEC protection degrades.

DKIM key still at 1024 bits. Many older implementations default to 1024. Google Workspace lets you switch to 2048 from the admin console with one click. Do it.

p=reject without monitoring legitimate traffic. The HR onboarding emails that go through a SaaS vendor nobody remembered now bounce. HR calls IT. IT calls you. You walk back to p=none and lose a month of DMARC maturity.

Subdomains not covered. p=reject on the root doesn't automatically cover marketing.yourdomain.com unless sp=reject is also set. Common failure: p=reject on root, no sp=, attackers start spoofing accounting.yourdomain.com because the subdomain has no DMARC record at all.

BIMI without DMARC enforcement. BIMI requires p=quarantine or p=reject with pct=100. Setting pct=50 or p=none disables BIMI display silently.

DKIM set up for the primary sender but not for transactional. Gmail's bulk requirements check every sender, not the one you configured. SendGrid/Postmark/Mailgun all need their own DKIM records set up on their selector subdomains.

Not enabling "enforce MTA-STS". Policy file at testing or none doesn't block opportunistic TLS downgrade attacks. Must be enforce for protection.

Forgetting old vendors in the SPF record. The Mailchimp account from 2019 was cancelled but the include:servers.mcsv.net is still there. When Mailchimp eventually changes their SPF include structure, your record might break.

#Exact config walkthroughs

#Google Workspace

1. Admin console → Apps → Google Workspace → Gmail → Authenticate email
2. Generate DKIM key (2048-bit)
3. Add the provided TXT record at google._domainkey.yourdomain.com
4. After DNS propagation, click "Start authentication"
5. For SPF, publish: v=spf1 include:_spf.google.com ~all (or add other includes before ~all)
6. For DMARC, start with p=none and a reporting mailbox
7. Enable enhanced pre-delivery scanning for inbound email
8. Enable Postmaster Tools (postmaster.google.com) to monitor outbound reputation

#Microsoft 365

1. Security portal (security.microsoft.com) → Email & collaboration → Policies & rules → Threat policies → Email authentication settings
2. Enable DKIM for each domain. This creates selector1 and selector2 records
3. Add the two CNAME records pointing to selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com and selector2-yourdomain-com._domainkey.yourtenant.onmicrosoft.com
4. Rotate DKIM keys on a schedule (auto-rotation available since 2024)
5. SPF: v=spf1 include:spf.protection.outlook.com -all
6. DMARC: start with p=none, move to quarantine, then reject
7. Enable Microsoft Defender for Office 365 advanced features (anti-phishing, impersonation detection)

#Self-hosted (Postfix + OpenDKIM + OpenDMARC)

For the rare case of running your own mail. This is a bad idea in 2026 for deliverability reasons but sometimes necessary.

• OpenDKIM for signing
• Publish DKIM public key in DNS
• SPF record for the sending server's IP
• DMARC record with p=none during bootstrap
• Monitor DMARC reports through a third-party processor
• Warm up the sending IP gradually (start at 50 emails/day, double every few days)
• Expect significant deliverability issues for the first 6-12 months even with everything configured correctly

#Monitoring tools

Domain authentication checkers (free):

• mxtoolbox.com
• dmarcian.com/dmarc-inspector
• easydmarc.com/tools
• learndmarc.com (interactive simulation)

DMARC aggregate report processors:

• dmarcian (tier-priced, $20-$1000+/mo)
• EasyDMARC (free tier + paid)
• Postmark DMARC (free, email-only)
• Valimail (enterprise)
• URIports (budget)

Email security platforms (inbound protection):

• Proofpoint Email Protection
• Mimecast
• Abnormal Security (AI-based BEC detection)
• Avanan (Check Point)
• Microsoft Defender for Office 365
• Google Workspace security add-ons (BeyondCorp, context-aware access)

#Hire Valtik Studios

Email authentication audits are part of our standard security baseline engagement. We review your SPF, DKIM, DMARC, BIMI, MTA-STS, and DNSSEC setup, identify alignment gaps. And produce a remediation roadmap that gets you from p=none to p=reject without breaking production. If you're a Covered Entity under NYDFS or a CMMC-pursuing defense contractor, we include this as part of a broader compliance review.

Reach us at valtikstudios.com.