Email delivery has changed more in the last two years than in the previous decade combined. As of 2024, authentication is no longer optional for serious senders. Major providers such as Google, Yahoo, and Microsoft now require SPF, DKIM, and at least a baseline DMARC policy for bulk email senders.
For anyone sending at scale, especially in B2B outbound or transactional workflows, unauthenticated email is effectively treated as suspicious by default. That means degraded inbox placement, spam routing, or full rejection depending on the recipient infrastructure.
This article walks through the full email authentication stack in the correct implementation order: SPF, DKIM, DMARC, ARC, and BIMI. More importantly, it explains how these standards work together, why configuration alone is not enough, and why continuous monitoring is now part of the infrastructure rather than an optional add-on.
TL;DR: Google, Yahoo, and Microsoft now require SPF, DKIM, and at least a baseline DMARC policy from bulk senders, so unauthenticated mail gets filtered or rejected by default. Build the stack in order: SPF authorizes your sending infrastructure, DKIM signs messages so recipients can confirm they were not altered, and DMARC ties both to your visible From domain and tells providers what to do when they fail. Move DMARC from monitoring (p=none) to enforcement (p=quarantine, then p=reject) once reporting shows your legitimate mail passing. ARC preserves authentication through forwarding and mailing lists, and BIMI displays a verified logo once enforcement is in place. The part teams underestimate is drift: a new sending tool, a rotated key, or an SPF record that quietly exceeds its ten-lookup limit will break the chain without any visible signal, which is why hourly monitoring matters as much as the original setup.
What is email authentication, and why does it matter?
Email authentication is a collection of DNS-based standards that allow receiving mail servers to verify three things: whether a message genuinely came from the domain it claims, whether it was altered in transit, and whether the sender was authorized to use that domain.
At the core of the problem is the original design of SMTP. It was built without sender verification, which means anyone can technically send an email claiming to be from any domain. Authentication protocols exist to close this structural gap and restore trust in the system.
The scale of abuse is significant. Email remains the dominant entry point for cyberattacks, with CISA reporting that more than 90% of successful attacks begin with a phishing email. The volume of targeted attempts is equally striking: Proofpoint's State of the Phish reporting notes that it detects and blocks an average of 66 million Business Email Compromise attacks every month.
In practice, authentication provides a trust signal to receiving servers. When configured correctly, it improves inbox placement, reduces spoofing risk, and protects a domain from being used in phishing attacks. When missing, the domain becomes easy to impersonate and harder to trust.
What the 2024–2025 enforcement changes mean for senders
The shift toward enforcement began in early 2024 when Google and Yahoo introduced mandatory authentication requirements for bulk senders, defined as those sending 5,000+ emails per day. These requirements include SPF, DKIM, and a minimum DMARC policy of at least p=none. Microsoft followed with similar expectations across Outlook and Microsoft 365 ecosystems in 2025, aligning major inbox providers around a shared baseline.
The direction of travel is just as important as the current rules. p=none is no longer seen as a long-term state but as an onboarding phase. Providers have clearly signaled that enforcement will progress toward p=reject as the industry standard over time.
Despite this, adoption remains uneven. The Mailgun and Sinch State of Email Deliverability 2023 report found that only 55.4% of senders used SPF, 58.5% used DKIM, and just 42.5% had DMARC in place. A further 30–39% of respondents were unsure whether authentication was configured at all.
The Senior Director of Product at Yahoo, Marcel Becker, has noted in a commentary cited by Email on Acid that these requirements are not new ideas but long-established best practices that are now being enforced at the infrastructure level. For more details on current requirements, see our Google Bulk Sender Guidelines.
How email authentication works: the technical foundation
Email authentication operates through a simple but strict sequence. A domain owner publishes DNS TXT records for SPF, DKIM, and DMARC. When an email arrives, the receiving server queries DNS to retrieve these records and validates the message against them.
If checks pass, the email is treated as legitimate traffic. If they fail, the message may be routed to spam, quarantined, or rejected entirely, depending on the receiver’s policy.
This entire system depends on DNS, which introduces an operational reality many teams underestimate: propagation delays. Changes can take 24–48 hours to fully propagate, and even small formatting errors can silently break authentication without obvious delivery failures.
The stack can be summarized as follows:
Read the right-hand column as a sequence rather than a list. DKIM does not help if SPF is broken, DMARC cannot enforce anything unless one of the two passes and aligns, and BIMI is unavailable until DMARC is at enforcement.
SPF: who is authorized to send from your domain?
SPF (Sender Policy Framework) defines which servers are allowed to send email on behalf of your domain. It works by publishing a DNS TXT record listing authorized IP addresses and third-party sending services.
A typical SPF record includes mechanisms like v=spf1, include: statements for services, and ip4: or ip6: entries. The final qualifier, usually ~all (SoftFail), indicates how strictly unauthorized mail should be treated. For most organizations, SoftFail is safer during gradual rollout.
However, SPF has a fundamental limitation: it validates the envelope sender (Return-Path), not the visible “From” address. This means an attacker can pass SPF checks while still spoofing the displayed sender identity.
Another operational issue is forwarding. When an email is forwarded, the forwarding server’s IP is not included in the original SPF record, which often causes SPF to fail even for legitimate messages.
There is also a hard technical constraint: SPF allows a maximum of 10 DNS lookups. Modern B2B stacks using multiple tools such as CRM platforms, sales engagement tools, and transactional email providers frequently exceed this limit, causing authentication failure at scale.
DKIM: is this email really from you, and has it been altered?
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each outgoing email. This signature is created using a private key held by the sender and verified using a public key stored in DNS.
In simple terms, the private key “signs” the message, and the public key allows receivers to confirm it has not been tampered with.
DKIM provides two critical assurances: sender identity and message integrity. Unlike SPF, it can survive forwarding, because the signature travels with the message rather than depending on the sending IP. The caveat is that it only survives if the message is not modified in transit. Mailing lists and some forwarding services add footers or rewrite subject lines, and any such change breaks the signature, which is the problem ARC exists to solve.
However, DKIM has its own limitations. The signing domain (defined in the d= tag) can differ from the visible “From” address. This creates a gap that attackers can still exploit unless DMARC alignment is enforced.
Key management is also important. DKIM keys should be rotated at least once or twice per year. Many organizations use dual selectors during rotation to avoid breaking authentication for messages already in transit. Shared DKIM keys provided by ESPs can also introduce risk if not properly isolated.
DMARC: what should happen when authentication fails?
DMARC (Domain-based Message Authentication, Reporting and Conformance) builds on SPF and DKIM by introducing domain alignment. It ensures that the authenticated domain matches the visible “From” domain that users actually see.
For DMARC to pass, either SPF or DKIM must pass and align with the From domain. This alignment is what closes the spoofing gap left open by SPF and DKIM individually. DMARC policies operate in three stages:
A p=none policy allows all mail through but collects reports. This is the monitoring phase and is where most organizations should start. It provides visibility without disrupting delivery.
A p=quarantine policy moves failing emails into spam folders. This is the intermediate enforcement stage.
A p=reject policy blocks unauthenticated email entirely. This is the end goal for mature senders and is also a requirement for BIMI. Although Gmail and Yahoo currently require a minimum DMARC policy of p=none for bulk senders, their long-term direction is toward stronger enforcement.
DMARC also generates aggregate XML reports sent to the address specified in the rua tag. These reports show sending sources, pass/fail rates, and unauthorized usage of the domain. However, DMARC is still affected by forwarding scenarios where authentication breaks. ARC helps mitigate this, which we will cover next.
ARC: how authentication survives forwarding and mailing lists
ARC (Authenticated Received Chain) exists to solve one specific problem: legitimate mail failing DMARC because somebody forwarded it. Forwarding breaks authentication in two ways at once: (1) the forwarding server changes the sending IP, so SPF fails because that IP was never in your authorization list, and (2) mailing lists add footers or rewrite subject lines, which breaks the DKIM signature. DMARC needs one of the two to pass and align, meaning a legitimate message can fail every check purely by being forwarded.
ARC preserves authentication results by adding a signed chain of custody to the message headers. This allows the final receiving server to see that the email was originally authenticated, even if intermediate steps break SPF or DKIM.
ARC does not replace SPF, DKIM, or DMARC. It only supports them in forwarding scenarios such as mailing lists, compliance gateways, or archiving systems. It also depends on the message being authenticated before forwarding occurs. In practice, ARC is important in enterprise environments but not a primary setup concern for most outbound teams.
BIMI: making authentication visible in the inbox
BIMI (Brand Indicators for Message Identification) is a visual layer built on top of authentication. It allows a verified brand logo to appear next to authenticated emails in supported inboxes. Supported providers include Gmail, Yahoo, Apple Mail, and Fastmail, while Microsoft uses a separate verified sender experience.
BIMI has a strict dependency on DMARC enforcement. A domain must have a policy of either p=quarantine or p=reject to qualify. This requirement forces organizations to fully implement authentication before gaining visual branding benefits.
A Verified Mark Certificate (VMC) is also required for major providers like Gmail and Yahoo. This certificate must be issued by an approved Mark Verifying Authority (the BIMI Group's current issuer list includes DigiCert, GlobalSign, and SSL.com), and the logo must be a registered trademark in SVG format.
Essentially, BIMI should be viewed as a trust enhancement, not a security mechanism. It does not protect email itself; it simply makes already-authenticated email more recognizable.
How to set up email authentication: where to start and what order to follow
Implementing email authentication is much easier when you follow the protocols in the right order. Each standard builds on the previous one, so rushing ahead to DMARC enforcement before SPF and DKIM are working correctly can block legitimate email instead of stopping malicious traffic.
Step 1: Set up SPF
Start by checking whether your domain already has an SPF record. Many email service providers create one automatically during setup, so creating a second SPF TXT record will cause a permanent authentication failure. Every domain should have only one SPF record that includes all authorized sending sources.
As you build your record, make sure every platform that sends email on behalf of your domain is included, whether that's Google Workspace, your CRM, a sales engagement platform, or a transactional email provider. B2B organizations often overlook one of these services, which causes legitimate emails to fail authentication.
It's also important to keep an eye on SPF's 10 DNS lookup limit. As more sending platforms are added over time, many organizations unintentionally exceed this limit, resulting in permanent SPF failures. Flattening or consolidating sending platforms is usually the fix, and it is worth checking the count before adding any new tool rather than after.
Step 2: Set up DKIM
Once SPF is in place, configure DKIM signing. Most email service providers generate a DKIM key pair as part of the sending setup, but you'll need to confirm whether you must publish the public key in your own DNS or whether your provider manages it automatically.
Use 2048-bit DKIM keys whenever possible, and plan to rotate your private keys at least once a year. During key rotation, use dual selectors so existing messages can still be verified while new messages are signed with the updated key. If your organization uses multiple sending platforms, you may also need multiple DKIM records.
Step 3: Set up DMARC at p=none first
After SPF and DKIM are passing consistently, publish a DMARC record using a policy of p=none. Although it may be tempting to move directly to full enforcement, starting with p=reject can cause legitimate email to be rejected if every authorized sender has not yet been authenticated.
Configure the rua= tag to receive aggregate DMARC reports. These XML reports show every service sending email on behalf of your domain, how often SPF and DKIM pass or fail, and whether unauthorized sources are attempting to impersonate your domain. Monitor these reports for at least two to four weeks before moving to enforcement.
Step 4: Advance DMARC to p=quarantine, then p=reject
Once every legitimate sending source is authenticated and consistently passing DMARC, move your policy to p=quarantine. Continue monitoring your reports carefully to ensure legitimate messages are not being routed to recipients' spam folders.
After confirming there are no unexpected authentication failures, advance to p=reject. This is the recommended end state because it prevents unauthorized email from reaching recipients entirely. Moving to p=reject too early can interrupt legitimate business communications, so only enforce it once you're confident every authorized sender has been identified.
Step 5: Consider BIMI once enforcement is in place
BIMI should be the final step, not the first. It only becomes available once DMARC enforcement is set to p=quarantine or p=reject, and it also requires a registered trademark and a Verified Mark Certificate (VMC).
For most organizations, completing SPF, DKIM, and DMARC enforcement will have a much greater impact on deliverability and domain protection than adding a branded logo in recipients' inboxes.
Authentication and B2B outbound email: what sales and RevOps teams need to know
Authentication becomes more complex in B2B outbound environments because email is often sent through multiple platforms, domains, and subdomains. Without careful management, small configuration issues can quietly undermine deliverability across an entire outbound program.
Why subdomains matter for outbound authentication
Many organizations use dedicated subdomains for cold outreach to protect the reputation of their primary domain. However, every subdomain used for outbound email requires its own SPF and DKIM configuration. A subdomain without authentication records will fail authentication immediately, regardless of whether the root domain is configured correctly.
DMARC also requires careful planning. Unless you publish a separate DMARC record for a subdomain, it inherits the policy of the parent domain. For example, if your root domain enforces p=reject and an outbound subdomain is not authenticated correctly, an email sent from that subdomain may be automatically rejected. Our guide on email subdomain best practices explains how to configure this safely.
Multi-tool SPF management for B2B teams
Modern B2B teams often send emails through Google Workspace, HubSpot, Outreach, Salesloft, and transactional email providers simultaneously. Every additional platform adds DNS lookups to the SPF record, bringing the domain closer to the 10-lookup limit.
Review your SPF record regularly as new tools are introduced. Some organizations use SPF flattening to reduce lookup counts, but this approach requires ongoing maintenance because provider IP ranges can change over time. If you're using Outreach or Salesloft, make sure those platforms are properly incorporated into your authentication strategy.
Authentication in sales engagement platforms
Sales engagement platforms do not all send email the same way. Some send through their own infrastructure, while others send directly from your Microsoft 365 or Google Workspace account. If the platform sends on behalf of your own domain, its infrastructure must be authorized within your SPF record.
Where available, enable custom DKIM signing so outbound messages are signed using your own domain rather than the provider's domain. This improves DMARC alignment and strengthens your overall sender identity. Our deliverability guides for Outreach and Salesloft cover these platform-specific considerations in more detail.
What an authentication failure looks like in cold outbound
Authentication failures are rarely obvious. Messages continue to send successfully, but instead of reaching the inbox, they begin landing in spam folders or being filtered before recipients ever see them. As engagement declines, sender reputation weakens further, making future campaigns even more difficult to deliver.
When diagnosing poor outbound performance, start by checking SPF, DKIM, and DMARC pass rates in Google Postmaster Tools. Next, review your domain reputation and confirm your domain or sending IPs are not listed on major blocklists. Finally, review authentication alongside other deliverability factors such as list quality and sending practices. Our guides on Google Postmaster Tools, email blocklists, and cold email deliverability provide a structured troubleshooting process.
Why authentication alone is not enough: the monitoring gap
Authentication is not a one-time configuration task. It is an evolving system that changes whenever your infrastructure changes. Common failure scenarios include adding a new email tool without updating SPF, rotating DKIM keys incorrectly, creating new subdomains without authentication records, or exceeding SPF lookup limits as tools accumulate over time.
These issues often go unnoticed because authentication failures are silent. Emails are still sent, but inbox placement gradually deteriorates. Monitoring DMARC reports is essential, but they are often complex XML files that require parsing. Tools like Google Postmaster Tools provide partial visibility, but only for Gmail traffic.
This is where continuous monitoring becomes critical. In high-volume B2B environments, even a single misconfiguration can disrupt entire outbound sequences for weeks before it is detected manually.
Platforms like Allegrow provide hourly SPF, DKIM, and DMARC monitoring to detect authentication drift early, before it impacts deliverability. This is particularly important for teams running large-scale outbound programs where domain reputation directly impacts revenue.
Conclusion
Email authentication is no longer a technical best practice buried in DNS settings. It is now a core requirement for deliverability across major providers.
The shift since 2024 is enforcement, and it changes what maintaining authentication looks like. A correct setup is a starting point rather than a finished state, because every new sending tool, key rotation, and subdomain can break something that was working the week before.
For B2B teams running outbound at volume, this is not an infrastructure detail. A domain that quietly falls out of alignment takes the pipeline with it, and nothing in the sending platform will tell you it happened.
If you want to ensure your authentication stack is correctly configured and continuously monitored, you can run a full domain audit and test your setup in real conditions with Allegrow. Start your 14-day free trial and verify up to 1,000 addresses while identifying deliverability risks before they impact your outbound performance.
FAQ
What is email authentication?
Email authentication is a set of DNS-based protocols that verify whether an email is genuinely sent from the domain it claims to represent. It protects against spoofing by validating sending sources and message integrity using SPF, DKIM, DMARC, ARC, and BIMI.
Do I need all three of SPF, DKIM, and DMARC?
Yes. Modern inbox providers, including Google and Yahoo, require all three for bulk senders. Each protocol covers a different gap, and none is sufficient alone to prevent spoofing or ensure deliverability.
What is the difference between SPF and DKIM?
SPF validates which servers are allowed to send email for a domain based on IP addresses. DKIM validates the identity of the sender and ensures the message has not been altered in transit using cryptographic signatures. SPF can fail during forwarding, while DKIM usually survives it.
What does DMARC p=none actually do?
p=none is a monitoring-only policy. It does not block or quarantine emails but generates reports that show authentication results and unauthorized sending activity. It is intended as a setup phase, not a permanent configuration.
What is ARC, and when do I need it?
ARC preserves authentication results when email is forwarded through intermediate servers such as mailing lists or security gateways. It is useful in enterprise environments but is not required for basic outbound email setups.
What is BIMI, and do I need it?
BIMI displays a verified brand logo in supported inboxes, but only works when DMARC is enforced at p=quarantine or p=reject. It requires a Verified Mark Certificate and should only be implemented after core authentication is fully stable.
How do I check if my email authentication is set up correctly?
You can check authentication headers in Gmail, validate DNS records using lookup tools, and review DMARC aggregate reports. Tools like Google Postmaster Tools also provide domain-level insights into authentication and spam rates.
Why is my DMARC failing even though SPF and DKIM pass?
This usually happens due to domain misalignment. SPF or DKIM may pass, but the authenticated domain does not match the visible From address. This is common when using third-party email platforms without proper custom DKIM configuration.
.jpg)