What Changed and Why It Matters
Starting February 2024, Google and Yahoo implemented new requirements for anyone sending email to Gmail or Yahoo addresses. The requirements are not optional - if your domain doesn't comply, your emails will be rejected or sent to spam. This affects businesses of all sizes, and the impact is particularly severe for companies that send invoices, quotes, or regular client communications via email.
The three standards involved - SPF, DKIM, and DMARC - have existed for years as best practices. What changed is that the major email providers are now enforcing them as hard requirements rather than recommendations. If you've been sending email without these controls, your past success was partly luck.
The Three Things You Need
SPF (Sender Policy Framework)
An SPF record in your DNS tells receiving email servers which mail servers are authorized to send email on behalf of your domain. If an email arrives claiming to be from your domain but doesn't come from an authorized server, SPF allows the receiving server to reject it or flag it as suspicious. This prevents spoofing of your domain and establishes that your email is legitimate.
Getting SPF right requires knowing every service that sends email on your behalf - your mail server, your CRM, your invoicing platform, your marketing automation tool, and any newsletter service you use. Missing one can cause legitimate emails to fail SPF checks.
DKIM (DomainKeys Identified Mail)
DKIM adds a cryptographic signature to your outbound emails that allows receiving servers to verify the email genuinely came from your domain and wasn't tampered with in transit. It requires generating a key pair and adding the public key to your DNS records. Most modern email platforms (Microsoft 365, Google Workspace, etc.) support DKIM signing - but it needs to be explicitly configured for your domain.
DMARC (Domain-based Message Authentication, Reporting and Conformance)
DMARC builds on SPF and DKIM to tell receiving servers what to do when an email fails authentication checks: monitor it (p=none), quarantine it to spam (p=quarantine), or reject it outright (p=reject). It also provides a reporting mechanism so you can see who is sending email using your domain - which often reveals unauthorized use you didn't know about.
For the 2024 requirements, a DMARC policy of at least p=none is required. However, ThreeShield recommends moving to p=quarantine or p=reject once you've confirmed all legitimate senders are properly authenticated - a p=none policy stops the reports but doesn't stop spoofing of your domain.
The Concern: What Goes Wrong
The most common problems we see when assessing email authentication:
- Multiple conflicting SPF records - DNS allows only one SPF record. Multiple records cause authentication failures.
- SPF includes too many lookups - SPF has a limit of 10 DNS lookups. Using many third-party email services can exceed this.
- DKIM not configured for all sending services - Every platform that sends email on your behalf needs its own DKIM configuration.
- DMARC policy set to p=none indefinitely - This generates reports but provides no actual protection against spoofing.
- Subdomain DMARC not addressed - If you have subdomains that send email (e.g., billing.yourdomain.com), they need their own authentication configuration.
ThreeShield's Approach
For our managed clients, email authentication is part of our baseline security controls. We:
- Maintain a complete inventory of all services authorized to send email on your behalf
- Configure and maintain SPF records that cover all authorized senders
- Set up and monitor DKIM for all sending platforms
- Implement DMARC with monitoring and a roadmap to enforcement
- Review DMARC aggregate reports to identify unauthorized use of your domain
For organizations that haven't had this done, ThreeShield offers a one-time email authentication audit and remediation engagement - and for MSPs, Lavawall® includes domain security monitoring that flags missing or misconfigured DMARC, SPF, and DKIM records across your client base.