Key takeaways

  • SPF says which servers may send for your domain, DKIM signs each message, and DMARC tells receivers what to do when the checks fail and sends you reports.
  • Google and Yahoo set requirements for bulk senders in 2024, and Outlook.com set its own for high-volume senders in 2025. All three expect SPF, DKIM and a published DMARC policy.
  • A DMARC policy of none satisfies the minimum requirements but does not stop spoofing. Protection comes when you move to quarantine or reject after reviewing your reports.
  • A resilient mail platform is the product of routine work: prompt patching, supported software versions, replicated databases, tested failover and monitoring.

Why email authentication is now a business issue

Email was designed without a reliable way to prove who sent a message. Anyone can put your domain in the From line of a message. That weakness powers phishing, invoice fraud and impersonation of executives. It also means that mailbox providers have to decide, for every message, whether it is real. When your own legitimate mail fails that test, it lands in spam or is rejected.

Three standards address the problem: SPF, DKIM and DMARC. Together they let a receiving server check that a message claiming to come from your domain was really sent by or for you. They protect your brand from spoofing, they protect your clients and staff from fraud, and since 2024 the largest mailbox providers have made them a condition of reliable delivery for senders at scale.

SPF, DKIM and DMARC in plain terms

SPF, the Sender Policy Framework, is a DNS record on your domain that lists the servers and services allowed to send mail for it. A receiving server looks up the record and checks whether the connecting server is on the list. SPF has practical limits. The specification limits a record to 10 mechanisms and modifiers that cause DNS lookups, and exceeding the limit produces a permanent error. Companies that add a marketing platform, a ticketing tool, a CRM and an invoicing service can hit that limit without noticing.

DKIM, DomainKeys Identified Mail, adds a cryptographic signature to each outgoing message. The sending system signs selected parts of the message with a private key. The matching public key is published in DNS under a selector. A receiver uses it to confirm that the message was signed by the domain and was not altered in transit. Each sending service you use should sign with your domain, not only with its own.

DMARC, Domain-based Message Authentication, Reporting and Conformance, builds on both. It ties the checks to the domain people actually see in the From header through a concept called alignment: SPF or DKIM must pass, and the domain that passed must match the From domain. The DMARC record then states a policy for messages that fail. Under RFC 7489 the options are none, where the receiver is asked to take no specific action, quarantine, where failing mail should be treated as suspicious, and reject, where failing mail should be refused during the SMTP transaction. The record can also include a reporting address. Those aggregate reports show which systems are sending mail as your domain, and they are how you find forgotten services before you tighten the policy.

What Google, Yahoo and Microsoft require

Google and Yahoo announced requirements for bulk senders that took effect in 2024, and Microsoft followed for Outlook.com in 2025. The details differ slightly, but the pattern is consistent.

  • Google: starting February 1, 2024, senders of more than 5,000 messages per day to Gmail accounts must set up SPF and DKIM, set up DMARC (the enforcement policy can be none), have valid forward and reverse DNS for sending IPs, use a TLS connection, keep spam rates reported in Postmaster Tools below 0.30 percent, format messages according to RFC 5322, and align the From domain with the SPF or DKIM domain. Marketing and subscribed messages must support one-click unsubscribe and include a visible unsubscribe link. All senders to Gmail, regardless of volume, must also meet baseline requirements such as SPF or DKIM, valid DNS records, TLS and low spam rates.
  • Yahoo: all senders need to authenticate with SPF or DKIM at a minimum and keep spam rates below 0.3 percent. Bulk senders must implement both SPF and DKIM and publish a valid DMARC policy of at least p=none, with the From domain aligned to either the SPF or DKIM domain. They must also support easy unsubscribe with a working list-unsubscribe header, where the one-click POST method of RFC 8058 is highly recommended.
  • Microsoft: for domains sending more than 5,000 emails per day to Outlook.com, SPF and DKIM must pass and DMARC must be published with at least p=none and aligned with SPF or DKIM, preferably both. After May 5, 2025, Outlook began routing messages from non-compliant high-volume domains to the Junk folder. Microsoft stated that, on a date to be announced (its post, last updated in April 2025, gave no date; some administrators report 550 5.7.515 rejections already), non-compliant messages will be rejected with an error such as 550 5.7.515.

Two points deserve emphasis. First, the thresholds are defined by volume to those providers, but the requirements are sound for every sender. A ten-person firm that sends invoices and proposals benefits from the same authentication. Second, a DMARC policy of none meets the published minimum, but it only monitors. It does not instruct receivers to block spoofed mail. Google's guidance also notes that it applies stricter enforcement to impersonation of Gmail From addresses.

A safe path to DMARC enforcement

Moving straight to reject is how companies lose their own mail. The safe sequence is gradual.

  • Inventory every system that sends as your domain: your mailboxes, marketing and newsletter tools, billing, support desk, CRM, website forms, scanners and applications.
  • Publish SPF and DKIM for each legitimate sender, keeping the SPF record within the lookup limit.
  • Publish DMARC at p=none with a reporting address, and read the reports for several weeks.
  • Fix what the reports show: unknown senders that are legitimate, misaligned services, and forgotten systems.
  • Move to quarantine, and then to reject, once legitimate traffic passes consistently. Many organizations phase this in using the policy's percentage option.
  • Keep monitoring. Every new tool that sends email needs to be added to the plan.

