A DMARC record is not DMARC protection. The gap between the two is the whole story of where email auth stands in 2026. In our February 2026 scan of 5,499,028 domains, 30.4% publish a DMARC record. But only 12.8% reach an enforcement policy — p=quarantine or p=reject. The other 17.6 percentage points sit at p=none. Put from the DMARC owner's side: 57.9% of every domain that publishes DMARC never moves past monitoring. They get reports they mostly don't read, and they block nothing. This matters because p=none is monitoring mode by design (RFC 9989 §4.7). It tells receivers to watch and report, not to reject spoofed mail. A domain at p=none is exactly as spoofable as a domain with no record — it just has better telemetry about it. Why do teams stall? The bulk-sender mandates from Google, Yahoo, and Microsoft all accept a p=none record. Nothing forces the next step, and the next step is real work: identify every legitimate sender, align it, then tighten. What to do: if you're at p=none, you're not done — you're at the start. Use your aggregate reports to find unaligned senders, fix them, then step to quarantine. The five numbers, with sources: dmarcguard.io/blog/dmarc-enforcement-gap/ #DMARC #EmailSecurity

NIS2 enforcement is rolling out across the EU — Germany's law took effect 6 December 2025. A question we keep hearing: does it require DMARC? No. The NIS2 Directive (EU) 2022/2555 is technology-neutral and names no email protocol. The binding email text lives one layer down, in Commission Implementing Regulation (EU) 2024/2690, point 6.7.2(k): in-scope entities must adopt a plan to deploy "internationally agreed and interoperable modern e-mail communications standards." That phrase is the map. SPF, DKIM, and DMARC cover sender authentication; MTA-STS and DANE cover the Article 21(2)(h) cryptography-in-transit duty; TLS-RPT gives you the monitoring auditors expect. What to do: don't wait for a protocol to be named — it won't be. Move DMARC to enforcement, publish MTA-STS, and write down the deployment plan. The plan is the part 6.7.2(k) actually requires. The full Article 21 control map: dmarcguard.io/blog/nis2-email-security/ #NIS2 #EmailSecurity

Two in five domains can be spoofed by anyone, today, with no special access. We scanned 5,499,028 domains in February 2026 and found 40.8% — 2,243,877 of them — with no email authentication of any kind. Not DMARC. Not DKIM. Not even an SPF record. This is the silent default. Domains don't arrive spoofable through a misconfiguration; they arrive spoofable because nobody published anything. There's no error message for "you have no SPF." Mail flows fine. The gap only shows up when someone forges your From address and a receiver has no record to check it against. It's worth separating two ideas. A domain with no auth isn't theoretically at risk — it's missing the one set of records that lets receivers tell your mail from a forgery. - SPF (RFC 7208) authorizes your sending IPs - DKIM (RFC 6376) signs your messages - DMARC (RFC 9989) ties them to your From domain and tells receivers what to do on a mismatch. What to do: if you've never published anything, start with SPF and a DMARC record at p=none with a rua address. That's a 2-minute DNS change, and it moves you out of the 40.8% and into a position to see what's actually being sent as you. The full protocol breakdown: https://dmarcguard.io/research/email-authentication/ #EmailSecurity #DMARC

SPF doesn't fail loudly. It fails silently, and the failure mode that bites hardest is the one with no error message: PermError. Three ways SPF breaks, and the fix for each. 1. Too many DNS lookups. SPF caps evaluation at 10 DNS-querying mechanisms (RFC 7208 §4.6.4). Every include: you add — Microsoft 365, Google Workspace, your CRM, your help desk — costs at least one. Cross 10 and the whole record returns PermError, which DMARC treats as fail. Fix: flatten low-churn includes to ip4 ranges, or delegate senders to subdomains, each with its own 10-lookup budget. 2. Two records on one domain. RFC 7208 §3.2 allows exactly one SPF record. Two v=spf1 TXT records — usually from a provider migration nobody cleaned up — and receivers PermError on all of it. Fix: merge them into one. 3. Syntax that doesn't parse. A stray space, a missing v=spf1 prefix, a dead include pointing at NXDOMAIN. Fix: validate after every change. The thread running through all three: SPF fails open and invisible. No bounce, no log on your side — just legitimate mail quietly losing alignment. What to do: count your lookups and confirm you have exactly one record before you touch anything else. The full set of causes, with fixes: dmarcguard.io/blog/spf-permerror-fix/ #SPF #DMARC

