Mailgun made API-key abuse a transactional-email accountability test

Summary

• Mailgun's accountability issue is not framed here as a single unverified breach; it is the recurring platform problem created when API keys, domains, send permissions, and deliverability reputation become shared abuse surfaces.
• A transactional email platform can prevent customer harm only if key custody, account takeover detection, outbound throttling, domain authentication, suppression handling, abuse reporting, and customer notice work as one evidence system.
• The practical control chain is shared: Mailgun controls platform defaults, key tooling, monitoring, policy enforcement, and support response; customers control application secrets, repository hygiene, least privilege, domain setup, and rotation discipline.
• Deliverability harm is a cost-transfer problem because one compromised sender or weak authentication setup can damage reputation, delay legitimate mail, trigger blocks, and impose cleanup work on innocent recipients and customers.
• The public evidence supports a high-confidence control analysis, while private telemetry, customer-specific abuse events, and individual account investigations remain outside the public record.

Why API-key abuse is an accountability issue for transactional email

Mailgun made API-key abuse a transactional-email accountability test because an email API key is not just a developer convenience. It is a sending authority. If an attacker obtains a key, abuses a weak account, or compromises an integration that can call the platform, the result may not look like a traditional breach at first. It may look like sudden phishing traffic, unexpected spam volume, bounces, account suspension, degraded domain reputation, delayed password-reset mail, failed invoices, or support tickets from customers who no longer receive important messages. That makes the control problem operational, not only technical.

Mailgun's own public materials establish the service context. The company security page at https://www.mailgun.com/security/ frames trust and platform security commitments. API-key guidance at https://documentation.mailgun.com/docs/mailgun/user-manual/security/api-keys identifies credentials as an operational control point. Sending documentation at https://documentation.mailgun.com/docs/mailgun/user-manual/sending-messages, domain setup material at https://documentation.mailgun.com/docs/mailgun/user-manual/domains, and authentication guidance at https://documentation.mailgun.com/docs/mailgun/user-manual/domains/authentication show that customers are expected to connect application workflows, sending domains, authentication records, and reputation controls. The public status page at https://status.mailgun.com/ provides availability context, but availability is only one part of the abuse file.

The article deliberately avoids inventing a single dated Mailgun breach. The evidence base is broader and more durable. Transactional email platforms face abuse whenever credentials are leaked, applications are compromised, domains are misconfigured, accounts are taken over, or customers send risky traffic. Mailgun may detect and block some abuse. Customers may cause some abuse by poor secret handling. Mailbox providers may impose authentication and reputation rules that shape deliverability. Recipients may suffer phishing or spam regardless of which organization failed first. Accountability asks who had practical control at each step.

The public standard for credential risk is well established. GitHub's secret-scanning documentation at https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning and supported-pattern material at https://docs.github.com/en/code-security/reference/secret-security/supported-secret-scanning-patterns show how exposed service credentials have become a routine software-supply risk. CWE entries such as hard-coded credentials at https://cwe.mitre.org/data/definitions/798.html and insufficiently protected credentials at https://cwe.mitre.org/data/definitions/522.html provide weakness vocabulary. MITRE ATT&CK's unsecured credentials technique at https://attack.mitre.org/techniques/T1552/ explains why secrets in files, repositories, logs, or configuration become attack material. Those sources are not Mailgun-specific accusations. They define the control environment in which Mailgun and its customers operate.

The accountability file therefore starts with a precise question: who can prevent a sending credential from becoming an abuse weapon, who can detect it once it happens, who can limit the blast radius, and who bears the cost when deliverability reputation is damaged? Mailgun controls platform-side key tooling, account security features, policy enforcement, outbound monitoring, suspension, support escalation, and customer notice. Customers control secret storage, repository hygiene, application permissions, key rotation, domain DNS records, and whether they treat email as critical infrastructure.

Mailbox providers control acceptance, filtering, reputation, and authentication enforcement. Recipients absorb the first human risk of phishing or fraud. The duty is shared, but the evidence should not be vague.

