An EU DSA complaint involving email can be confusing because a recipient may be reporting spam, phishing, illegal content, a blocked account, or a perceived lack of response from an email provider. The right response starts by separating the legal complaint route from the immediate technical and abuse-handling work needed to stop harmful or unwanted mail.

Important: This article is technical and operational guidance, not legal advice. The Digital Services Act (DSA) can apply differently depending on the service, its role, where it is established, its users, and the facts of the complaint. Obtain qualified legal advice for regulatory interpretation, formal responses, or disputes.

What an EU DSA complaint means in an email context

The EU Digital Services Act is Regulation (EU) 2022/2065. It creates due-diligence obligations for certain intermediary services, including rules around notices of illegal content, explanations for content-moderation decisions, user redress, transparency, and cooperation with regulators.

For an email-sending business, an EU DSA complaint does not automatically mean that every unwanted message or delivery failure is a DSA violation. Many complaints that arrive under a DSA label are really one of several different issues:

A recipient says they received unsolicited commercial email.
A recipient believes a message is phishing, malware, impersonation, fraud, or another form of illegal activity.
A recipient cannot unsubscribe or continues receiving mail after opting out.
A sender claims that its account, domain, API credential, or messages were suspended without an adequate explanation.
A person believes an email platform failed to process an abuse notice appropriately.
A complaint concerns personal-data processing, which may be primarily a GDPR issue rather than a DSA issue.
A consumer is seeking a remedy for a purchase, subscription, or misleading business practice, which may involve consumer-protection law rather than the DSA.

The DSA distinguishes between service categories. A provider that merely carries, stores, or technically processes information may have a different role from an online platform that disseminates information to the public at the recipient's request. A transactional email API or SMTP relay can be part of an email-delivery chain without necessarily operating as a public-facing online platform for every message it processes.

That classification matters, but it should not become an excuse for inaction. If a credible report alleges phishing, fraud, malware, child sexual abuse material, account compromise, impersonation, or other illegal activity, the operational priority is to preserve evidence, contain risk, investigate, and use the provider's applicable reporting and escalation channels.

Start by classifying the complaint correctly

A good incident response begins with a short triage decision. Do not route every complaint through the same mailbox or treat every report as ordinary deliverability feedback.

Complaint type one: alleged illegal content or conduct

Examples include phishing pages linked from an email, fraudulent invoices, credential theft, malware attachments, impersonation, or scams. This category calls for urgent abuse handling.

Preserve the original message, including the full RFC 5322 headers and MIME parts. Do not rely on a screenshot alone. Screenshots can establish what a recipient saw, but they usually omit the routing, authentication, sending-IP, message-ID, and return-path evidence needed to identify the responsible sender or relay.

Where an allegation is credible, temporarily stop further mail from the affected sending identity, API key, SMTP credential, application, tenant, or domain while the investigation proceeds. The appropriate containment scope depends on the evidence. A single compromised API key may justify revoking that key; a domain-wide pattern may justify pausing the entire sending domain.

Complaint type two: unwanted or unlawful marketing email

A recipient may call a message "spam" even where it is a legitimate account notification, password reset, receipt, or security alert. Conversely, a sender may call a message "transactional" even when it contains promotional content.

Assess the message's actual purpose. A receipt for a completed purchase and a password-reset email are generally operational messages. An email that says "Your account is ready" but mainly promotes upgrades, discounts, or unrelated products may be marketing in substance. Blending promotional content into operational email creates legal, deliverability, and trust risks.

Check consent or another appropriate sending basis where applicable, the message's unsubscribe behavior, suppression-list status, frequency, and whether the recipient has an existing relationship with the sender. For technical remediation, immediately add a proven opt-out address to the relevant suppression system before debating edge cases.

Complaint type three: moderation, suspension, or access decision

A sending provider may suspend an account or block a campaign after detecting abuse signals, policy violations, compromised credentials, or deliverability risk. The customer may describe that action as an EU DSA complaint because they want an explanation or an appeal.