Free DMARC checkers and DMARC monitoring are different products. Worth knowing which you need. A free checker answers a point-in-time question: is my record valid right now? Genuinely useful — run one before you change anything. Most of the field, us included, offers these at no cost. Monitoring answers a different question, continuously: who is sending as my domain, which messages pass alignment, and what breaks when I tighten policy? That means ingesting the aggregate (rua) reports receivers send you and turning thousands of lines of XML into something you can act on. The honest test: are you moving from p=none to p=reject without breaking legitimate mail? If yes, a one-time check can't get you there — you need to see the senders before you enforce. If you just need to confirm a record is valid, the free tool is the whole job. What each tier includes: dmarcguard.io/blog/best-dmarc-monitoring-tools/ #DMARC

There's a successor to DKIM taking shape at the IETF, called DKIM2. The first working-group revision, draft-ietf-dkim-dkim2-spec-01, was posted 20 April 2026. Instead of signing a message once at origin (RFC 6376, with its known replay weakness), DKIM2 signs every hop — each forwarder adds its own DKIM2-Signature binding the SMTP envelope and a timestamp, and rejects signatures older than 14 days. Replay gets structurally harder. The same week, the IETF rechartered the DMARC working group to move ARC (RFC 8617) to Historic. DKIM2 is the intended replacement. The honest status: nothing to deploy. As of 2026, no operator signs DKIM2; first production is realistically 2026 H2 to 2027. It reuses the existing _domainkey namespace, so no new record types. What to do: nothing urgent. Keep ARC where you rely on it, and track the draft. The five drafts, read in full: dmarcguard.io/blog/arc-to-dkim2-future/ #DKIM #EmailAuthentication

Two companies underpin a third of the email-sending internet. In our SPF Supply Chain scan of 5,499,028 domains (March 2026), Microsoft 365 appears in 19.6% of all SPF-enabled domains and Google Workspace in 13.6%. Together, two providers sit inside roughly a third of every SPF record on the web. Concretely: 603,854 domains list spf.protection.outlook.com. When Microsoft changes an IP range in that include, the SPF result for all 603,854 recomputes at once — they inherit whatever Microsoft publishes, by design. include: (RFC 7208 §4.6.2) is delegation: you're trusting another domain's record to be correct and current. That centralization is mostly a good thing. Two well-run providers maintain SPF for hundreds of thousands of domains that would otherwise hand-edit ip4 ranges and drift out of date. But it's also concentration risk: one upstream change, one outage, one IP rotation that overflows your lookup budget, and the blast radius is enormous. What to do: know which includes you actually depend on. If you carry Microsoft 365 plus Google plus a few ESPs, you're closer to the 10-lookup ceiling than you think — audit the chain before adding the next sender. The full supply-chain breakdown: https://dmarcguard.io/research/spf-supply-chain/ #SPF #EmailSecurity

DANE was meant to be the gold standard for email transport security. Almost nobody uses it. We scanned 5,499,028 domains in February 2026. Thirty of them publish a valid TLSA record. Not thirty percent. Thirty domains. That rounds to 0.0%. The design is sound. DANE (RFC 6698/7672) pins your TLS certificate in DNS, signed with DNSSEC, so a downgrade attack has nothing to forge. The problem isn't the protocol. It's the prerequisite. DANE needs DNSSEC on both sides, and DNSSEC adoption stalled years ago. Senders don't validate it because few receivers publish it; few publish it because no senders check. A deadlock. Meanwhile MTA-STS, which rides on the web PKI you already have, solved the same downgrade problem without DNSSEC, and reached roughly 10× the adoption. Still only 0.3%, but an order of magnitude ahead of thirty domains. What to do: if you already run DNSSEC, DANE is worth publishing — it's strictly stronger. If you don't, start with MTA-STS. Don't let "DANE is better on paper" stall you from shipping the transport security you can actually deploy this week. https://dmarcguard.io/learn/dane/?utm_source=slack&utm_medium=social&utm_campaign=jul2026&utm_content=li-w3-tue #EmailSecurity