Cloud sending services belong on that inventory. Amazon Simple Email Service (Amazon SES) is one example: an application that sends mail through it must be covered by your SPF record and signed with a DKIM key for your domain, or the messages will fail DMARC. The same applies to Microsoft 365, Google Workspace and any marketing platform. DNS hosts hold these records, whether that is Amazon Route 53, Oracle Cloud Infrastructure (OCI) DNS or your own servers, so keep change control on them.

Once your domain is at enforcement, spoofed messages that claim to come from you are blocked by participating receivers. That reduces the risk of someone impersonating your CEO to your customers or your accounts payable team. It does not stop attacks from lookalike domains or from compromised real accounts, so it is one layer, not a complete defense. Multi-factor authentication, inbound filtering and staff training remain essential.

Running Exchange and Microsoft 365 resiliently

Authentication protects your reputation. Resilience protects your ability to send and receive at all. Email is a system that staff notice within minutes when it fails, so the platform behind it needs routine care. Most organizations today use Exchange Online in Microsoft 365, some still run Exchange Server on premises, and many run a hybrid of the two. The right operating practices differ slightly, but the principles are the same.

Patching and supported versions

Exchange servers are a high-value target, and an unpatched server is an open door. In August 2025, CISA issued Emergency Directive 25-02 about a vulnerability in Exchange hybrid configurations (CVE-2025-53786) that could let an attacker who already has administrative access to an on-premises Exchange server move laterally into the Microsoft 365 cloud environment. Its required actions included inventorying Exchange servers with Microsoft's Health Checker script, disconnecting end-of-life servers, updating to the latest supported cumulative update and applying the April 2025 hotfix updates. The directive applied to federal agencies, but the lesson applies to everyone.

Version support matters as much as patch speed. Microsoft's documentation states that Exchange Server 2016 and 2019 are out of support, that customers who enrolled in the Extended Security Update program are eligible to receive the December 2025 and later security updates for those versions, and that anyone not in that program should migrate to Exchange Server Subscription Edition to keep receiving the latest security updates. A server that no longer receives fixes is a liability regardless of how well it is administered.

A disciplined patch practice for Exchange includes the following.

  • An accurate inventory of every Exchange server, its cumulative update level and its support status
  • A schedule to apply security updates promptly, tested first in a non-production environment when one exists
  • A rollback plan and a recent, restorable backup before every change
  • Post-update validation with the vendor's health checks, and monitoring for known issues
  • A plan to retire end-of-life servers, including the last Exchange server left after a move to the cloud, as CISA's directive recommended where appropriate
  • Attention to the operating system, the web server components, and the hybrid configuration, not only Exchange itself

Failover by design

For Exchange Server, Microsoft's high availability framework is the database availability group, or DAG. A DAG is a group of up to 16 Mailbox servers that hosts a set of databases and provides automatic database-level recovery from failures that affect individual servers or databases. Any server in the group can host a copy of a mailbox database from any other server. When a disk, server or network fails, a component called Active Manager performs a switchover or failover, so a copy on another server becomes active. DAGs also use a witness server to help keep the group consistent. Every server in a DAG must run the same version of Exchange.

A DAG is not a backup. It replicates changes, including mistakes and malicious deletions, to the other copies. A resilient design therefore pairs high availability with independent, tested backups, and it places copies in separate failure domains such as separate hosts, storage and, where the business needs it, separate sites. It also covers the pieces around the database: redundant DNS, certificates that are tracked and renewed before they expire, redundant mail gateways or filtering, and load balancing for client access.

For Microsoft 365, Microsoft operates the underlying infrastructure, but the customer still owns the configuration and the data protection decisions. A resilient tenant has multi-factor authentication and conditional access, administrator accounts that are separated and monitored, mail flow rules and connectors that are documented, retention and independent backup of mailboxes, a tested process for restoring deleted items, and a way to keep communicating if the service is unavailable, such as an out-of-band channel.

Monitoring and rehearsal

Resilience is not proven by a diagram. It is proven by drills. A well-run platform monitors mail queues, replication health, certificate expiry, disk space and authentication failures, and alerts a person who can act. It rehearses a server loss, a database restore and a tenant-level incident on a schedule, writes down the time each takes, and fixes what the drill exposes. It also reviews DMARC reports regularly, because a sudden change in who is sending as your domain is often the first sign of an attack.

A checklist to take away

  • SPF, DKIM and DMARC published for every domain you own, including parked domains that never send mail
  • A DMARC reporting address that someone reads, and a plan with dates to reach quarantine or reject
  • A current inventory of everything that sends email as your domain
  • Exchange versions that are still supported, patched on a schedule, with health checks after each update
  • Replicated mailbox databases, independent backups and a documented, tested restore
  • Multi-factor authentication and conditional access for all mailboxes, with extra care for administrators

Clayton Cybernetics provides managed IT services that include email authentication, Exchange and Microsoft 365 administration, patching, monitoring and recovery testing. If you are not sure what your DMARC reports would show, that is the right place to start.

Sources

This article is general information, not legal or technical advice for your environment. Provider requirements change; confirm current rules in each provider's documentation, and test DNS and policy changes before you enforce them. Product names are trademarks of their owners. Last reviewed .

Keep reading

Need help with this?

Your entire IT operation, run by engineers who have operated infrastructure for global enterprises.

Managed IT Services