Preserve the decision record: the triggering event, timestamps, account identifiers, relevant evidence, automated signals, human-review notes, scope of the restriction, and communications sent to the affected party. Avoid vague explanations such as "security reasons" when a more meaningful explanation can be given without exposing detection systems, victims, or confidential threat intelligence.

Complaint type four: privacy or data-rights request

A request for access, deletion, correction, restriction, or objection to personal-data processing may be a GDPR request. It should be sent to the controller or the provider's privacy process, not handled as a normal abuse complaint.

Do not use a DSA process to delay a valid privacy request, and do not assume that deleting an email log is always appropriate. Retention obligations, fraud investigations, security needs, and legal claims may affect what can be erased and when. Separate the request intake, identity verification, legal assessment, and deletion workflow.

Preserve the evidence before changing anything

Fast containment is essential, but an unstructured response can destroy the evidence needed to determine what happened. Capture a point-in-time incident record before changing DNS, deleting an account, rotating every credential, or removing messages from queues.

For each disputed email, collect:

The complete original message as an .eml file, including all headers and MIME parts.
The recipient address, the visible From address, Reply-To address, Return-Path, and message subject.
The Message-ID, provider message identifier if available, SMTP transaction ID, and application request ID.
Timestamps in UTC for API submission, SMTP acceptance, queueing, delivery attempt, bounce, complaint, and suppression events.
The sending IP address, HELO/EHLO name where available, authenticated domain, DKIM selector, and envelope sender domain.
SPF, DKIM, and DMARC results from Authentication-Results headers.
The application, service account, API credential, SMTP user, IP allowlist record, or tenant associated with the send.
Links, attachment hashes, landing-page URLs, redirect chains, and any security-scanner verdicts.
Consent records, subscription source, unsubscribe event, and suppression-list history when the issue is unwanted commercial email.
The exact recipient complaint, including its date, language, and requested remedy.

Maintain a simple evidence log with a hash for every original .eml file and attachment. For example, calculate a SHA-256 digest and record the time it was captured. This is not a substitute for formal forensic procedure, but it makes it easier to show that investigators reviewed the same artifact throughout the incident.

A useful case record can be small and structured:

Case ID: ABUSE-2026-00418
Received: 2026-10-18T14:22:08Z
Reporter: recipient@example.net
Allegation: credential-phishing email
Message-ID: <12345.67890@app.example.com>
Sending identity: billing@example.com
DKIM: d=example.com; s=s1; pass
SPF: pass for bounce.example.com
DMARC: pass for example.com
API credential: app-prod-billing (revoked 2026-10-18T14:37:19Z)
Containment: paused affected workflow; blocked destination URL
Evidence SHA-256: [recorded internally]
Owner: security-on-call
Status: investigation open

The point is not to collect everything forever. It is to collect enough to connect the complaint to a message, a sending identity, an application action, and a defensible response.

Read email headers like an incident investigator

Headers are the fastest way to distinguish a forged message from one sent through a provider or domain under investigation. A visible From address alone proves very little.

Identify the visible and envelope identities

The From: header is what recipients usually see. The SMTP envelope sender is commonly reflected in Return-Path: after delivery, and can be different from the visible From address.

A simplified message might contain:

From: Example Billing <billing@example.com>
Reply-To: help@example.com
Return-Path: bounces@bounce.example.com
Message-ID: <abc123.456@app.example.com>

This can be legitimate. Many senders use a separate subdomain for bounce processing. The important question is whether authentication aligns with the visible From domain and whether the message was actually injected through infrastructure controlled by the apparent sender.

Follow the Received chain carefully

Each mail server that processes a message commonly adds a Received: header. Read them from bottom to top to reconstruct the earliest visible part of the delivery path, but remember that headers inserted before a trusted receiving system can be forged.