"Move to p=reject in 30 days" is the goal everyone wants. The honest version: you move when the reports say you're ready, not when the calendar does. Here's the rollout that doesn't break mail. Publish p=none with a rua address and read the aggregate reports until every legitimate sender is passing SPF or DKIM aligned. Then step up, but stage it with a brake. Under DMARCbis, the brake is t=y, not the old pct tag (pct is deprecated in RFC 9989 §4.7; receivers ignore it). t=y means the policy is provisional; receivers downgrade enforcement one step. The ladder: p=quarantine; t=y → p=quarantine → p=reject; t=y → p=reject. The readiness test is signal-based. M3AAWG and the UK NCSC both say advance when all known legitimate sources are identified and aligned and no new ones are appearing, not after a fixed number of days. As a heuristic, many teams hold each step until about 30 days of clean reports. NCSC notes 6–8 weeks is common. What to do: don't set a countdown. Set a threshold: zero unexplained senders. And let the reports tell you when to climb. The full staged rollout: https://dmarcguard.io/blog/how-to-create-dmarc-record/?utm_source=slack&utm_medium=social&utm_campaign=jul2026&utm_content=li-w3-thu #DMARC #EmailSecurity

MXToolbox is a tool we'd point you to for a fast diagnostic — it's genuinely good at what it does. Worth being clear where that job ends. MXToolbox answers point-in-time questions well: is my MX right, am I blacklisted, does my SPF parse, what does my DMARC record say today. For a quick check before you change DNS, it's hard to beat. What a checker doesn't do is ingest your aggregate (rua) reports day after day, name the senders behind the IPs, and track alignment over time. That's a different product — monitoring, not checking — and you need it specifically when moving off p=none without breaking mail. What to do: use a checker for the snapshot; reach for monitoring when you need the movie. https://dmarcguard.io/blog/mxtoolbox-alternative/?utm_source=slack&utm_medium=social&utm_campaign=jul2026&utm_content=li-w3-thu #DMARC

A "transitional" SPF setting quietly became the default state of the internet. In our scan of 5,499,028 domains (March 2026), 53.6% of SPF-enabled domains end their record with ~all (softfail), against 40.2% using -all (hardfail). Softfail means "this sender is probably not authorized, but don't reject outright" (RFC 7208 §8.5 — receivers SHOULD NOT reject on softfail alone). It was meant as a temporary posture while you found every legitimate sender, then tightened to -all. For most of the web, the temporary became permanent. Here's the part that makes the choice matter less than people think: once DMARC is deployed, receivers treat softfail and hardfail identically — both are "not pass" (RFC 9989 §4.2). DMARC overrides SPF's own enforcement signal. So with DMARC at p=reject and DKIM in place, ~all and -all reach the same outcome. Where it does matter: hardfail can get mail rejected before DMARC is even evaluated, and those rejections never appear in your reports. Softfail keeps the failure visible. That's why M3AAWG, Google, and the DMARCbis guidance all recommend ~all for sending domains, -all for parked ones. What to do: if you run DMARC enforcement, keep ~all and let DMARC do the deciding. Reserve -all for domains that send no mail at all. The data-backed decision guide: https://dmarcguard.io/blog/spf-softfail-vs-hardfail/?utm_source=slack&utm_medium=social&utm_campaign=jul2026&utm_content=li-w3-fri #SPF #DMARC

Gmail's bulk-sender rules stopped being a warning and became an SMTP rejection. Here's what gets you blocked now. Since November 2025, Gmail returns 550 5.7.26 — a permanent rejection, not a spam-folder placement — for unauthenticated mail from bulk senders (roughly 5,000+ messages a day to personal Gmail, counted across your domain and subdomains). Three things trigger it: - neither SPF nor DKIM passes and aligns - SPF hit a hard -all fail in transit - or your own DMARC policy rejected the message. The floor is still modest: - a DMARC record at p=none - SPF or DKIM aligned to your From domain - valid forward and reverse DNS - and one-click unsubscribe (RFC 8058) on marketing mail Google has signaled that requiring both SPF and DKIM alignment is the likely direction. What to do: if you send any volume to Gmail, confirm you're aligned — not just "have a record." The rejection is now at the SMTP door. The full three-provider checklist: https://dmarcguard.io/blog/google-yahoo-dmarc-requirements/?utm_source=slack&utm_medium=social&utm_campaign=jul2026&utm_content=li-w4-mon #DMARC #Deliverability

