ShieldMarc

Unauthorised senders and DMARC: what the reports show

By Nathan Jeffery8 min read

Unauthorised senders in DMARC reports are the sources in your aggregate reports that send mail as your domain without matching your published SPF or DKIM setup, whether that is a spoofing attempt or a legitimate tool you have not authorised yet. This guide covers how DMARC reports surface them, why the distinction matters, how to check your own domain, what a clean report looks like, and the mistake of treating every unauthorised row as an attack.

Contents
  1. What are unauthorised senders in a DMARC report?
  2. How DMARC reports show you unauthorised senders
  3. Why unauthorised senders are a risk you need to see
  4. How to check your own domain for unauthorised senders
  5. What good looks like once every sender is authorised
  6. Common misunderstandings about unauthorised senders
  7. Where ShieldMarc fits
  8. Start today: check your domain for unauthorised senders
  9. Frequently asked questions

What are unauthorised senders in a DMARC report?

An unauthorised sender is any source your DMARC aggregate report lists as sending mail using your domain in the From address without an aligned SPF or DKIM pass, whether that is a spoofer or a legitimate tool you have not set up yet (RFC 9989). Each row records a sending IP address, a message count, the From domain, the policy applied, and the SPF and DKIM results with the domains they checked, never your intentions.

That row can mean several things. It may be a genuine spoofer forging your domain for phishing or invoice fraud, or a forwarder, or a legitimate tool or old server nobody has added to SPF or DKIM yet.

Google's help pages call the same rows unauthenticated mail from your domain, not unauthorised. Only the label differs (Google: Control unauthenticated mail from your domain).

Domain owners can publish a policy telling Gmail and other participating email providers how to handle messages that are sent from your domain but aren't authenticated. Source: Google: Control unauthenticated mail from your domain

This is not a lookalike domain, which only resembles yours and never appears in your own report; that comes later. For the fundamentals, read our DMARC basics guide.

How DMARC reports show you unauthorised senders

DMARC reports show unauthorised senders as rows, one for each sending IP and set of results in each receiver's report, usually covering one day, with an SPF result, a DKIM result and an alignment outcome. That format is the aggregate report (rua=), defined alongside RFC 9989 as RFC 9990.

Alignment, not a bare SPF or DKIM pass, decides the DMARC result. A source passes only when SPF or DKIM aligns with your From domain: relaxed alignment, the default, accepts the same organisational domain, strict alignment demands an identical one. Our guide to why DMARC fails covers alignment failures and their fixes.

Every row identifies a sending IP address, never a hostname or company name, so matching it to a sender you recognise is the real work, covered in our guide to understanding DMARC reports. Forwarding complicates this: a forwarding server can break SPF, and sometimes DKIM if it changes the message, so a forwarded message can look like an unrecognised sending source with no spoofing involved.

Why unauthorised senders are a risk you need to see

Unauthorised senders are a risk you need to see because, at enforcement, they are exactly what gets blocked, whether attacker or overlooked tool. Enforcement lets receivers act on mail that fails authentication while using your domain in the From address, but it does not touch lookalike domains or display-name tricks.

This is why NCSC's anti-spoofing guidance recommends starting with monitoring only (p=none) rather than moving straight to enforcement. That way, unauthorised senders surface in reports before any mail gets blocked.

The risk cuts both ways. An unnoticed legitimate sender, a helpdesk tool nobody registered, gets silently blocked the moment you move to send fakes to spam (p=quarantine) or refuse fakes (p=reject), which is why every source needs identifying first.

Gmail, Yahoo and Microsoft also expect bulk senders to pass DMARC for inbox delivery; see our bulk sender requirements guide. DMARC.org's FAQ for senders explains why a sending domain should care at all.

How to check your own domain for unauthorised senders

You check your own domain for unauthorised senders by reading what your reports already show, one source at a time. Five steps cover it.

  1. Confirm a DMARC record with rua= exists, using the free DMARC checker: with no rua=, no reports arrive.
  2. Read each aggregate report file, using the free DMARC report viewer, which parses one .xml, .gz or .zip file at a time in your browser.
  3. Check unfamiliar sources against your own SPF record and DKIM selectors before assuming they are hostile. The free SPF checker shows your record and its include tree, and the free DKIM checker shows whether a selector, such as the one a report row names, publishes a key. Both take a domain, not an IP address, so match each row against them by hand.
  4. Separate authentication failures from alignment failures: a source can pass SPF or DKIM outright and still fail DMARC on alignment alone (RFC 9989).
  5. Keep a running list of confirmed senders, so next month only needs checking for new rows.

Pro Tip: Before blocking a failing source, check whether its IP already appears in your own SPF includes or matches a SaaS tool your organisation has signed up to recently, since it may be an unauthorised-but-legitimate sender rather than an attacker.

Check your domain in 4 steps

  1. Confirm you have DMARC

    Run the free DMARC checker to confirm a record with rua= exists.

  2. Read the aggregate report

    Drop the XML into the free report viewer to see each source in plain English.

  3. Identify each source

    Match every failing IP or hostname to a tool, forwarder or attacker before acting.

  4. Check SPF and DKIM

    Use the free SPF and DKIM checkers to see if a sender should already be authorised.

What good looks like once every sender is authorised

Good looks like every legitimate sender in your aggregate reports passing SPF or DKIM with alignment, and every row that still fails explained, such as a forwarder or a spoofer. The policy can then move on: monitoring only (p=none) becomes send fakes to spam (p=quarantine) or refuse fakes (p=reject), with no pct= left in the record, since RFC 9989 removed that tag.