Trust the Received: lines added by your own systems and by known providers more than arbitrary lines closer to the claimed origin. Match timestamps, sender IPs, TLS information, and provider hostnames against your logs. If the message does not appear in the relevant sending logs, and authentication fails, it may be a spoof rather than an authorized send.

Check authentication results

Look for a header similar to:

Authentication-Results: mx.recipient.example;
 spf=pass smtp.mailfrom=bounce.example.com;
 dkim=pass header.d=example.com header.s=s1;
 dmarc=pass header.from=example.com

A dmarc=pass result generally means the visible From domain aligned with either a passing SPF identity or a passing DKIM identity under the receiver's policy evaluation. It is strong evidence that the message was authenticated for that domain, but it does not prove that the message was authorized by every person at the organization. A compromised application credential can send fully authenticated phishing mail.

Conversely, spf=fail, dkim=none, and dmarc=fail may indicate spoofing, but not always. Forwarding, mailing lists, and misconfigured authentication can complicate results. Treat authentication as evidence, not a complete verdict.

Secure the sending path: SPF, DKIM, and DMARC

Authentication is not a legal-compliance checkbox. It is an operational control that helps recipients distinguish authorized mail from simple impersonation, helps domain owners discover unauthorized use, and improves the quality of abuse investigations.

SPF: authorize the actual envelope senders

SPF is published as a DNS TXT record. It tells receiving systems which hosts or delegated policies are authorized to send mail using a domain in the SMTP MAIL FROM identity or HELO/EHLO identity.

A syntactically valid example is:

example.com. 3600 IN TXT "v=spf1 include:spf.provider.example -all"

Do not copy the fictional spf.provider.example value into production. Your provider should supply its exact include domain or IP mechanisms. If you send from multiple systems, combine their mechanisms into one SPF TXT record rather than publishing several separate v=spf1 records.

For example, this is structurally valid when the named services are real and authorized for your domain:

example.com. 3600 IN TXT "v=spf1 include:_spf.google.com include:spf.provider.example -all"

SPF has a practical DNS-lookup limit. A long chain of include, a, mx, exists, redirect, and some ptr mechanisms can exceed the evaluation limit and produce permerror. Use tools such as MXToolbox, dig, or a provider's domain-authentication checker to inspect the published record, but validate against the actual sending architecture before flattening or simplifying anything.

DKIM: sign each message with a controlled selector

DKIM signs selected headers and parts of a message body. Receivers use the public key published in DNS to verify that the message was signed by the stated domain and was not materially modified after signing.

A provider may ask you to publish a CNAME similar to this:

s1._domainkey.example.com. 3600 IN CNAME s1.domainkey.mail.example.net.

The exact target is provider-specific. Do not guess it, remove the trailing dot in a zone-file context unless your DNS interface handles it correctly, or reuse a selector assigned to another service without confirming the configuration.

Some deployments publish the public key directly as TXT:

s1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=BASE64_PUBLIC_KEY_MATERIAL"

In production, the p= value must be the complete public key generated for that selector. Never put private-key material in DNS. Rotate selectors periodically and keep old selectors available long enough for delayed mail and forensic verification, subject to your security policy.

DMARC: begin with visibility, then enforce deliberately

DMARC uses the visible From domain and checks alignment with SPF and/or DKIM. It also lets the domain owner request aggregate reports.

A valid monitoring example is:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s; pct=100"

This requests aggregate reports without asking receivers to quarantine or reject mail. Strict alignment values, adkim=s and aspf=s, require exact-domain alignment and can expose previously hidden configuration problems. Many organizations begin with relaxed alignment, inventory all legitimate senders, then decide whether strict alignment is appropriate.

After reviewing reports and correcting legitimate streams, a policy might become:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; pct=100"

Eventually, some domains adopt p=reject. That can reduce straightforward spoofing, but it can also disrupt legitimate mail if every sending source is not properly aligned. DMARC reports are valuable incident evidence because they may reveal unknown senders, forgotten vendors, or active domain abuse. They do not guarantee inbox placement and do not replace abuse monitoring.