148,655 domains break their own SPF and most of them don't know it. In our SPF Supply Chain scan (5,499,028 domains, March 2026), that many exceed SPF's 10-lookup limit. That's 4.8% of every domain with a valid SPF record, quietly returning PermError on the mail they send. Here's the mechanism. SPF caps evaluation at 10 DNS-querying mechanisms (RFC 7208 §4.6.4). Each include: — Microsoft 365, Google Workspace, your CRM, your marketing tool — costs at least one lookup. Add enough senders and you cross the ceiling. At that point the record doesn't degrade gracefully — the entire SPF result becomes PermError, which DMARC treats as fail. Why it stays hidden: there's no bounce and no log on the sending side. SPF fails open and invisible. The first sign is usually deliverability dropping, or a DMARC report showing your own mail failing alignment. This is a supply-chain problem, not a typo. Every SaaS that sends on your behalf pushes you toward the limit — and nobody owns the running total. What to do: count your lookups. If you're near 10, flatten low-churn includes to IP ranges or delegate senders to subdomains, each with its own budget. Count yours: https://dmarcguard.io/tools/spf-flattener/?utm_source=slack&utm_medium=social&utm_campaign=jul2026&utm_content=li-w4-tue #SPF #DMARC

The aggregate report receivers send you XML, and the part that confuses everyone is two columns that look like they should match but don't. Inside every DMARC rua report (schema now in RFC 9990) each record has two verdict blocks. auth_results is the raw SPF and DKIM check the receiver saw on the wire. policy_evaluated is the DMARC verdict after the receiver checked alignment against your From domain. They diverge constantly — and reading the gap is the whole skill. The most common pattern looks alarming and is harmless: spf=pass in auth_results, spf=fail in policy_evaluated, dkim=pass. That's an ESP — its own SPF passes for its domain, doesn't align with yours, and DKIM carries the DMARC pass. Normal. The pattern that matters: an unfamiliar ASN, header_from matching your domain, no DKIM block at all, high counts, no override reason. That shape is a real spoofing run, not rotation. Four patterns — ESP rotation, list/ARC breakage, forwarder breakage, real spoofing — cover most of what shows up. What to do: learn to read auth_results vs policy_evaluated before you tighten policy. Guessing from raw counts is how teams block their own mail. Field-by-field, with a real report: https://dmarcguard.io/blog/how-to-read-dmarc-report/?utm_source=slack&utm_medium=social&utm_campaign=jul2026&utm_content=li-w4-wed #DMARC #EmailSecurity

Most DMARC platforms, including EasyDMARC, run a free tier. The useful question before you commit isn't "is it free?" — it's "where does free stop?" Free tiers gate on predictable lines: how many domains you can monitor (often one), how much report history you can see, whether sender names are enriched or you're left reading raw IPs, and whether enforcement guidance sits behind an upgrade. None of that is a knock — it's how the model works. It just decides whether the free tier covers your real situation or only a demo of it. What to do: before you pick a tool, list your actual needs — domain count, history, multi-tenant — and check each against the free tier's edges, not its headline. https://dmarcguard.io/blog/easydmarc-alternative/?utm_source=slack&utm_medium=social&utm_campaign=jul2026&utm_content=li-w4-thu #DMARC

