--- title: "DMARC Passed. The Email Was Still an Attack. Inside the Blesta Ransom Incident | DMARC Report" description: "A ransom email from no-reply@blesta.com passed SPF, DKIM, and DMARC because it came from Blesta" image: "https://dmarcreport.com/og/blog/blesta-ransom-email-dmarc-passed-authenticated-abuse.png" canonical: "https://dmarcreport.com/blog/blesta-ransom-email-dmarc-passed-authenticated-abuse/" --- Quick Answer In June 2026 a ransom email sent from no-reply@blesta.com passed SPF, DKIM, and DMARC because it was sent through Blesta's own authenticated mail infrastructure, not spoofed from outside. This is authenticated abuse: a real, authorized system is misused after a compromise, so authentication correctly passes. It is not a DMARC failure. SPF, DKIM, and DMARC prove that a message came through infrastructure the domain authorized. They do not prove that a human approved the content, that the account was not compromised, or that the message is trustworthy. The defense is to stop treating authenticated as a synonym for safe: enforce least privilege on who can trigger sends, require change control on sensitive templates, watch DMARC aggregate reports for behavioral anomalies from known-good infrastructure, and verify ransom or payment demands out of band. Related: [Free DMARC Checker](/tools/dmarc-checker/) Share [ ](https://www.linkedin.com/sharing/share-offsite/?url=undefined%2Fblog%2Fblesta-ransom-email-dmarc-passed-authenticated-abuse%2F "Share on LinkedIn") [ ](https://twitter.com/intent/tweet?text=DMARC%20Passed.%20The%20Email%20Was%20Still%20an%20Attack.%20Inside%20the%20Blesta%20Ransom%20Incident&url=undefined%2Fblog%2Fblesta-ransom-email-dmarc-passed-authenticated-abuse%2F "Share on X/Twitter") [ ](https://www.facebook.com/sharer/sharer.php?u=undefined%2Fblog%2Fblesta-ransom-email-dmarc-passed-authenticated-abuse%2F "Share on Facebook") [ ](https://reddit.com/submit?url=undefined%2Fblog%2Fblesta-ransom-email-dmarc-passed-authenticated-abuse%2F&title=DMARC%20Passed.%20The%20Email%20Was%20Still%20an%20Attack.%20Inside%20the%20Blesta%20Ransom%20Incident "Share on Reddit") [ ](mailto:?subject=DMARC%20Passed.%20The%20Email%20Was%20Still%20an%20Attack.%20Inside%20the%20Blesta%20Ransom%20Incident&body=Check out this article: undefined%2Fblog%2Fblesta-ransom-email-dmarc-passed-authenticated-abuse%2F "Share via Email") ![A ransom email that passed SPF, DKIM, and DMARC from a vendor's own infrastructure](https://media.mailhop.org/dmarcreport/images/2022/04/dmarc-report-4236.jpg) ## Try Our Free DMARC Checker Validate your DMARC policy, check alignment settings, and verify reporting configuration. [ Check DMARC Record → ](/tools/dmarc-checker/) On June 26, 2026, a number of people in the web hosting industry received an email with the subject line “Blesta Compromised.” It came from `no-reply@blesta.com`, the billing platform many hosting companies run their businesses on. It claimed an attacker had seized all customer data and demanded a ransom over the TOX messenger within 48 hours. The unsettling part is not the threat. It is that the email passed every authentication check we tell people to trust. SPF passed. DKIM passed, signed with Blesta’s own key. DMARC passed, against Blesta’s own `p=reject` policy. By every signal a mail client or security gateway uses to decide whether a message is genuinely from a domain, this one was genuinely from Blesta. That is exactly why it is worth understanding. This was not spoofing, and it was not a failure of email authentication. It is a textbook case of what is sometimes called authenticated abuse, and it exposes the single most important thing people misunderstand about SPF, DKIM, and DMARC. The incident was first surfaced publicly by Michael Pearce of Hosting Verified and reported in detail by [WebHosting Today](https://webhosting.today/2026/06/26/an-attacker-sent-a-ransom-email-from-blestas-own-servers/). The technical facts below come from that reporting and from the message headers it published. ## What actually happened The message did not come from a random server in some far-off network. It was injected from `account.web1.blesta.com` (IP `162.220.77.230`) and relayed through Blesta’s own Mailgun account (`mg.blesta.com`), riding the same transactional mail path the platform uses for ordinary invoices and notifications. According to Blesta’s own account of the event, the opening was a temporary support account. On June 25 the company created one for a third-party vendor in connection with an active support request. The attacker used that access to send mail through the platform’s legitimate sending capability, then the account was disabled once the activity was discovered. So there is a clean line between what the headers prove and what they do not. The headers prove the sending system was used by someone who should not have had it. They say nothing about whether the customer database was actually exfiltrated, partially accessed, or simply claimed to be. Authentication confirms the email is real. It cannot confirm the threat inside it is real. ## The headers, decoded It helps to be precise about what each check actually certified, because each one did its job correctly. - **SPF passed.** The sending IP was on an authorized sending path for the envelope domain. True, and it should have passed, because the mail really did leave through Blesta’s infrastructure. - **DKIM passed.** The message carried a valid cryptographic signature tied to Blesta’s signing domain (`d=mg.blesta.com`, selector `s=k1`). True. The content was signed with a key only Blesta’s systems hold. [DKIM proves the message was signed by the domain and not altered in transit](/blog/dkim-explained-how-dkim-works-and-why-is-dkim-important-for-organizations/), nothing more. - **DMARC passed.** The visible `From` domain aligned with an authenticated identity, evaluated against Blesta’s published `p=reject` policy. True. The `From` address was not forged. None of the three was ever designed to prove the next set of questions, which are the ones that actually matter here: Did a human at Blesta approve this message? Was the account that triggered it under the control of its rightful owner? Does this message belong in the stream of mail Blesta normally sends? Authentication has no opinion on any of that. ## This is not a DMARC failure. It is DMARC working as designed It is tempting to read a story like this as evidence that DMARC let everyone down. The opposite is true. DMARC answered the question it was built to answer, correctly: is this message from the domain it claims to be from? Yes, it was. The whole point of `p=reject` is to guarantee that mail bearing your `From` domain really came from you. In this case it really did. The mistake is not in the protocol. It is in the inference people draw from it. Over a decade of “look for the green checkmark” advice has trained both humans and automated filters to read authenticated as trustworthy. Those are two different claims. [SPF, DKIM, and DMARC verify authorization, not intent](/blog/can-dmarc-reports-help-me-detect-spoofing-and-phishing-attempts/). When an attacker gets inside authorized infrastructure, every signal that normally protects you now vouches for them. That is what makes authenticated abuse more dangerous than ordinary spoofing, not less. A spoofed ransom email from a lookalike domain trips alarms. This one sailed through, wearing the brand’s own cryptographic signature. ## Two threat models that look nothing alike The reason this trips people up is that we usually talk about email threats as if they are one problem. They are two, and email authentication only addresses one of them. | Unauthenticated spoofing | Authenticated abuse | | | ------------------------- | ---------------------------------------------------- | ---------------------------------------------------------- | | **Who is sending** | An outsider using infrastructure they do not control | An insider, or an attacker inside a real account or system | | **Authentication result** | Typically fails (SPF/DKIM/DMARC catch it) | Passes, because the infrastructure really is authorized | | **What stops it** | DMARC at p=quarantine or p=reject | Access control, change control, behavioral monitoring | | **Recipient’s instinct** | Suspicion (looks off) | Trust (looks official) | DMARC is the right and necessary answer to the left column. [Moving to an enforcement policy](/blog/dmarc-reject-policy-ultimate-protection-against-phishing-and-spoofing/) shuts down the impersonation attacks that make up the overwhelming majority of domain abuse. But enforcement does nothing about the right column, because there is no impersonation to reject. The mail is the real thing, sent for the wrong reason. If you have spent effort getting to `p=reject`, that effort was not wasted by the Blesta incident. Your domain is still protected against the millions of forged messages that would otherwise wear it. You have simply reached the edge of what authentication was ever meant to cover. ## Where DMARC reporting still earns its keep Here is the honest part, and the part a lot of coverage skips. DMARC will not block an authenticated-abuse message. But DMARC reporting can still help you notice one, and that distinction matters. [Aggregate reports](/blog/dmarc-aggregate-report-what-it-is-and-how-to-use/) give you a continuous, receiver-reported view of every source sending mail as your domain. The value in an incident like this is not the pass or fail column. It is the behavioral baseline. When you know what normal looks like for your domain, abnormal becomes visible: - A familiar sending service suddenly emitting from a new IP or a new geography. - A volume spike from a transactional path that normally sends a predictable trickle. - A new DKIM selector appearing on mail from infrastructure you thought you fully understood. - Sends at hours, or to patterns of recipients, that do not match your usual traffic. None of those are authentication failures. All of them are anomalies you can only see if you are [actually reading your reports](/blog/how-to-read-dmarc-reports-guide-2026/) rather than just confirming that everything passed. This is the shift the Blesta case should drive: from “are we passing” to “does this traffic look like us.” The first question is table stakes. The second is where real detection lives. A monitoring platform like [DMARCReport](/) exists to surface that second answer, by normalizing sources across receivers and making deviation from your own baseline obvious instead of buried. ## What to actually do The fix for authenticated abuse is not more authentication. It is defense in depth on both sides of the message. **If you operate infrastructure that sends on a domain’s behalf** (a billing platform, a SaaS notifier, a help desk, an MSP managing client mail): - **Least privilege on who and what can trigger a send.** The Blesta opening was an over-privileged temporary account. Notification and broadcast rights should be scoped tightly and expire automatically. - **Change control on sensitive templates.** A message that announces a breach, demands payment, or asks for credentials should never be a single account action away from going out. Require approval for high-impact content. - **Separate API keys per application and environment.** One leaked or abused key should not equal full sending capability across your whole platform. Scope and rotate them. - **Retain transactional mail event logs.** When something does go out, forensic answers depend on being able to reconstruct exactly what was sent, by whom, and from where. - **Monitor your own sending for anomalies,** using the DMARC aggregate-report signals above, so an unusual blast is caught in hours rather than discovered by your customers. **If you receive mail from vendors you depend on:** - **Stop equating authenticated with safe.** A green DMARC result means the domain is real. It does not mean the demand inside is. This single mental correction is the most valuable takeaway from the whole episode. - **Verify high-stakes asks out of band.** Any ransom note, payment change, or credential request, even one that authenticates perfectly, gets confirmed through a separate channel you already trust. This is the same discipline that defeats [business email compromise](/blog/business-email-compromise-vs-phishing-attacks-explained-by-dmarcreport/), and it applies just as well when the sender is genuine but compromised. - **Watch for the behavioral tells,** not just the authentication result: a vendor suddenly contacting you over an unusual channel like a peer-to-peer messenger, a hard countdown deadline, or a tone that does not match their normal communications. Worth naming directly: DMARC genuinely does prevent a large category of [vendor email compromise](/blog/how-does-dmarc-prevent-vendor-email-compromise/), namely the kind where attackers impersonate a vendor from outside. What it cannot prevent is a vendor’s own authorized system being turned against you from the inside. Knowing which problem you are facing is the whole game. ## Frequently asked questions **Did DMARC fail in the Blesta incident?**No. DMARC worked exactly as designed. It confirmed the message genuinely came from Blesta’s authorized infrastructure, which it did. DMARC verifies that a message is authorized by the domain. It does not, and was never meant to, verify that the content is legitimate or that the sending account was not compromised. **How can a ransom email pass SPF, DKIM, and DMARC?**Because it was not spoofed. The attacker sent it through Blesta’s own authenticated mail path after gaining access to a privileged account, so SPF, DKIM, and DMARC all validated a message that really did originate from the domain. This is authenticated abuse, which is different from the unauthenticated spoofing that DMARC is built to block. **If authentication cannot stop this, is DMARC still worth it?**Yes, emphatically. DMARC stops the vast majority of email attacks, which are impersonation from outside your infrastructure. Authenticated abuse is a smaller, harder category that requires different controls. You need DMARC for the common case and access control plus monitoring for the rare one. They are complementary, not alternatives. **Can DMARC reports help me catch this kind of attack?**Reports will not block it, but they can help you spot it. Aggregate reports establish what normal sending looks like for your domain, so anomalies like a new sending IP, a volume spike, or a new DKIM selector on known infrastructure become visible. Detection depends on reading your reports for behavior, not just confirming that mail passed. **What is the single most important lesson?**Authenticated is not the same as trustworthy. A passing DMARC result proves a domain is real. It does not prove the message should be believed. Treat high-stakes demands as unverified until you confirm them through a separate channel, no matter how cleanly they authenticate. ## The takeaway The Blesta ransom email is a strange kind of success story for email authentication. Every control did its job. SPF, DKIM, and DMARC told the truth: this message really is from Blesta. The failure was upstream of email entirely, in an account that should not have had the keys, and downstream of it, in the human habit of reading a green checkmark as a guarantee of good intent. Keep your domain at enforcement. It is still the right thing, and it still blocks the attacks that authentication can block. Then build the layer authentication was never going to give you: tight control over who can send in your name, a baseline of what your own mail looks like, and the discipline to verify the message that scares you, even when, especially when, it passes every check. ## Topics [ DMARC ](/tags/dmarc/)[ phishing ](/tags/phishing/)[ email security ](/tags/email-security/) ![Brad Slavin](https://media.mailhop.org/dmarcreport/images/team/brad-slavin.jpg) [ Brad Slavin ](/authors/brad-slavin/) General Manager Founder and General Manager of DuoCircle. Product strategy and commercial lead for DMARC Report's 2,000+ customer base. [LinkedIn Profile →](https://www.linkedin.com/in/bradslavin) ## Take control of your DMARC reports Turn raw XML into actionable dashboards. Start free - no credit card required. [Start Free Trial](https://app.dmarcreport.com/signup?plan=free) [Check Your DMARC Record](/tools/dmarc-checker/) ## Related Articles [ Intermediate 3m Device Code Phishing, iOS 18 Relief, Global Fraud Disrupted Apr 9, 2026 ](/blog/device-code-phishing-ios-18-relief-global-fraud-disrupted/)[ Intermediate 8m Best DMARC Reporting Tools in 2026: Honest Comparison Mar 25, 2026 ](/blog/best-dmarc-reporting-tools-2026/)[ Intermediate 8m Decoding I-Tag DKIM Vulnerability and Its Impact on Email Deliverability and Security Jun 6, 2024 ](/blog/decoding-i-tag-dkim-vulnerability-and-its-impact-on-email-security/)[ Intermediate 4m DKIM Key Rotation Best Practices: Here's What Large Organizations Should Know Apr 8, 2026 ](/blog/dkim-key-rotation-best-practices-for-large-organizations-should-know/) ```json {"@context":"https://schema.org","@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com","logo":{"@type":"ImageObject","url":"https://dmarcreport.com/images/dmarcreport-logo.png"},"description":"DMARC reporting and email authentication management. Monitor aggregate and forensic DMARC reports, analyze authentication results, and enforce DMARC policies across all your domains.","parentOrganization":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138883901","name":"DuoCircle LLC","url":"https://www.duocircle.com","sameAs":["https://www.wikidata.org/wiki/Q138883901","https://www.crunchbase.com/organization/duocircle-llc","https://www.linkedin.com/company/duocircle","https://github.com/duocircle"],"subOrganization":[{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897474","name":"AutoSPF","url":"https://autospf.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897912","name":"Phish Protection","url":"https://www.phishprotection.com"}]},"sameAs":["https://www.wikidata.org/wiki/Q138898167","https://www.linkedin.com/company/duocircle","https://x.com/duocirclellc","https://www.g2.com/products/dmarc-report/reviews","https://github.com/duocircle","https://www.crunchbase.com/organization/duocircle-llc","https://www.trustradius.com/products/duocircle/reviews"],"aggregateRating":{"@type":"AggregateRating","ratingValue":"4.8","reviewCount":"471","bestRating":"5","worstRating":"1","url":"https://www.g2.com/products/dmarc-report/reviews"},"contactPoint":{"@type":"ContactPoint","contactType":"customer support","url":"https://dmarcreport.com/support/"},"knowsAbout":["DMARC","DMARC Reporting","DMARC Aggregate Reports","DMARC Forensic Reports","Sender Policy Framework","DKIM","Email Authentication","Email Security","DNS Management","Email Deliverability"]} ``` ```json {"@context":"https://schema.org","@type":"WebSite","name":"DMARC Report","url":"https://dmarcreport.com","description":"DMARC reporting and email authentication management. Monitor aggregate and forensic DMARC reports, analyze authentication results, and enforce DMARC policies across all your domains.","publisher":{"@type":"Organization","name":"DMARC Report","url":"https://dmarcreport.com","logo":{"@type":"ImageObject","url":"https://dmarcreport.com/images/dmarcreport-logo.png"},"description":"DMARC reporting and email authentication management. Monitor aggregate and forensic DMARC reports, analyze authentication results, and enforce DMARC policies across all your domains.","parentOrganization":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138883901","name":"DuoCircle LLC","url":"https://www.duocircle.com","sameAs":["https://www.wikidata.org/wiki/Q138883901","https://www.crunchbase.com/organization/duocircle-llc","https://www.linkedin.com/company/duocircle","https://github.com/duocircle"],"subOrganization":[{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897474","name":"AutoSPF","url":"https://autospf.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897912","name":"Phish Protection","url":"https://www.phishprotection.com"}]}}} ``` ```json [{"@context":"https://schema.org","@type":"BlogPosting","headline":"DMARC Passed. The Email Was Still an Attack. Inside the Blesta Ransom Incident","description":"A ransom email from no-reply@blesta.com passed SPF, DKIM, and DMARC because it came from Blesta's own infrastructure. Here is why that is not a DMARC failure, and what authenticated abuse means for the way you read trust into email.","url":"https://dmarcreport.com/blog/blesta-ransom-email-dmarc-passed-authenticated-abuse/","datePublished":"2026-06-28T12:00:00.000Z","dateModified":"2026-06-28T12:00:00.000Z","dateCreated":"2026-06-28T12:00:00.000Z","author":{"@type":"Person","@id":"https://dmarcreport.com/authors/brad-slavin/#person","name":"Brad Slavin","url":"https://dmarcreport.com/authors/brad-slavin/","jobTitle":"General Manager","description":"Brad Slavin is the founder and General Manager of DuoCircle, the company behind DMARC Report, AutoSPF, Phish Protection, and Mailhop. He founded DuoCircle in 2014 and has led the company's growth to 2,000+ customers across its email security product family. Brad's focus is product strategy, customer relationships, and the commercial and compliance side of email authentication (DPAs, SLAs, enterprise procurement).","image":"https://media.mailhop.org/dmarcreport/images/team/brad-slavin.jpg","knowsAbout":["Email Security Strategy","SaaS Product Management","Enterprise Compliance","Customer Success","Email Deliverability Business"],"worksFor":{"@type":"Organization","name":"DMARC Report","url":"https://dmarcreport.com"},"sameAs":["https://www.linkedin.com/in/bradslavin"]},"publisher":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com","logo":{"@type":"ImageObject","url":"https://dmarcreport.com/images/dmarcreport-logo.png"},"description":"DMARC reporting and email authentication management. Monitor aggregate and forensic DMARC reports, analyze authentication results, and enforce DMARC policies across all your domains.","parentOrganization":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138883901","name":"DuoCircle LLC","url":"https://www.duocircle.com","sameAs":["https://www.wikidata.org/wiki/Q138883901","https://www.crunchbase.com/organization/duocircle-llc","https://www.linkedin.com/company/duocircle","https://github.com/duocircle"],"subOrganization":[{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897474","name":"AutoSPF","url":"https://autospf.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897912","name":"Phish Protection","url":"https://www.phishprotection.com"}]},"sameAs":["https://www.wikidata.org/wiki/Q138898167","https://www.linkedin.com/company/duocircle","https://x.com/duocirclellc","https://www.g2.com/products/dmarc-report/reviews","https://github.com/duocircle","https://www.crunchbase.com/organization/duocircle-llc","https://www.trustradius.com/products/duocircle/reviews"],"aggregateRating":{"@type":"AggregateRating","ratingValue":"4.8","reviewCount":"471","bestRating":"5","worstRating":"1","url":"https://www.g2.com/products/dmarc-report/reviews"},"contactPoint":{"@type":"ContactPoint","contactType":"customer support","url":"https://dmarcreport.com/support/"},"knowsAbout":["DMARC","DMARC Reporting","DMARC Aggregate Reports","DMARC Forensic Reports","Sender Policy Framework","DKIM","Email Authentication","Email Security","DNS Management","Email Deliverability"]},"mainEntityOfPage":{"@type":"WebPage","@id":"https://dmarcreport.com/blog/blesta-ransom-email-dmarc-passed-authenticated-abuse/"},"articleSection":"intermediate","keywords":"DMARC, phishing, email security","wordCount":2450,"image":{"@type":"ImageObject","url":"https://media.mailhop.org/dmarcreport/images/2022/04/dmarc-report-4236.jpg","caption":"A ransom email that passed SPF, DKIM, and DMARC from a vendor's own infrastructure","width":900,"height":600},"speakable":{"@type":"SpeakableSpecification","cssSelector":[".answer-block","h1"]}}] ``` ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://dmarcreport.com/"},{"@type":"ListItem","position":2,"name":"Blog","item":"https://dmarcreport.com/blog/"},{"@type":"ListItem","position":3,"name":"Intermediate","item":"https://dmarcreport.com/intermediate/"},{"@type":"ListItem","position":4,"name":"DMARC Passed. The Email Was Still an Attack. Inside the Blesta Ransom Incident","item":"https://dmarcreport.com/blog/blesta-ransom-email-dmarc-passed-authenticated-abuse/"}]} ```