Investigate API and SMTP delivery records

Email infrastructure usually has two submission paths: an HTTP-based REST API and SMTP relay. Investigate both, because an attacker may compromise one integration while the other remains clean.

What to collect from a REST API workflow

For an API-sent message, preserve the request timestamp, authentication principal, source IP, endpoint, HTTP status, response body, request ID, recipient count, sender identity, template or payload version, tags or metadata, and any asynchronous event identifiers.

An HTTP 202 Accepted commonly means a service accepted a message for later processing; it does not prove final recipient delivery. A 400 Bad Request generally indicates a malformed request, while 401 Unauthorized or 403 Forbidden indicates an authentication or authorization problem. A 429 Too Many Requests means rate limiting, and 5xx responses usually indicate a server-side or temporary failure condition.

Do not equate acceptance with delivery in a complaint response. Build the timeline through subsequent events: queued, processed, deferred, delivered, bounced, dropped, blocked, unsubscribed, or marked as spam. Names vary by provider, so retain the raw event payload and map it to your internal terminology.

What to collect from an SMTP workflow

For SMTP, preserve the authenticated username or certificate identity, connecting IP, HELO/EHLO value, TLS status, envelope sender, every recipient attempted, SMTP reply, enhanced status code, and queue identifier.

Common outcomes include:

250 2.0.0: the receiving SMTP server accepted the message at that stage. This is not necessarily an inbox-placement guarantee.
421 4.7.0: a temporary failure or deferral, often related to policy, reputation, rate limits, or transient system conditions.
450 4.2.0: a temporary mailbox or mail-system condition.
550 5.1.1: a permanent recipient-address failure in many implementations.
550 5.7.1: delivery not authorized or message refused; the enhanced-code standard describes this as a security or policy refusal.
554 5.7.1: a permanent policy rejection in many real-world SMTP implementations.

Text after the code is implementation-specific. Store it exactly, but do not build automated compliance conclusions solely from the human-readable phrase. A 5.7.1 can result from authentication failure, IP reputation, recipient policy, content filtering, blocklists, or other local decisions.

For address-quality problems, validate addresses before sending where appropriate, but do not treat an address-verification result as consent. A mailbox can exist and still be the wrong person, an abandoned account, a spam trap, or someone who opted out. Use a free email address verification tool as a hygiene control alongside consent, suppression, and list-management controls.

Respond to an abuse notice with a defensible workflow

An effective response should be quick, factual, privacy-conscious, and proportionate. It should not promise a legal conclusion before the facts are known.

A practical response sequence

Acknowledge receipt. Confirm the report was received and provide a case reference if possible. Do not request passwords, full payment-card data, or unnecessary personal information.
Confirm the artifact. Ask for the original message as an attachment or full headers if the report lacks them. Preserve the supplied email without altering it.
Contain credible harm. Revoke a suspected credential, pause a risky workflow, block a malicious URL, or suspend the affected sender when evidence supports it.
Correlate internal logs. Match the message to API, SMTP, queue, delivery, authentication, and account records.
Assess the complaint category. Distinguish illegal-content allegations, unsolicited marketing, impersonation, account compromise, moderation appeal, and privacy requests.
Take corrective action. Remove malicious content, secure credentials, add suppressions, correct authentication, or restore access if an automated decision was wrong.
Communicate the outcome. Explain what was reviewed, what action was taken where appropriate, and what further route exists if the reporter disagrees.
Record lessons learned. Update controls, detection rules, templates, or access policies so the same failure is less likely to recur.

When the report concerns illegal content, the DSA's notice-and-action concept is relevant to services that fall within its scope. A notice should be sufficiently precise and adequately substantiated for a provider to locate and assess the content. From a technical perspective, "I got a scam email" is much harder to action than an original .eml, the suspicious URL, the time received, and a concise explanation of why the content is alleged to be illegal.