Email security is a two-tier internet, and the tiers split on resources. In our February 2026 scan of 5,499,028 domains, the top 10,000 sites adopt DMARC at 62.5% — more than double the 30.4% across the full list. The pattern is consistent across every cut. Regulated and well-resourced populations run far ahead: .gov sits at 76.4% DMARC adoption, .edu at 84.0%, against that 30.4% baseline. The further down the ranking, the thinner the protection. This isn't apathy in the long tail. DMARC done right is operational work — identify every sender, align SPF or DKIM, read reports, tighten policy without breaking mail. Big sites have someone who owns that. A 12-person company with one stretched IT generalist often doesn't, so the domain stays at "no record" or parks at p=none. The uncomfortable read: attackers know the odds. A forged From address is likelier to clear at a small supplier than at a bank — which is exactly why supply-chain phishing targets the small supplier. What to do: in the long tail you don't need a big team, you need the steps in order. Monitor, align, enforce. The full adoption breakdown: https://dmarcguard.io/research/email-authentication/?utm_source=slack&utm_medium=social&utm_campaign=jul2026&utm_content=li-w4-fri #EmailSecurity #DMARC

Microsoft's DMARC enforcement is the strictest of the big three, and the specifics trip people up. Since May 5, 2025, Outlook.com consumer inbound (@outlook.com, @hotmail.com, @live.com, @msn.com) rejects unauthenticated bulk mail — over 5,000 messages a day — with 550 5.7.515. Microsoft skipped the soft 4xx-deferral phase Google used and went straight to permanent rejection. The catch is the alignment bar. Gmail accepts either SPF or DKIM aligned. Microsoft expects both to pass and align. If you've been getting by on DKIM alone, you can clear Gmail and still bounce at Outlook. Scope matters: this rule is about sending to Outlook.com consumer mailboxes. Exchange Online tenant inbound is a separate regime, honoring p=reject and p=quarantine by default since July 2023. What to do: if you send to Outlook.com at volume, verify SPF and DKIM both align — not just one. The M365 specifics, step by step: https://dmarcguard.io/blog/microsoft-dmarc-enforcement/?utm_source=slack&utm_medium=social&utm_campaign=jul2026&utm_content=li-w5-mon #DMARC #Microsoft365

When a mandate has teeth, adoption follows. The clearest evidence in our data is the sector split. In our February 2026 scan of 5,499,028 domains, .gov domains publish DMARC at 76.4% and .edu at 84.0% — against a 30.4% baseline across the whole list. That's not a small lift — roughly two and a half times the internet average. The difference is governance. US federal agencies have operated under CISA's Binding Operational Directive 18-01 since 2017, which requires DMARC at p=reject. It set a deadline, named the policy, and followed up. Adoption moved. The contrast is the open market, where the bulk-sender rules from Google, Yahoo, and Microsoft accept a p=none record — a checkbox, not enforcement. Predictably, the broad population sits at 30.4% adoption and 12.8% enforcement. The lesson cuts both ways. A mandate with a named policy and a date works. A mandate that accepts "publish anything" produces records that don't protect. What to do: don't wait for a regulator to set your bar. Adopt the .gov posture voluntarily — p=reject is the target — and you're ahead of whatever lands next. The sector-by-sector data: https://dmarcguard.io/research/email-authentication/?utm_source=slack&utm_medium=social&utm_campaign=jul2026&utm_content=li-w5-tue #EmailSecurity #DMARC

Rotating a DKIM key sounds risky — you're swapping the thing that signs your mail. Done with selectors, it's a zero-downtime change. Done in place, it breaks verification for everything still in flight. The mechanism is the selector. A DKIM key lives in DNS at selector._domainkey.yourdomain.com, and the signature names which selector signed it via the s= tag (RFC 6376). Because you can publish multiple selectors at once, rotation is additive, not a swap: 1. Generate a new key under a new selector — date-based like 2026-07 reads cleanly. 2. Publish the new public key; leave the old one in place. 3. Switch your mail server to sign with the new selector. 4. Keep the old key published at least 7 days so in-flight mail still verifies. 5. Then remove the old record and destroy the old private key. One catch most checkers miss: most ESPs publish DKIM by CNAME so they can rotate keys without you touching DNS. If that alias chain dangles — points at a target that no longer resolves — your DKIM silently fails, and a plain TXT lookup won't catch it. What to do: rotate on selectors, never in place, and validate the full CNAME chain (not just the record) after every change. Walk your DKIM CNAME chain: https://dmarcguard.io/tools/dkim-cname-validator/?utm_source=slack&utm_medium=social&utm_campaign=jul2026&utm_content=li-w5-wed #DKIM #EmailSecurity