Before moving to refuse fakes (p=reject), make sure every legitimate sender also passes with aligned DKIM: the same RFC says a domain publishing p=reject must not rely on SPF alone, because forwarding usually breaks SPF while DKIM signatures generally survive it.

Name:  _dmarc.example.com
Type:  TXT
Value: v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc-reports@example.com

Subdomains need the same deliberate treatment. Use sp= for subdomains that exist and np= for ones that do not, rather than defaulting to the parent policy.

The bar for moving on is several consecutive sending cycles, such as monthly invoice runs, with no unexplained source, not one quiet week, since reports only arrive from receivers that saw mail that day. Our guide to moving from none to reject covers the full path.

Common misunderstandings about unauthorised senders

Five misunderstandings about unauthorised senders recur. The first is treating every row as an attacker, when it may instead be a marketing, helpdesk or invoicing tool nobody has added to SPF or DKIM yet.

The second is assuming refuse fakes (p=reject) makes every receiver block failing mail outright. Receivers must not reject solely on that policy and, without further analysis, must treat it as quarantine instead (RFC 9989). The same RFC admits that in practice mail forwarded through mailing lists that leave the From address unchanged is still frequently rejected under p=reject, so plan for outright rejection anyway.

The third is reading silence as proof. A source that stops appearing has not necessarily been fixed: reports only come from receivers that send them, on days they saw mail from it.

The fourth is citing an outdated RFC. RFC 7489 (2015) is no longer current: RFC 9989 (May 2026) obsoletes it and removed pct=. A pct= left in an old record is still honoured under the old rules, applying to only that share of failing mail, so it should come out.

The fifth is confusing this with lookalike domains: a similar domain sending its own mail is not an unauthorised sender on yours, and deserves takedown once it is seen being used for phishing, whether by email or on a copycat website. See our guide to lookalike domain protection.

Where ShieldMarc fits

ShieldMarc fits first as free tools that read your domain, then as paid monitoring that keeps reading it for you. The free checker and report viewer need no account; Starter, our free plan with no time limit, keeps one domain's aggregate reports and one SSL monitor running.

Professional, MSP and the trial ingest every aggregate and forensic report automatically through a deterministic threat model. Ask AI, which offers chat and deep reviews on the Email page, runs only when you click, never on its own; the MSP plan covers 100 domain slots for one monthly price, with more added in blocks of 50 through support, rather than per-domain fees.

ShieldMarc runs no live SMTP or STARTTLS handshake test against a sender's mail server, and discovers no senders beyond what DNS and your reports show. For the wider picture, the Security Grade runs up to 16 outside-in checks covering DMARC, SPF, certificates, MTA-STS, TLS-RPT, DNSSEC and CAA, graded A+ to F.

My own view: treat an unrecognised sender as unidentified, not hostile, until checked against SPF and DKIM. That costs nothing and takes minutes on one domain. Starter already processes one domain's aggregate reports automatically for free, so a paid plan only makes sense once you need more domains watched than that.

Start today: check your domain for unauthorised senders

You can check your own domain for unauthorised senders today with tools that need no sign-up. Run the free DMARC checker on your domain now. If aggregate reports are already arriving, drop this week's report files into the free report viewer one at a time to see the sources each receiver saw.

For anything unrecognised, ask whoever manages email, marketing and helpdesk tools before touching the DMARC policy. Once every source is identified, the 30-day trial, no card needed, processes your aggregate reports automatically and gives the domain a Security Grade. Receivers typically send aggregate reports once a day, so the first ones usually arrive a day or two after your record's rua= address is in place.

Frequently asked questions

Can DMARC block unauthorised senders automatically?

DMARC only blocks mail at enforcement: send fakes to spam (p=quarantine) or refuse fakes (p=reject); monitoring only (p=none) just reports. Under RFC 9989, receivers must not reject solely on p=reject and, without further analysis, must treat it as quarantine, though the RFC admits that mail forwarded through mailing lists that leave the From address unchanged is still frequently rejected in practice.

A legitimate sender needs an aligned SPF or DKIM pass before you enforce, or enforcement can block it too, and before p=reject it needs aligned DKIM, since RFC 9989 says a domain publishing p=reject must not rely on SPF alone.

Why does my DMARC report show a sender I don't recognise?

It could be a genuine spoofer, or it could be a forwarding path, or a marketing, helpdesk or invoicing tool sending on the domain's behalf. Check the source against your SPF record and DKIM selectors before assuming it is hostile. If it stays unidentified after asking around, treat it as a candidate for blocking at enforcement.

Does removing an unauthorised sender stop lookalike domain phishing?

No, DMARC only covers mail using your own domain, or one of its subdomains, in the From address. A lookalike is a separate registration needing its own detection, not a DMARC fix on the real domain. Treat takedown as necessary once it is seen being used for phishing, whether by email or on a copycat website.

How long should I monitor before moving from p=none to enforcement?

RFC 9989 says domains whose users might post to mailing lists should not publish refuse fakes (p=reject) at all, and that any that still want to should first spend at least a month at monitoring only (p=none), then an equally long period at send fakes to spam (p=quarantine). In practice, keep monitoring until every source is identified and every legitimate one is aligned, not until reports look quiet for a week. A quiet report is not proof of a clean domain: reports only arrive from receivers that send them, on days they saw mail.

Sources