Email Security Beyond DMARC: DKIM, ARC, and BIMI for Texas SMBs in 2026

DMARC tells receiving mail servers what to do when SPF and DKIM both fail: pass, quarantine, or reject. Setting p=reject is necessary because anything else lets attackers spoof your domain in business email compromise (BEC) attacks. But DMARC says nothing about:

• Whether the DKIM key signing your mail is rotated (most aren't)
• Whether legitimate forwarding paths (mailing lists, internal forwards, support tools) preserve authentication (most don't, without ARC)
• Whether your domain shows a trust indicator in supporting inboxes (most don't, without BIMI)
• Whether your SPF record stays under 10 DNS lookups as your SaaS sender list grows (most break silently when they don't)

If your DMARC policy is still p=none or p=quarantine in 2026, that's the highest-priority fix on this list. The path is: monitor DMARC reports for 60-90 days at p=none to identify all legitimate senders, fix the SPF and DKIM gaps for each, then escalate to p=quarantine for 30 days, then to p=reject. Tools like Dmarcian, Valimail, and EasyDMARC turn the report parsing from "free time on a weekend" into "automated dashboard."

The pct= tag lets you escalate gradually (pct=25 enforces on 25% of failing mail). Use it.

DKIM signs outbound mail with a private key. The corresponding public key lives in DNS as a TXT record at selector._domainkey.yourdomain.com. The 2026 best practice — and what NIST recommends — is rotating these keys at least annually. The reality across our Texas SMB engagements: 90% of organizations have never rotated their DKIM keys since initial setup.

Why rotate? Because keys generated in 2018 are often 1024-bit (now considered weak). Modern best practice is 2048-bit. Because if a key is compromised (developer laptop stolen, exchange administrator account breached), you cannot revoke it — you can only rotate to a new selector. Because mail providers increasingly check key length and reject signatures from short keys.

The rotation pattern: generate a new 2048-bit key, publish under a new selector (e.g., google2026), reconfigure your sending platform to sign with the new selector, wait 14 days for downstream caches to update, then remove the old selector record. Repeat annually.

ARC (Authenticated Received Chain) solves a long-standing problem: when a legitimate intermediary (mailing list, forwarding rule, ticketing system) modifies a message, it breaks SPF and DKIM, which causes DMARC to fail, which causes the receiving server to reject perfectly legitimate mail.

ARC adds a cryptographically signed chain of custody so each intermediary attests to the prior authentication state. The receiving server can then trust the original authentication even when the path was modified.

For Texas SMBs running shared mailboxes, support ticketing systems (Zendesk, Freshdesk, Help Scout), or mailing lists, ARC is the difference between "mail mostly works" and "mail consistently works." Microsoft 365 and Google Workspace both support ARC natively — you typically just need to enable it in the mail flow rules.

BIMI displays your organization's verified logo next to authenticated mail in the recipient's inbox (Gmail, Apple Mail, Yahoo, Fastmail, and increasingly Outlook). The trust signal is significant: a March 2024 Yahoo study showed 21% increase in open rates and 33% increase in brand recall for BIMI-displaying senders.

BIMI requires DMARC at p=quarantine or p=reject (which you should already have), an SVG logo published at a specific URL, and — for the trusted-mark indicator — a Verified Mark Certificate (VMC) issued by Entrust or DigiCert (around $1,500/year). The cheaper Common Mark Certificate (CMC) works for inbox display in Gmail without the trusted-mark badge.

For Texas SMBs sending high-volume marketing or transactional mail, BIMI is one of the highest-ROI brand investments available in 2026.

SPF has a hard 10-DNS-lookup limit. Each include: directive (Microsoft 365, Mailchimp, Salesforce, HubSpot, SendGrid, Zendesk, etc.) consumes lookups, and many of those services have nested includes that consume more. A typical mid-size Texas SMB with 8-12 SaaS senders breaks the 10-lookup limit silently — and once you exceed it, ALL of your SPF results return PermError, which means DMARC starts failing for every legitimate sender.

The fix is SPF flattening: use a service like EasyDMARC, Valimail, or PowerDMARC to publish a single managed SPF record that resolves the underlying IP ranges and republishes them, keeping you under the lookup limit. Alternative: aggressively trim SaaS senders that should be sending from a subdomain instead of your apex.

1. DMARC at p=reject with rua= reporting to a parser you actually monitor
2. DKIM 2048-bit, rotated within the last 12 months
3. ARC enabled on all forwarding paths
4. SPF under 10 lookups (use flattening if needed)
5. BIMI deployed with at least a CMC (VMC if budget allows)
6. MTA-STS and TLS reporting (TLSRPT) for transport-layer security
7. Microsoft Defender for Office 365 anti-phishing impersonation protection on for executives + finance

For Texas SMBs that have DMARC enforcement: the highest-leverage next step is auditing your DKIM key age and SPF lookup count. Both are 30-minute exercises that often reveal months-old time bombs. Tools like MXToolbox or EasyDMARC will flag both. Then plan ARC, then BIMI.

For organizations still at p=none or p=quarantine: get to p=reject first using the gradual escalation pattern above. Related: MFA bypass attacks 2026, M365 Copilot security, M365 managed services.

• Houston managed IT
• The Woodlands managed IT
• Sugar Land cybersecurity
• Katy managed IT