Switching DMARC vendors has one trap nobody warns you about: your report history doesn't come with you. Your rua tag points failing-mail telemetry at a mailbox your current tool owns. Re-point rua to a new vendor and the new one starts from zero — while months of aggregated history stay locked in the old platform. Cancel first, and you can lose the trend line that told you enforcement was safe. Two ways to keep continuity: - Export your historical data before you cancel anything. - Run both rua destinations in parallel for an overlap window, so the new tool has real data before you cut the old. What to do: treat history as a migration artifact, not an afterthought. Export or overlap before you flip rua. How a clean migration works: https://dmarcguard.io/blog/dmarcian-alternative/?utm_source=slack&utm_medium=social&utm_campaign=jul2026&utm_content=li-w5-thu #DMARC

The layer almost nobody publishes is the one that secures mail in transit. In our February 2026 scan of 5,499,028 domains, MTA-STS adoption is 0.3% — about 101 times rarer than DMARC's 30.4%. Here's the gap it fills. SPF, DKIM, and DMARC authenticate who sent a message. None of them protect the connection that carries it. SMTP was designed to fall back to plaintext if TLS isn't available, so a network attacker can strip encryption — a downgrade attack — and read mail in transit. Authentication never sees it. MTA-STS (RFC 8461) closes that. You publish a policy over HTTPS plus an _mta-sts TXT record, and compliant senders refuse to deliver over an unencrypted or untrusted connection. It rides on the web PKI you already have — no DNSSEC required, which is why it reached 10× the adoption of DANE (still 0.0%). It's neglected not because it's hard, but because authentication gets the attention and transport gets none — until someone's mail is intercepted on a hostile network. What to do: if you've done DMARC, MTA-STS is the logical next record. Pair it with TLS-RPT so you learn when a sender can't reach you securely. The mechanism, end to end: https://dmarcguard.io/learn/mta-sts/?utm_source=slack&utm_medium=social&utm_campaign=jul2026&utm_content=li-w5-fri #EmailSecurity #DMARC

DMARCbis quietly retired the tag most people used for gradual rollout. Here's what replaced it. The old way: pct=10 told receivers to apply your policy to 10% of messages and treat the rest as p=none. Useful for easing into enforcement — but receivers implemented it inconsistently, and it blurred what your policy actually meant. RFC 9989 deprecates pct. The replacement is t= (testing mode). With t=y, receivers apply your stated policy one level weaker — p=reject behaves like quarantine, p=quarantine behaves like none. A clean binary: "I'm testing, don't fully enforce yet." Major receivers still honor pct, so existing records won't break. But t= is where the standard points now. What to do: if your rollout depends on pct, plan the switch. Stage at quarantine with t=y, watch your aggregate reports, then drop t= for full enforcement. Full DMARCbis tag breakdown: https://dmarcguard.io/learn/dmarc/?utm_source=slack&utm_medium=social&utm_campaign=jul2026&utm_content=li-w6-mon #DMARC #DMARCbis

Almost nobody publishes BIMI. Of the few who do, more than a quarter publish it broken. In our 5.5M-domain scan (Feb 2026), 20,518 domains had a BIMI record — 0.4% of the internet. That alone makes BIMI one of the rarest things in email. But the detail that stuck with us: 5,779 of those records were broken. That's 28.2% — a 404 on the logo URL, or an SVG that fails validation. Only 71.8% actually resolve to a valid logo. Think about what that means. These are organizations that cleared the hard prerequisites — DMARC at enforcement, often a four-figure Verified Mark Certificate — and then the logo doesn't render because a file moved or never met the SVG Tiny PS profile. The setup is the cheap, visible part. Keeping the asset live and spec-valid is the part that quietly fails. A logo URL that 404s after a website migration breaks BIMI silently — no bounce, no alert, just a missing logo. What to do: if you run BIMI, treat the logo URL and certificate as monitored production assets, not set-and-forget DNS. Re-validate after any site migration. The BIMI failure modes, in detail: https://dmarcguard.io/learn/bimi/?utm_source=slack&utm_medium=social&utm_campaign=jul2026&utm_content=li-w6-fri Data: 5.5M domains, Feb 2026. #BIMI #EmailSecurity