The API key is both automation credential and abuse weapon

A transactional email API key works because it is trusted by automation. A SaaS product can send password resets, invoices, alerts, receipts, onboarding mail, account-change notices, and support updates without human intervention. That same property makes the key dangerous if stolen. An attacker does not need to break into every downstream application if a single credential can send convincing mail through infrastructure that has already been authorized by DNS, domain reputation, and mailbox-provider history.

Mailgun's API-key documentation at https://documentation.mailgun.com/docs/mailgun/user-manual/security/api-keys is therefore not merely operational help. It is a control surface. Key creation, naming, permissions, rotation, revocation, and auditability determine whether a customer can practice least privilege. A mature platform makes it easy to issue scoped keys, identify old keys, rotate without downtime, detect anomalous use, and revoke suspicious credentials quickly. A mature customer uses those tools, avoids embedding keys in source code, separates production and test credentials, limits access to environment variables, and treats email keys as high-value secrets.

The accountability question becomes sharper when a small business uses a transactional email provider. Small teams often lack a dedicated security function. A developer may copy a key into a local file, paste it into a CI variable, place it in a mobile app by mistake, or commit it to a repository. GitHub secret scanning can reduce that risk for supported patterns, but detection after exposure is still a race. Once a credential is public, attackers can automate abuse quickly. The platform's ability to identify abnormal sending, freeze traffic, and notify the customer becomes part of the customer's security posture.

This is where prevention and response meet. If a key has wide sending authority, response must be fast because the blast radius is large. If the key is scoped by domain, route, account, or permission, response may be more targeted. If logs show which key sent which messages, the customer can separate legitimate mail from abuse. If logs are incomplete or support is slow, the customer may be forced to assume broad compromise. The platform's evidence quality decides whether cleanup is surgical or chaotic.

The article's root issue is that a credential is not just a customer's problem once it can harm public email recipients and other platform users. A stolen key may be customer's secret-management failure, but the platform still controls volume thresholds, anomaly detection, suspension, authentication enforcement, bounce handling, complaint handling, and reputation remediation. The attacker creates abuse, the customer may create an opening, and the provider controls the platform's ability to limit public harm.

Deliverability reputation turns abuse into shared economic harm

Email deliverability is an economic system as much as a technical system. Senders want legitimate messages delivered. Mailbox providers want to protect recipients from spam and phishing. Transactional email platforms want to maintain sending reputation. Recipients want useful mail without fraud. Abuse harms all of them, but the cost is not distributed evenly. A compromised customer can damage a domain or IP reputation. Other legitimate mail may be delayed or filtered. Customer support volume rises. Recipients receive phishing. Small businesses may miss password resets, invoices, or critical alerts.

The cost spreads beyond the account that lost control.

Mailgun documentation on suppressions at https://documentation.mailgun.com/docs/mailgun/user-manual/sending-messages/suppressions, tracking at https://documentation.mailgun.com/docs/mailgun/user-manual/tracking-messages, and reputation at https://documentation.mailgun.com/docs/mailgun/user-manual/reputation shows the operational categories that matter: bounces, complaints, unsubscribes, engagement signals, and sender reputation. These are not cosmetic metrics. They are the operating record that decides whether mail continues to flow. If abuse traffic raises complaints or triggers blocks, the recovery problem becomes more than rotating a key. It becomes restoring trust with mailbox providers and recipients.

Mailbox-provider rules make the accountability file even clearer. Google sender guidance at https://support.google.com/a/answer/81126, Yahoo sender best practices at https://senders.yahooinc.com/best-practices/, and email authentication standards such as SPF at https://datatracker.ietf.org/doc/html/rfc7208, DKIM at https://datatracker.ietf.org/doc/html/rfc6376, and DMARC at https://datatracker.ietf.org/doc/html/rfc7489 show that senders are expected to authenticate mail, manage complaint rates, and align domain identity. These requirements mean a transactional platform is not only delivering messages. It is helping customers maintain a reputation passport.