For a customer or user affected by a content-moderation decision, keep the appeal route separate from standard support. The reviewer should be able to see the original decision, its evidence, subsequent information, and the reason for upholding or reversing the decision. Where practical, avoid having the original decision-maker conduct the only review.

Know when the DSA is not the primary route

The DSA is important, but it is not a universal email-complaint framework. Misrouting complaints delays remedies and creates inconsistent records.

GDPR and privacy matters

Use the relevant privacy process for requests about personal data, marketing objections, access, deletion, or alleged unlawful processing. The recipient may need to contact the organization that determined the purpose and means of processing, which is often the sender rather than the email infrastructure provider.

Consumer disputes

A disputed purchase, refund, recurring subscription, or misleading offer might be a consumer-law issue. Preserve the message as evidence, but direct the complainant to the merchant's support and complaint process, payment provider, consumer authority, or other appropriate channel.

Criminal or urgent safety reports

Threats of imminent harm, extortion, child sexual abuse material, credible fraud, or other potentially criminal conduct may require escalation to law enforcement or specialized reporting channels. Do not promise anonymity, evidence preservation, or disclosure restrictions that your organization cannot legally or technically guarantee.

Deliverability and recipient filtering

A sender that cannot reach a recipient is usually dealing with email operations, not a DSA complaint. Investigate DNS, authentication, reputation, content, recipient-side policy, and bounce codes. The right first stop is often the platform's email API reference and setup guides, not a regulatory escalation.

Prevent future complaints with sender controls

The most effective complaint process is one that receives fewer valid complaints. Build preventative controls into the sending system rather than relying only on manual review after harm occurs.

Separate message types and identities

Use distinct streams or subdomains for transactional, marketing, product notifications, and high-risk workflows. This reduces blast radius and makes it easier to analyze consent, reputation, and abuse patterns.

For example, use a clearly authenticated domain or subdomain for receipts and account notices, while maintaining a separate identity for promotional mail. The exact structure depends on your organization, but the operational goal is stable: do not let a marketing-list problem compromise critical password-reset or security-alert delivery.

Apply least privilege to credentials

Create separate API keys or SMTP credentials for each application and environment. A production billing service should not share a credential with a staging environment, a support tool, and a marketing workflow.

Limit credentials by sender identity, IP range, permission, environment, and expiration where the platform supports those controls. Rotate credentials after suspected exposure. Monitor for unusual spikes in recipient count, new sender domains, unusual geographies, high failure rates, or abrupt shifts in link destinations.

Build unsubscribe and suppression into the application

For mail that is promotional or otherwise requires an opt-out mechanism, make the unsubscribe action reliable, immediate, and durable. The application should check suppression status before rendering and submitting a message, not merely after delivery.

Maintain a suppression record with the address, reason, source, timestamp, scope, and evidence. Consider whether a global suppression, list-level suppression, or category-level preference is appropriate. Never silently remove an unsubscribe because an address later appears in a new import or customer-data sync.

Test like a recipient and a receiver

Use seed addresses at major mailbox providers, inspect headers, and test the actual production path. Tools such as mail-tester.com can help identify common authentication and message-quality issues, while MXToolbox and command-line DNS tools can help inspect public DNS.

Useful commands include:

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short CNAME s1._domainkey.example.com

Also test unsubscribe links, password-reset expiration, localization, reply handling, and landing-page redirects. A message can pass SPF, DKIM, and DMARC yet still be deceptive, inaccessible, or operationally broken.

Document decisions without overcollecting personal data

Complaint handling creates a tension: you need enough evidence to investigate, but collecting every possible data point creates privacy and security exposure. Define a retention schedule and an access model before the incident arrives.

A strong operational record normally includes the complaint, original message, relevant logs, decision rationale, remediation, and communication history. It does not require unrestricted staff access to every recipient's message content or a permanent archive of unrelated mail.