If you touch cardholder data, anti-phishing controls stopped being optional in March 2025. PCI DSS v4.0.1 Section 5.4.1 requires processes and automated mechanisms to detect and protect personnel against phishing. It was best-practice until March 31, 2025 — since then it's mandatory for any entity that stores, processes, or transmits cardholder data. The guidance names the controls explicitly: DMARC, SPF, and DKIM. Most Qualified Security Assessors now treat DMARC as an expected baseline. The standard doesn't mandate a specific policy, but p=quarantine or p=reject (RFC 9989 §3.2.9) is what blocks spoofed mail rather than just reporting on it. One nuance: 5.4.1 is broader than your own domain — it pairs domain authentication with email filtering and user controls. DMARC is one component, not the whole requirement. What to do: before a PCI assessment, confirm your sending domains enforce DMARC and document SPF/DKIM/DMARC as your 5.4.1 controls. https://dmarcguard.io/learn/pci-dss/?utm_source=slack&utm_medium=social&utm_campaign=jul2026&utm_content=li-w9-mon #PCIDSS #DMARC

Of the three core email-auth protocols, the one that proves a message wasn't tampered with is the least deployed. We scanned 5,499,028 domains (Feb 2026). SPF adoption: 56.0%. DMARC: 30.4%. DKIM: 22.7% — the lowest of the three. And that 22.7% is a floor: we probed six common selectors (default, google, selector1, selector2, k1, dkim), so domains using custom or rotated selectors are undercounted. Why is DKIM last? Because SPF and DMARC are a TXT record you publish once. DKIM (RFC 6376) is key management. You generate a keypair, publish the public half in DNS, and configure every sending system to sign with the private half. Miss one system and that mail goes unsigned. Rotate a key carelessly and you break signatures in flight. That difficulty matters because DKIM is the part that survives forwarding. SPF breaks the moment a message is relayed; an aligned DKIM signature is often the only reason DMARC still passes. The hardest protocol to deploy is the one doing the heavy lifting. What to do: confirm every sending source signs with DKIM, and that the d= domain aligns with your From address. Check your selectors and signatures here: https://dmarcguard.io/tools/dkim-checker/?utm_source=slack&utm_medium=social&utm_campaign=jul2026&utm_content=li-w6-tue #DKIM #EmailSecurity

Every DMARC vendor promises to get you "enforcement-ready." Few define it. Here's a test you can apply before you pay anyone. Enforcement-ready means moving to p=reject (RFC 7489 §6.3) without blocking one piece of legitimate mail. That takes three things, in order: 1. A complete inventory of every system sending as your domain. 2. Each source passing SPF or DKIM alignment. 3. Confidence, from real aggregate reports, that nothing legitimate is failing. A point-in-time score doesn't get you there. Across 5.5M domains, 30.4% have DMARC but only 12.8% enforce (Feb 2026). The gap between those two numbers is exactly this work. What to do: before signing up anywhere, ask how a vendor proves steps 1–3 — not how fast it shows a green checkmark. What enforcement-ready should include: https://dmarcguard.io/compare/?utm_source=slack&utm_medium=social&utm_campaign=jul2026&utm_content=li-w6-thu #DMARC #EmailSecurity

The logo in the inbox is the cheap part of BIMI. The certificate behind it is where the budget goes. BIMI puts a verified brand logo next to your mail. It's still an IETF draft, but the major providers have already settled the rules. Publishing the DNS record costs nothing — displaying in Gmail or Apple Mail is where it gets expensive, because both require a Verified Mark Certificate (VMC). What a VMC actually takes: 1. A registered trademark for your logo. Filing runs months and isn't free. 2. The certificate: $1,000–$1,500 a year, from one of only two issuers (DigiCert or Entrust). 3. DMARC already at enforcement — p=quarantine or p=reject (RFC 7489 §6.3). BIMI will not work at p=none. Hard prerequisite, not a recommendation. 4. Your logo rebuilt as SVG Tiny 1.2 PS — a restrictive profile most standard logos fail without rework. Yahoo, AOL, and Fastmail show BIMI logos without a VMC. If your audience skews there, you can ship the logo for free. What to do: don't start with the certificate. Get DMARC to enforcement first — it's the prerequisite and the part that actually protects you. The logo is the reward, not the goal. Full BIMI setup and cost breakdown: https://dmarcguard.io/learn/bimi/?utm_source=slack&utm_medium=social&utm_campaign=jul2026&utm_content=li-w6-wed #BIMI #EmailSecurity

