BlogEmail & SMTP
Email & SMTP

Email Authentication in 2026: DMARC Enforcement, BIMI, and Stopping Email Spoofing Permanently

Google and Yahoo now reject unauthenticated email. This guide covers SPF, DKIM, DMARC enforcement (from p=none to p=reject), BIMI brand indicators, and ARC for forwarding β€” with DNS records and troubleshooting for every step.

A

Alex Thompson

CEO & Cloud Architecture Expert at ZeonEdge with 15+ years building enterprise infrastructure.

February 4, 2026
22 min read

In February 2024, Google and Yahoo implemented strict email authentication requirements: bulk senders (5,000+ messages/day) must have SPF, DKIM, and DMARC configured, with a DMARC policy of at least p=none. Since October 2024, emails failing these checks are rejected outright β€” not sent to spam, rejected. Microsoft followed in 2025 with similar requirements for Outlook.com and Office 365.

These requirements are a forcing function that made the internet's email infrastructure measurably more secure. But "having DMARC" and "having DMARC enforced" are very different things. Most organizations set p=none (monitor only, don't block anything) and never progress to p=reject (block all unauthenticated email). This guide walks through the complete journey from zero email authentication to full enforcement with BIMI brand indicators.

The Three Pillars: SPF, DKIM, and DMARC

SPF (Sender Policy Framework)

SPF lets you publish a DNS record listing which mail servers are authorized to send email on behalf of your domain. When a receiving server gets an email from your domain, it checks the SPF record to verify that the sending server's IP is authorized.

; SPF record for zeonedge.com
; Allows: Google Workspace, your VPS mail server, and SendGrid
zeonedge.com. IN TXT "v=spf1 include:_spf.google.com ip4:5.161.224.7 include:sendgrid.net ~all"

; Breakdown:
; v=spf1          β€” SPF version 1
; include:_spf.google.com β€” Authorize Google Workspace servers
; ip4:5.161.224.7 β€” Authorize your VPS mail server
; include:sendgrid.net β€” Authorize SendGrid for transactional email
; ~all            β€” Soft fail everything else (change to -all for hard fail)

; Common mistakes:
; 1. Too many DNS lookups. SPF allows max 10 DNS lookups (includes count too).
;    Use "ip4:" for static IPs instead of "include:" to save lookups.
; 2. Using "+all" β€” this authorizes EVERYONE to send as your domain.
; 3. Multiple SPF records β€” you can only have ONE SPF TXT record per domain.

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to every outgoing email. The sending server signs the email with a private key, and the receiving server verifies the signature using the public key published in DNS. This proves the email wasn't modified in transit and was sent by an authorized server.

; DKIM public key record
; Selector: google (Google Workspace)
google._domainkey.zeonedge.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

; Selector: sg (SendGrid)
sg._domainkey.zeonedge.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqG..."

; Selector: mail (your own mail server)
mail._domainkey.zeonedge.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

; To verify DKIM is working:
; Send an email to check-auth@verifier.port25.com
; or check headers of received email for "dkim=pass"

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

DMARC ties SPF and DKIM together and tells receiving servers what to do with emails that fail authentication. It also provides reporting β€” receiving servers send you XML reports showing who is sending email from your domain and whether it's passing or failing authentication.

; DMARC record β€” Start with p=none (monitoring only)
_dmarc.zeonedge.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@zeonedge.com; ruf=mailto:dmarc-forensics@zeonedge.com; adkim=r; aspf=r; pct=100; fo=1"

; After 2-4 weeks of monitoring (confirm all legitimate sources pass):
; Move to p=quarantine (send failures to spam)
_dmarc.zeonedge.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@zeonedge.com; pct=100; adkim=s; aspf=s"

; After another 2-4 weeks (confirm no legitimate email is quarantined):
; Move to p=reject (block all unauthenticated email)
_dmarc.zeonedge.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@zeonedge.com; pct=100; adkim=s; aspf=s"

; Key parameters:
; p=none|quarantine|reject β€” Policy for emails that fail both SPF and DKIM
; rua= β€” Address for aggregate DMARC reports (daily XML summaries)
; ruf= β€” Address for forensic reports (per-failure details, some providers ignore)
; adkim=r|s β€” DKIM alignment: relaxed (subdomain ok) or strict (exact domain match)
; aspf=r|s β€” SPF alignment: relaxed or strict
; pct=100 β€” Percentage of failing emails to apply policy to (use for gradual rollout)