When a credential is abused, that passport can be damaged. A customer may have to pause sending, clean lists, review templates, examine logs, rotate keys, adjust DNS, contact support, and wait for reputation recovery. Some of those tasks are customer duties. But the platform controls how quickly abuse is detected, whether traffic is throttled before reputation damage spreads, whether suspicious spikes are explained, whether logs are usable, and whether support can distinguish compromised automation from ordinary high-volume sending.

This is the cost-transfer problem. If the platform's controls are weak, the cost of abuse is transferred to recipients, mailbox providers, and innocent customers. If customer secret hygiene is weak, the cost is transferred to the platform's abuse team and other senders. A mature accountability record measures both. It does not simply blame the customer or the platform. It asks whether each party had the practical controls needed to prevent the harm it was best positioned to stop.

Customer account security is part of platform reliability

Transactional email customers often think of account security as a login issue. It is broader. An account controls domains, API keys, authorized senders, billing, suppression lists, logs, templates, webhooks, routes, and support access. If an attacker takes over an account, the risk can extend from fraudulent mail to data exposure, configuration tampering, reputation damage, and interruption of legitimate communications. Account takeover detection is therefore part of platform reliability, not only user security.

Mailgun's security page at https://www.mailgun.com/security/ and customer security documentation around keys and authentication identify public control categories, while CISA's MFA guidance at https://www.cisa.gov/secure-our-world/turn-mfa and phishing guidance at https://www.cisa.gov/news-events/news/avoiding-social-engineering-and-phishing-attacks show the baseline for account protection and social-engineering risk. Customers should use multi-factor authentication where available, restrict administrative access, review users, monitor unusual logins, and separate duties. The provider should make those controls visible, enforceable, and easy to audit.

The practical question is what happens before and after takeover. Before takeover, does the platform encourage or require strong authentication for sensitive actions? Are API keys visible only to authorized users? Are key creation and deletion logged? Are domain changes protected? Are billing changes and sending-limit changes reviewed? After takeover, can the provider identify which admin actions occurred, which keys were created, which messages were sent, which domains were changed, and which suppressions or logs were accessed? Without that evidence, a customer may recover the account but not know what changed.

Security automation must be tuned to email behavior. A sudden login from a new geography, a new key followed by high-volume sending, a domain-authentication change, a new webhook, or an unusual template change can be more meaningful together than separately. A provider that sees platform-wide patterns is often better positioned than a small customer to detect abuse. That advantage creates responsibility. It does not require the provider to prevent every customer failure, but it does require measurable detection and escalation.

Account security also affects customer notice. If Mailgun detects suspicious use of a key or account, the customer needs to know what happened in terms that map to action: which key, which domain, which messages, what volume, what recipients or recipient categories where available, what time window, what actions were taken, and what should be rotated or reviewed. Generic advice to secure the account is weaker than an incident-specific action list. In email, vague notice prolongs deliverability damage.

Outbound abuse controls should be treated as operating controls

Abuse controls on an email platform are often discussed as anti-spam features. They should be treated as operating controls. They decide whether one customer's compromise becomes a broad public harm event. They also decide whether legitimate customers are protected from the reputation consequences of other users' abuse. Abuse detection, volume limits, content signals, complaint monitoring, bounce analysis, new-domain warmup, support review, and suspension policies are therefore part of the platform's reliability system.

OWASP's API Security material on broken authentication at https://owasp.org/API-Security/editions/2023/en/0xa2-broken-authentication/ and unrestricted resource consumption at https://owasp.org/API-Security/editions/2023/en/0xa4-unrestricted-resource-consumption/ is useful because email API abuse combines credential misuse and scale. A key that can send one message may be harmless. A key that can send one million phishing messages can create public harm. The platform must treat volume, velocity, recipient patterns, complaint spikes, and content anomalies as risk signals. A static credential check is not enough.