Use role-based access controls. Security responders may need header and credential data; customer-support staff may only need case status; legal teams may need a protected evidence export. Log who accessed sensitive complaint material, especially when it includes message bodies, recipient addresses, account data, or security findings.

If your organization offers email infrastructure through REST APIs and SMTP relay, document the boundary between the platform and the sender. The sender is often best placed to explain why a message was sent, what relationship it had with the recipient, and what the message meant. The infrastructure provider may be best placed to explain submission records, abuse controls, authentication configuration, and actions taken on a sending account.

Escalation paths and regulator-facing readiness

A person who believes a service infringes the DSA may be able to lodge a complaint with the Digital Services Coordinator in the EU Member State where that person is located or established. Digital Services Coordinators are national authorities responsible for DSA coordination and enforcement, while the European Commission has specific supervisory responsibilities for very large online platforms and very large online search engines.

For a business receiving such a complaint, do not improvise a regulator response from a support ticket. Assign an owner who can coordinate legal, security, privacy, abuse, and engineering teams. Preserve the original case record, define what is known and unknown, and avoid altering logs after a preservation request.

A regulator-ready packet should generally include:

The complaint and the date it was received.
The service's role in the email flow.
The relevant message and header evidence.
A timeline of technical events and decisions.
The applicable policy or terms relied upon, if any.
Actions taken to reduce harm or correct an error.
The communications sent to affected parties.
The responsible contact and escalation owner.

Be exact about scope. Do not state that a message was delivered when logs only show SMTP acceptance. Do not state that a domain was compromised unless the evidence supports it. Do not state that a complaint was invalid merely because the reporter used informal language or did not cite a specific DSA article.

Conclusion: treat the complaint as both a trust and security signal

An EU DSA complaint about email is rarely solved by a single template. It may involve content moderation, abuse reporting, consumer protection, privacy rights, authentication failures, compromised credentials, or ordinary deliverability troubleshooting.

The durable approach is consistent: preserve the original evidence, identify the message and sending path, contain credible harm, use SPF, DKIM, and DMARC to establish domain-level facts, document decisions, and route the matter to the correct legal or operational process. That approach helps recipients receive meaningful answers, helps legitimate senders correct real mistakes, and helps email providers keep their REST API and SMTP relay infrastructure safer for everyone.

FAQ

What is an EU DSA complaint?

An EU DSA complaint is a report alleging that an online or intermediary service has not met an obligation under the EU Digital Services Act. In email operations, the underlying issue may involve illegal content, phishing, abuse reporting, a moderation decision, or another matter that needs to be classified before it can be handled correctly.

Does every spam complaint qualify as a DSA complaint?

No. Many spam reports are deliverability, consent, unsubscribe, or consumer-protection matters rather than DSA complaints. They should still be investigated promptly, especially when they show a broken opt-out process, account compromise, impersonation, or a pattern of deceptive mail.

What evidence should I include when reporting a suspicious email?

Include the original email as an .eml attachment if possible, full headers, date and time received, recipient address, suspicious URLs or attachments, and a short explanation of the suspected harm. Avoid forwarding only a screenshot because it often removes the header evidence needed to identify the sending path.

Can SPF, DKIM, and DMARC prove an email is safe?

No. They show whether certain domain-authentication checks passed. A malicious message can be correctly authenticated if an authorized account, application, or credential was compromised. Authentication is essential evidence, but it must be combined with content review, sending logs, consent records, and security investigation.

What should an email sender do after discovering phishing from its domain?

Immediately pause the affected sending route, revoke or rotate suspected credentials, preserve messages and logs, remove malicious links or templates, investigate the entry point, review SPF/DKIM/DMARC alignment, notify affected parties where appropriate, and monitor for follow-on abuse. If criminal activity or immediate harm is involved, use the appropriate emergency or law-enforcement escalation path.

EU DSA Complaint: A Technical Guide for Email Senders