The DMARC Enforcement Journey: Step by Step

Week 1-2: Inventory all email sources. Before configuring anything, identify every service that sends email from your domain: Google Workspace, marketing platforms (Mailchimp, SendGrid, HubSpot), transactional email (your application), ticketing systems (Zendesk, Freshdesk), CRM (Salesforce), payroll, HR systems, and any legacy systems. Missing even one source will cause legitimate email to fail after enforcement.

Week 2-3: Configure SPF and DKIM for all sources. Add each sending service to your SPF record and configure DKIM signing for each service. Verify by sending test emails from each service and checking headers for spf=pass and dkim=pass.

Week 3-4: Deploy DMARC with p=none. Set DMARC to monitoring mode and collect reports for 2-4 weeks. Use a DMARC report analyzer (dmarcian, EasyDMARC, or the free parsedmarc tool) to visualize the reports and identify any sources that are failing.

Week 5-8: Fix failures and move to p=quarantine. Address any legitimate sources failing authentication. Common issues: a forgotten marketing tool, a SaaS application sending notifications from your domain, or an employee using a personal email client with incorrect SMTP settings. Once all legitimate sources pass, move to p=quarantine.

Week 9-12: Move to p=reject. After 2-4 weeks of quarantine with no legitimate email being flagged, move to p=reject. This is the gold standard β€” receiving servers will reject any email from your domain that fails both SPF and DKIM alignment.

BIMI: Your Brand Logo in the Inbox

Brand Indicators for Message Identification (BIMI) displays your brand logo next to your emails in supporting email clients (Gmail, Apple Mail, Yahoo Mail). It requires DMARC at p=quarantine or p=reject, a verified logo, and a Verified Mark Certificate (VMC) from a certificate authority like DigiCert or Entrust.

; BIMI record
default._bimi.zeonedge.com. IN TXT "v=BIMI1; l=https://zeonedge.com/bimi-logo.svg; a=https://zeonedge.com/vmc.pem"

; Requirements:
; 1. DMARC policy must be p=quarantine or p=reject
; 2. Logo must be SVG Tiny PS format (not regular SVG)
; 3. VMC certificate required for Gmail (optional for other providers)
; 4. Logo must be trademarked (VMC requirement)
; 5. Square logo recommended (displayed at various sizes)

BIMI isn't just vanity β€” emails with brand logos have measurably higher open rates (10-15% increase in studies by both Validity and Red Sift) because users trust and recognize branded emails. For marketing teams, this alone justifies the investment in full DMARC enforcement.

ARC: Solving the Forwarding Problem

Email forwarding breaks SPF (the forwarding server's IP isn't in your SPF record) and often breaks DKIM (mailing lists modify headers or body content). ARC (Authenticated Received Chain) solves this by allowing each mail server in the forwarding chain to sign the authentication results it observed, creating a chain of trust.

ARC is implemented by the mail server software (Postfix, Exchange, Gmail) β€” you don't need to configure DNS records for it. What you need to know: if your employees use mailing lists or email forwarding rules, ARC-aware receiving servers will honor the original authentication results even after forwarding. Most major email providers (Google, Microsoft, Yahoo) support ARC.

Troubleshooting Common Issues

"SPF PermError: Too many DNS lookups" β€” SPF allows a maximum of 10 DNS lookups. Each include: and redirect: counts as a lookup, and included records may contain their own lookups. Solution: replace include: with ip4:/ip6: for services with static IPs, use an SPF flattening service, or move some sending to a subdomain with its own SPF record.

"DKIM signature verification failed" β€” Common causes: the email was modified in transit (mailing list added a footer), the DKIM DNS record has incorrect formatting (line breaks, missing quotes), or the DKIM key was rotated but the DNS record wasn't updated. Check the DKIM record with dig TXT selector._domainkey.yourdomain.com.

"DMARC alignment failure" β€” SPF and DKIM pass, but DMARC still fails. This happens when the domain in SPF (envelope from / Return-Path) or DKIM (d= parameter) doesn't align with the header From domain. Common with third-party sending services that use their own domain for the envelope from.

ZeonEdge provides email authentication implementation and managed DMARC enforcement services. We handle the entire journey from p=none to p=reject, including BIMI setup and ongoing monitoring. Learn about our email services.

A

Alex Thompson

CEO & Cloud Architecture Expert at ZeonEdge with 15+ years building enterprise infrastructure.

Ready to Transform Your Infrastructure?

Let's discuss how we can help you achieve similar results.