Mailgun's sending and reputation materials show that the platform already operates in a world of thresholds and signals. The accountability question is how those signals are used when abuse is suspected. Does Mailgun throttle new or anomalous senders? Does it distinguish a legitimate product launch from a compromised account? Does it warn customers before blocking when possible? Does it suspend quickly when recipient harm is likely? Does it provide an appeal route when controls misfire? Both false negatives and false positives matter. A platform that lets abuse continue harms recipients.

A platform that blocks legitimate transactional mail without useful explanation can harm customers.

The balance is difficult because attackers adapt. They may send low volume, use convincing templates, target specific recipients, or abuse a domain with existing reputation. They may also use compromised accounts to test deliverability before scaling. A strong platform needs layered controls: customer onboarding, domain verification, key management, anomaly detection, complaint loops, mailbox-provider signals, support escalation, and incident review. The public does not need every detection threshold. Customers do need evidence that these categories exist and that support can explain actions.

This is why status pages are incomplete evidence. https://status.mailgun.com/ can show operational incidents and service health. A platform can be technically available while an account is abusing credentials, a domain is blocked, or a customer is under suspension review. Availability status does not equal abuse-control health. A customer experiencing deliverability failure needs a different evidence path: logs, suppression data, complaint indicators, support responses, and clear reason codes.

Domain authentication is where platform and customer duties meet

Email authentication is a shared boundary. Mailgun can document setup, validate records, and provide sending infrastructure. Customers must publish correct DNS records and align their domain practices. Mailbox providers then evaluate identity, reputation, alignment, and recipient response. This three-party structure makes accountability easy to blur. When mail fails, a customer may blame the platform, the platform may point to DNS, and mailbox providers may point to sender reputation. The recipient only sees whether the message arrived and whether it was trustworthy.

Public standards help separate duties. SPF, described at https://datatracker.ietf.org/doc/html/rfc7208, allows a domain to publish which systems may send for it. DKIM, described at https://datatracker.ietf.org/doc/html/rfc6376, allows cryptographic signing of messages. DMARC, described at https://datatracker.ietf.org/doc/html/rfc7489, ties alignment and policy reporting to domain identity. Google and Yahoo sender guidance add modern operational expectations for authenticated bulk and transactional sending. Mailgun domain authentication documentation at https://documentation.mailgun.com/docs/mailgun/user-manual/domains/authentication is the platform-specific bridge between standards and customer setup.

The accountability question is whether setup evidence is durable. A customer should be able to see which domains are verified, which records are missing or misconfigured, which keys are active, which messages pass authentication, and which failures affect deliverability. If a credential is abused, domain authentication does not by itself prevent abuse; the mail may still be authenticated if the attacker uses a valid sending path. That is exactly why API-key custody and outbound monitoring matter. Authentication proves domain authorization; it does not prove message legitimacy.

Domain authentication also affects recovery. If abuse damages a domain's reputation, the customer may need to rotate keys, pause mail, review templates, correct DNS, enforce DMARC policy, and monitor reports. Mailgun can help by providing clear diagnostics and support. Mailbox providers can help through feedback loops and best-practice guidance. But the cost of delayed or blocked mail falls first on the customer and recipient. Password resets, invoices, account alerts, and compliance notices are not optional communications for many businesses.

The shared boundary should not become a shared excuse. Mailgun can say a customer controls DNS, but it still controls product guidance, validation, warnings, and sending enforcement. Customers can say Mailgun is the platform, but they still control whether keys are protected and records are configured. Mailbox providers can say senders must authenticate, but their filters also shape recoverability. Accountability follows practical control, not brand visibility.

Support escalation and notice decide whether cleanup is possible

When email abuse occurs, minutes matter. A compromised key can send quickly. Complaints can accumulate quickly. Reputation can degrade before a small team understands what happened. Support escalation is therefore an accountability control. The relevant question is not whether a support channel exists. It is whether the customer can reach the right response path, receive account-specific evidence, stop abuse, rotate credentials, restore legitimate sending, and understand deliverability recovery.

