Skip to main content

What the New Email Authentication Requirements Mean for Your Domain

Erich Kolb

What changed and why it matters

In early 2024, Google and Yahoo began enforcing new email authentication requirements for anyone sending mail to their platforms. If your organization sends email from a custom domain, these changes affect you whether you send one message a day or ten thousand.

The short version: if your domain does not have SPF, DKIM, and DMARC configured correctly, your email will increasingly end up in spam folders or get rejected before it arrives. For organizations that rely on email to reach clients, partners, or prospects, this is not a theoretical problem.

The three standards you need to understand

SPF (Sender Policy Framework)

SPF is a DNS record that tells the world which mail servers are authorized to send email on behalf of your domain. When a receiving mail server gets a message claiming to be from yourcompany.com, it checks your SPF record to see if that server is on the approved list.

If you have never set up SPF, your domain has no such list, and receiving servers have no way to verify your messages are legitimate.

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to outgoing messages. The signature is tied to your domain and verified using a public key stored in DNS. A valid DKIM signature proves that the message was sent by someone in control of your domain and that the message body was not altered in transit.

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

DMARC is the policy layer that sits on top of SPF and DKIM. It tells receiving mail servers what to do when a message fails authentication checks: ignore it, quarantine it (send to spam), or reject it entirely.

DMARC also enables reporting. With a DMARC record in place, you receive aggregate reports from major mail providers showing which sources are sending email using your domain. This visibility is valuable even before you tighten your policy, because it lets you see legitimate sending sources you may not have known about.

What Google and Yahoo now require

For all senders:

  • A valid SPF or DKIM record for your sending domain
  • A DMARC record with at minimum p=none (monitoring mode)
  • A one-click unsubscribe link in marketing and bulk messages
  • Spam complaint rates below 0.3 percent (Google enforces this via Postmaster Tools)

For bulk senders (5,000 or more messages per day to Gmail addresses):

  • Both SPF and DKIM must be configured and passing
  • DMARC must be present
  • The "From" domain must align with either the SPF or DKIM domain

These are not suggestions. Google and Yahoo are actively rejecting or spam-filtering messages from domains that do not meet these requirements.

The three DMARC policy levels

DMARC has three policy settings, and knowing the difference matters when you are rolling this out.

p=none — Monitor only. Messages that fail authentication are delivered normally, but you receive reports. This is where most organizations should start. It lets you see what is sending email as your domain before you start blocking anything.

p=quarantine — Failed messages go to the spam folder. This is a meaningful enforcement step. Move here after you have reviewed your reports and confirmed all legitimate sending sources are authenticated.

p=reject — Failed messages are not delivered at all. This is the strongest protection against domain spoofing and phishing. It is the target state for most organizations, but you should not jump here without first validating your sending sources through the p=none monitoring phase.

What you should do now

Step 1: Check your current state

Use a free tool like MXToolbox or Google's Email Sender Guidelines checker to see whether your domain has SPF, DKIM, and DMARC records today and whether they are configured correctly.

Step 2: Add or fix your SPF record

Your SPF record needs to include every service that sends email on your domain's behalf: your Microsoft 365 or Google Workspace tenant, your CRM, your marketing platform, your ticketing system. Missing even one legitimate sender will cause authentication failures.

Step 3: Enable DKIM signing

Your email provider (Microsoft 365, Google Workspace, etc.) can generate a DKIM key pair for your domain. You publish the public key in DNS and the provider signs outgoing messages automatically. This is typically done in the admin console of your email platform.

Step 4: Add a DMARC record at p=none

Start with a monitoring-only policy and include a reporting address so you receive aggregate data. A basic record looks like this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourcompany.com;

Step 5: Review your reports and tighten the policy

After two to four weeks of reports, you will have a clear picture of your sending landscape. Authenticate any legitimate sources you discover, then move to p=quarantine. After another monitoring period, move to p=reject.

What happens if you do not act

Domains without proper authentication are increasingly treated as suspicious by default. Practically, this means:

  • Client-facing emails go to spam, including invoices and proposals
  • Transactional messages from your CRM or ticketing system never arrive
  • Attackers can more easily spoof your domain in phishing campaigns targeting your clients
  • Your domain's sender reputation degrades over time, making the problem harder to recover from

The good news is that SPF, DKIM, and DMARC are not expensive to implement. The records are DNS changes. The work is in the audit: identifying every service sending email as your domain and making sure each one is properly configured.

If you are unsure where to start or want someone to handle the audit and implementation, this is a straightforward project for a managed IT partner.

Ready to talk about your IT environment?

Thirty minutes is usually enough to understand your situation and sketch out what working together would look like.

Send a Message