yodai Academy Domain and email

Academy › Publishing › Domain and email

The report nobody checks until it's too late

You know how to read your domain's DMARC reports and tell within a minute whether the problem is on your end or someone's impersonating you.

By Yodai · Published September 6, 2026 · Updated October 12, 2026

4 min read

With DMARC set to monitor mode, your domain starts receiving reports. Some random Monday, an email shows up with a subject line that doesn't make sense: "Report Domain: yourdomain.com," followed by the sender's name and a report number. Inside is an attachment, usually a compressed file; if you open it with one of the tools that translate these reports, you'll see a table with IP addresses, countries, and two columns, "pass" and "fail," full of numbers that don't mean much on their own. Most business owners close it without a second look, and that's exactly the moment someone could be sending emails pretending to be you without your knowing for weeks.

That report is the only thing that warns you about two very different things: that you left something misconfigured, or that someone else is using your domain to scam your customers. Reading it wrong, or not reading it at all, means you won't tell your own mistake apart from an attack until someone calls to ask why you sent them a fake invoice.

Where that report comes from and what's in it

If your domain already has SPF, DKIM, and a DMARC rule set up carefully, without turning on blocking the first day, that DMARC rule is what requests the report. Every provider that receives your mail and sends these reports, like Google, usually sends you one a day: a summary of every email it has seen arrive with your domain as the sender, whether it passed the check or not.

The report includes a list of source IPs, how many emails each one sent, and whether those emails passed SPF and DKIM or failed. It's not something to read word for word: it's a table to scan in a minute, looking for one thing, who's sending on your behalf.

How to scan it in a minute
  1. 1Look at who's sending, not how many
    Before you check whether it passes or fails, look at the IP or the name of the source service. If it's your email provider, your website, or the tool you use to send invoices, you already know where it's coming from.
  2. 2Check it against your list of approved services
    You need to know, off the top of your head or written down somewhere, which services send email on your behalf: your inbox, your website, your billing software, your newsletter tool. Any IP address not on that list is suspicious by default.
  3. 3If the IP is yours and it fails, that's a configuration issue
    A service you recognize showing SPF or DKIM as a fail isn't an attack, it just means that service isn't properly added to your SPF record or isn't signing with your DKIM. You fix it by adding it, not by blocking it.
  4. 4If the IP isn't yours and it's failing, someone's impersonating you
    A batch of emails from an unknown IP, failing both SPF and DKIM, means someone is sending mail in your name. There's nothing to fix on your end there: it's the sign that you should tighten your DMARC rule, moving first to quarantine and then to reject, as soon as all your own services pass cleanly.
Your mistake or an impersonation: they don't read the same way
It's your mistake
  • The IP is a service you recognize: your website, your invoicing, your inbox
  • The volume is low and steady, similar every week
  • The same mechanism always fails, for example only DKIM and never SPF
Someone impersonating your domain
  • The IP doesn't match any service you've set up
  • The volume shows up all at once, a spike that wasn't there before
  • SPF and DKIM both fail at the same time, and the country of origin usually isn't yours

Which one applies to you: If you recognize the source, fix your setup that same week, no rush. If you don't recognize it, don't wait: that's proof you need to tighten the rule, first to quarantine and then to reject, as soon as your own mail passes clean.

The costly mistake: blocking your own service because you didn't recognize it
The most expensive mistake isn't reading the report late, it's reading it in a panic and blocking one of your own services thinking it's an attack. This happens most often with billing software or a newsletter tool, when you forgot to add it to your list of approved services. Before you touch your DMARC rule, check it against your own list first: a misconfigured email of your own is explained in a minute, an email that isn't yours has no explanation.

With this, you're no longer relying on luck: every week, you know whether the report is about you or about someone else.

You now know how to read the report and tell your own mistake apart from someone impersonating you. What that report won't tell you is that some emails, like confirmations and invoices, should never go out from your regular inbox: that's what's next.

What you'll walk away with
  • You know which report to check and how often it arrives
  • You have the judgment to tell a misconfigured service of yours apart from someone impersonating your domain
  • You know what to do in each case: fix the record or switch the rule to reject mode
NextThe invoice that shouldn't come from your everyday inbox