Mailgun support and documentation materials provide product context, but the public record cannot show every private support interaction. The accountability standard can still define what good support evidence should contain. A customer should receive the affected key or account identifier, the first and last observed suspicious activity, the sending volume, the domains involved, the policy action taken, the steps required for reinstatement where applicable, and guidance on recipient notice if phishing or fraud occurred.

If support cannot disclose recipient-level detail for privacy or security reasons, it should provide aggregate evidence sufficient for customer action.

Notice should also distinguish security events from policy enforcement. If a customer's traffic is blocked because it looks abusive, the customer needs to know whether the platform believes the account was compromised, the content violated policy, the list quality was poor, DNS was misconfigured, complaint rates were too high, or mailbox providers imposed blocks. Different causes require different repairs. A vague suspension notice can turn a solvable security problem into a business interruption.

For recipients, the notice problem is even harder. A platform may not have a direct relationship with recipients of customer mail. If phishing is sent through a compromised customer, the customer may need to notify its users. The platform needs to provide enough evidence for that downstream notice without overexposing recipient data. This is where abuse-contact economics matters. The entity with telemetry may not be the entity with the user relationship. The entity with the user relationship may not have enough logs. If the evidence does not move efficiently, harm is transferred to recipients and support teams.

CISA and FTC small-business cybersecurity guidance at https://www.ftc.gov/business-guidance/resources/cybersecurity-small-business and phishing guidance at https://www.cisa.gov/news-events/news/avoiding-social-engineering-and-phishing-attacks show that small organizations are expected to protect users, but they often need concrete vendor evidence. A transactional email platform that serves developers and small businesses should assume that its support record may become the customer's incident record. That raises the evidence bar.

Secret leakage is a software-lifecycle failure, not only a user mistake

API-key leakage often happens inside the software lifecycle: local development files, CI logs, build systems, deployment variables, shared snippets, public repositories, copied configuration, or third-party integration platforms. Treating leakage only as careless user behavior misses the system that produces it. Developers work under speed pressure. Small teams reuse environments. Documentation sometimes encourages quick starts. Frameworks generate configuration files. CI systems expose variables in complex ways. The platform's job is not to eliminate customer responsibility but to design for predictable mistakes.

GitHub secret scanning at https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning is evidence that the industry treats exposed secrets as a continuous risk. Supported patterns at https://docs.github.com/en/code-security/reference/secret-security/supported-secret-scanning-patterns show how providers can participate in detection. If a Mailgun key appears in a public repository and is detected, the best outcome is rapid notification, automatic or guided revocation, and clear rotation steps. If detection is delayed or the customer misses the alert, platform-side anomaly detection becomes the next defense.

The lifecycle view changes the accountability question. A provider should ask whether keys are easy to scope, easy to rotate, easy to name, easy to audit, and hard to accidentally expose. Documentation should encourage environment-variable storage, least privilege, separate development and production keys, and rotation. Dashboards should make stale keys visible. Webhooks or alerts should notify unusual use. Customers should integrate secret scanning, avoid client-side exposure, use vaults, and treat email keys as production credentials.

Hard-coded credential weaknesses at https://cwe.mitre.org/data/definitions/798.html and limited public evidence protection at https://cwe.mitre.org/data/definitions/522.html show that the failure mode is familiar. Familiar failure modes deserve engineered guardrails. A platform that knows customers frequently mishandle secrets has reason to invest in detection and limit design. A customer that knows email keys can be abused has reason to invest in secret management. The existence of shared responsibility does not dilute responsibility; it identifies multiple control owners.

This also affects procurement. A buyer evaluating Mailgun or any transactional email platform should not ask only for uptime, price, or throughput. It should ask for key-scoping features, audit logs, anomaly alerts, secret-scanning partnerships, rotation workflows, suspension policies, and deliverability-repair support. The cost of abuse is not theoretical. It appears in blocked password resets, missed customer notices, and brand damage after phishing.

Phishing risk makes recipient harm part of the platform file

