BIPI
BIPI

Gmail and Yahoo's February Deadline Is Forcing Every Sender to Get Serious About DMARC

Cybersecurity

Starting February 2024, Gmail and Yahoo require SPF, DKIM, and DMARC for bulk senders. Half the enterprises we've audited will fail. Here's the rollout playbook that actually moves you to p=reject without breaking your mail flow.

By Arjun Raghavan, Security & Systems Lead, BIPI · January 16, 2024 · 6 min read

#email-security#spf#dkim#dmarc

Google and Yahoo announced in October 2023 that bulk senders (5,000+ messages per day to Gmail or Yahoo addresses) need SPF, DKIM, and DMARC by February 1, 2024. Unauthenticated mail will be rejected. The announcement created a small industry of consultants who suddenly remembered DMARC existed.

If your organization runs marketing campaigns, transactional email, or any kind of customer notifications, this is now compliance, not best practice. We've audited 14 enterprises since November 2023 for DMARC readiness. Three were ready. The rest had at least one third-party sender breaking DKIM alignment, a misconfigured SPF record, or a DMARC policy stuck at p=none for three years.

What the Three Records Actually Do

SPF tells receivers which IPs are allowed to send mail from your domain. Published as a TXT record at the apex (example.com). The lookup limit is 10 DNS lookups, which is the single most common cause of SPF failures in large enterprises with many third-party senders.

DKIM cryptographically signs the message. The sending server adds a DKIM-Signature header containing a signature over selected headers and the body. The receiving server fetches the public key from a DNS TXT record at selector._domainkey.example.com and verifies. Multiple selectors are normal, one per sending platform.

DMARC ties SPF and DKIM to the visible From address (RFC 5322). It requires alignment: either SPF passes for a domain that matches the From, or DKIM signs with a domain that matches the From. The DMARC record sets the policy (none, quarantine, reject), reporting addresses, and percentage rollout.

The Rollout Path That Works

  1. Publish a DMARC record with p=none and rua/ruf reporting addresses
  2. Collect aggregate reports for 4-6 weeks (use Dmarcian, Valimail, or PowerDMARC to parse the XML)
  3. Identify every sender, marketing platforms, transactional services, internal apps, shadow IT
  4. For each sender: add SPF include or DKIM selector, verify alignment in next batch of reports
  5. Move to p=quarantine; pct=10 once unknown sender volume drops below 1%
  6. Ramp pct up to 100% over 2-4 weeks while monitoring reports
  7. Move to p=reject; pct=100 once quarantine has been clean for 30 days

This typically takes 4-6 months end to end for a mid-size enterprise. The bottleneck is always identifying and reconfiguring third-party senders. Marketing teams use platforms IT doesn't know about. Sales teams send email through CRMs. Finance teams use invoice automation. Every one of them needs SPF and DKIM configuration.

The Lookup Limit Trap

SPF allows ten DNS lookups during evaluation. Each include: counts as one. Salesforce, Mailchimp, HubSpot, SendGrid, Microsoft 365, Google Workspace, and Marketo all use include: directives. Enterprises with five marketing platforms blow through the limit and SPF returns permerror, which DMARC treats as a fail.

The fix is SPF flattening, resolve all the includes ahead of time and publish the resulting IP list directly. Tools like Scrutinize, PowerDMARC, and Valimail flatten and auto-update the record. Don't hand-edit a flattened SPF; the upstream IPs change and you'll silently break mail.

What Breaks During Rollout

Mailing lists rewrite headers and break DKIM. Auto-forwarders strip authentication and break SPF. Internal apps that send via SMTP relays often forge From headers. Every one of those failure modes shows up in aggregate reports. Resist the urge to skip the reporting phase, going straight to p=reject without baseline reports will block legitimate mail.

After p=reject

DMARC isn't done at p=reject. Aggregate reports keep flowing. Watch for new sources that show up unexpectedly, they're either new legitimate senders or someone trying to spoof your domain. Both deserve investigation. A consistent volume of unaligned sends from random IPs is brand impersonation in progress.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.