A mechanism the SPF spec told you to stop using twelve years ago is still in 41,728 records. When we parsed SPF across 5.5M domains (SPF Supply Chain 2026, scanned March 2026), 41,728 of them — 1.4% of all SPF-enabled domains — still include the ptr mechanism. RFC 7208 §5.5 is blunt: ptr "SHOULD NOT be used." Here's why the spec gave up on it. ptr authorizes a sender by doing a reverse-DNS lookup on the connecting IP and checking whether the result sits under your domain. That's slow, it's spoofable if reverse DNS isn't tightly controlled, and it loads receiving mail servers on every connection. Some receivers now skip or downrank it, so a ptr pass isn't even reliable. So why is it still there? Cargo-cult DNS. Someone copied an SPF record from an old tutorial a decade ago, it worked well enough, and nobody has touched it since. For most domains, SPF is write-once-and-forget. What to do: pull your SPF record and look for ptr. If it's there, replace it with explicit ip4/ip6 ranges or an include: for the real sender, then drop ptr. Inspect it token by token here: https://dmarcguard.io/tools/spf-syntax-inspector/?utm_source=slack&utm_medium=social&utm_campaign=jul2026&utm_content=li-w9-tue Data: SPF Supply Chain 2026, scanned March 2026. #SPF #Sysadmin

MTA-STS is two files that have to agree. When senders report "STSFetchResult.None," one of them is missing. MTA-STS (RFC 8461) tells sending servers to require TLS when they deliver to you. It lives in two places: 1. A DNS TXT record at _mta-sts.<yourdomain> — v=STSv1; id=20260826T120000. The id is just a version stamp. 2. A policy file served over HTTPS at mta-sts.<yourdomain>/.well-known/mta-sts.txt. The policy file is four lines version: STSv1 mode: enforce mx: mail.<yourdomain> max_age: 604800 mode is the switch: testing reports failures without blocking, enforce refuses non-TLS delivery, none withdraws the policy. STSFetchResult.None means the sender found your DNS record but couldn't fetch a valid policy. Three usual causes: 1. the .well-known file isn't there 2. the mta-sts subdomain has no valid HTTPS certificate 3. or the file is served with the wrong content type. Fastest check: open that URL in a browser. If it doesn't load cleanly for you, it won't load for a sending server either. One gotcha: when you edit the policy file, bump the id in DNS — or senders keep using the cached copy until max_age expires. What to do: open your policy URL, confirm it returns plain text over valid HTTPS, then validate the whole setup: https://dmarcguard.io/tools/mta-sts-checker/?utm_source=slack&amp;utm_medium=social&amp;utm_campaign=jul2026&amp;utm_content=li-w9-wed #MTASTS #EmailSecurity

"We monitor nine protocols, they monitor three." It's a common DMARC-vendor claim. Here's how to read it. Protocol count is real, but it isn't the same as value. Of the six we measured across 5.5M domains, three carry almost all the weight — SPF, DKIM, DMARC — and the advanced layers are rare: MTA-STS at 0.3%, BIMI at 0.4%, DANE at 30 domains total (Feb 2026). A protocol almost nobody runs is easy to list and rarely the thing between you and a spoof. The claim that matters isn't breadth — it's whether a tool gets you from p=none to enforcement without breaking mail. That's the work most of the internet still hasn't done. What to do: when you read a feature list, ask which items move your policy forward and which just make the list longer. Count outcomes, not protocols. How to compare on outcomes: https://dmarcguard.io/compare/?utm_source=slack&amp;utm_medium=social&amp;utm_campaign=jul2026&amp;utm_content=li-w9-thu #DMARC #EmailSecurity