Transactional email infrastructure can make phishing more convincing because recipients are trained to trust routine messages: password resets, account notices, invoices, shipping updates, verification codes, and support replies. If an attacker sends through a compromised legitimate sender path, the message may inherit some trust signals even if content is malicious. This is why abuse-control accountability must include recipients, not only the paying customer.

CISA phishing guidance at https://www.cisa.gov/news-events/news/avoiding-social-engineering-and-phishing-attacks, FBI and IC3 reporting channels at https://www.ic3.gov/, and FTC small-business guidance show the public harm model. Attackers exploit trust, urgency, and identity cues. A transactional platform cannot inspect every business meaning of every email, but it can monitor sending patterns, known malicious indicators, complaint spikes, domain anomalies, and credential misuse. Customers can design safe templates, protect keys, and provide user education. Recipients can report suspicious messages. Mailbox providers can filter. Each layer reduces risk, but none can replace the others.

The distinction between spam and phishing matters. Spam may waste attention and damage reputation. Phishing may lead to credential theft, payment fraud, malware, or account takeover. If a compromised Mailgun customer sends phishing, the customer may need to warn users that messages appearing to come from its domain were unauthorized. Mailgun's role would be to provide the evidence needed to scope that warning and to stop further sending. Mailbox providers may need to filter or block. Without coordination, recipients remain exposed while organizations debate control boundaries.

The public article should not claim that Mailgun is responsible for every phishing message sent by every customer. That would be too broad. It should claim that a platform selling transactional email has accountability for the controls that make large-scale abuse harder, detect it faster, and make recovery more precise. The customer's misuse or compromise is part of the cause. The platform's monitoring and enforcement are part of the mitigation. Both should be measured.

Recipient harm also highlights why transparency matters. A paying customer may receive support details, but recipients usually do not. If they receive phishing through a compromised sender, they may only see a suspicious message. The customer-facing notice has to be good enough to support recipient-facing warnings when necessary. That means timestamps, subject patterns, sender domains, links, attachment indicators, and remedial guidance. Privacy limits may constrain detail, but no detail at all transfers the burden to the people least equipped to investigate.

Availability status and deliverability status are different evidence lanes

A transactional email platform can be available while a customer's mail fails. The API may accept messages, but mailbox providers may filter them. The platform dashboard may show processing, but recipients may not receive mail. A status page may show all systems operational, while one customer is under abuse review or reputation remediation. This difference is central to accountability because customers often discover deliverability harm through users, not through infrastructure metrics.

Mailgun's status page at https://status.mailgun.com/ is useful for platform availability. Sending, suppressions, tracking, reputation, and authentication documentation provide the customer-specific operating lanes. A mature incident record separates them. Was the platform down? Was the account suspended? Was the domain blocked? Were bounces rising? Were complaints high? Was authentication failing? Was a key abused? Was traffic throttled? A single "operational" status does not answer these questions.

This distinction is especially important for small businesses. A small SaaS company may depend on email for signup, password reset, billing, compliance notices, and support. If deliverability fails, the business may lose revenue or trust before it understands cause. If the provider's evidence is unclear, the customer may rotate keys, change DNS, contact mailbox providers, rewrite templates, and open support tickets all at once. That shotgun response is expensive and may make diagnosis harder.

The accountability standard should require reasoned failure labels. A bounce is not the same as a spam complaint. A spam complaint is not the same as a compromised key. A mailbox-provider block is not the same as a platform outage. A suppression-list issue is not the same as domain misalignment. Each has a different control owner and repair path. Mailgun has public documentation for many of these categories; the accountability question is whether customers can connect documentation to their own incidents quickly.

Deliverability is also where redress becomes practical. If legitimate mail was blocked because a platform control misclassified it, the customer may need support priority, clear explanation, and help restoring reputation. If traffic was blocked because a customer's key was compromised, the customer may need incident guidance and a safe path back. If mailbox providers imposed blocks due to abuse, recovery may take time. Redress is not always money. Often it is evidence, speed, and a credible recovery path.

