LGPD breach notification — DMARC's role

The LGPD’s Article 48 obliges controllers to communicate “incidents that may cause relevant risk or damage to data subjects” to the ANPD and, where appropriate, to the affected subjects themselves. Phishing campaigns that spoof your domain to extract credentials or PII land squarely in that bucket. The cost of a notification — legal review, communications, regulator relationship — dwarfs the cost of preventing the spoof in the first place.

The spoofing → breach pipeline

A typical incident timeline:

1. Attacker spoofs [email protected] because DMARC is at p=none.
2. Customers receive a credible-looking message asking them to “confirm account details.”
3. Some click. Credentials, IDs, addresses leak.
4. You learn about it from a customer, not from your own monitoring.
5. Legal asks: was personal data involved? Yes. Notify the ANPD.

Each step before #4 is preventable with email-security hygiene. DMARC at p=quarantine or stronger, paired with aligned SPF/DKIM, makes step #2 fail at the receiver’s inbox.

What “monitoring” means under the LGPD

The DPO will ask whether you noticed the spoof attempt before the customer did. RUA reports answer that question with timestamps. “We did not notice” is a control gap; “we noticed within 24h via RUA aggregate” is documented oversight.

Practical posture

• Publish DMARC at p=none with RUA pointed at a parser you actually read.
• Wait 14 days while you classify legitimate sources.
• Move to p=quarantine, then p=reject once aligned mail flows are stable.
• Keep monthly evidence — the PDF, not just the dashboard screenshot.

That posture closes the most common LGPD-notification trigger we see in mid-market companies.