The platform should also distinguish between customer blame and customer enablement. A customer may have made the first mistake by leaking a key, but the platform may still be the only party with the telemetry to stop abuse before recipient harm grows. A customer may have configured DNS incorrectly, but the platform may still be the best party to show which authentication check failed. A customer may have sent a risky campaign, but the platform may still need to explain whether the issue was complaint rate, list quality, content, domain alignment, or mailbox-provider enforcement.

If the platform collapses every problem into a generic policy outcome, the customer cannot improve. If the platform gives precise cause labels and proportional recovery steps, the same enforcement action becomes an accountability control rather than only a punishment.

The customer side needs the same discipline. Developers should know where keys live, who can view them, which applications use them, how to rotate them, and what breaks when a key is revoked. Marketing and product teams should know that deliverability is not a limitless shared resource. Support teams should know how to recognize reports that password-reset mail or invoice notices are not arriving. Finance and compliance teams should know which transactional messages are business critical. Without that internal map, even a good provider notice may not produce an effective response.

Transactional email is often treated as plumbing until it fails; accountability requires treating it as a dependency before failure.

This is also why abuse metrics should be reviewed after the immediate event. A customer recovering from key abuse should know whether complaint rates returned to baseline, whether bounces stabilized, whether suspicious templates were removed, whether DNS alignment remained valid, and whether new keys are being used only by expected systems. A provider should be able to show enough trend evidence to support that review. Otherwise the customer may reopen sending while reputation is still damaged or continue operating with a hidden second credential. Recovery is not complete when the first key is rotated.

It is complete when legitimate mail is again trustworthy, measurable, and separated from the abuse path.

The evidence should be usable by non-email specialists as well. A founder, school administrator, public-agency manager, or support lead may not understand every SMTP or mailbox-provider signal, but they still need to know whether password resets, invoices, verification links, or safety notices are reaching people. A good abuse-response file translates technical status into business function: which message classes were affected, which domains were involved, which recipient providers were blocking or throttling mail, which keys were revoked, which templates were suspended, and when legitimate delivery returned to baseline.

That translation is a continuity control, not just support courtesy.

What would change the assessment

This article reaches a high-confidence conclusion about the accountability structure because the public technical and policy evidence is strong: Mailgun documents API keys, sending, domains, authentication, suppression, reputation, and service status; public secret-scanning, API-security, weakness, and email-authentication sources establish the risk model; mailbox-provider requirements show that deliverability depends on authenticated and reputable sending. The article does not need to invent a single breach to identify the control problem.

Several private facts would change the assessment in specific cases. A confirmed Mailgun security incident involving platform-side key exposure would increase provider-side responsibility and require incident-specific analysis. Evidence that a particular customer leaked a key in a public repository would increase customer-side responsibility for that event while still leaving platform detection and response questions. Mailbox-provider evidence that blocks came from complaint rates rather than credential abuse would change the repair path. Support records showing delayed or unclear escalation would increase the redress concern.

Logs showing rapid detection, narrow throttling, clear notice, and successful reputation recovery would strengthen the platform's accountability position.

The current public record does not establish exact rates of Mailgun key compromise, a complete list of abuse events, private detection thresholds, customer-specific support outcomes, or recipient-level harm. Those remain unknown from public sources. The article therefore keeps the conclusion structural rather than incident-specific. That is the right frame for a platform-abuse article. Transactional email risk is not only what happened on one date. It is what the platform is designed to prevent, detect, contain, and document every day.

The final accountability finding is practical. Mailgun controls platform features and enforcement that can reduce API-key abuse and deliverability harm. Customers control application secrets, DNS, user permissions, and response discipline. Mailbox providers control filtering and sender requirements. Recipients bear the human risk when those controls fail. A defensible transactional email platform must make that chain auditable. It must treat API keys as high-risk sending authority, deliverability as a shared economic asset, and abuse response as a customer-continuity function rather than an afterthought.