DMARC aggregate reports name sending services by ASN owner, not brand — your own ESP can look like a spoofer

Symptom

A DMARC aggregate report (Cloudflare DMARC Management, 7-day window) listed three sending services for the domain:

DEFT.COM matched no vendor anyone had heard of, and it was 48% of total volume across 50 IP addresses. The obvious reading — an unrecognized high-volume sender on a large IP pool — is "spoofer", and the obvious action is to tighten policy to shut it down.

That reading is wrong, and acting on it would have blocked all of the domain's own transactional email.

Cause

DEFT.COM is Postmark. The report labels each source by the ASN / netblock owner, not by the ESP brand. Postmark's sending ranges are hosted at Deft (formerly ServerCentral):

$ dig +short TXT spf.mtasv.net
v=spf1 ip4:50.31.156.96/27 ip4:104.245.209.192/26 ip4:50.31.205.0/24 ip4:147.160.158.0/24 -all

$ whois 50.31.156.96 | grep -iE '^(netname|orgname):'
NetName:        SCN-3
OrgName:        DEFT.COM

So the "unknown" source was the domain's own ESP, resolved through infrastructure ownership. The 100%/100% alignment and the 50-IP pool are exactly what a healthy transactional ESP looks like — the same two facts that made it look suspicious.

Procedure: identify every source before touching policy

For each row in the report, resolve identity from evidence rather than name recognition:

1. Take a sample IP and check it against your own SPF includes. Expand every include: to its ip4:/ip6: ranges and test membership. If the IP is inside a range you publish, it is a sender you authorized — whatever the label says.
2. whois the IP and compare OrgName to the netblock owner of your known ESPs, not to their brand.
3. Use the alignment columns as corroboration. 100% SPF and 100% DKIM alignment is very hard for a spoofer to achieve — it requires your DNS-published SPF and your DKIM private key. A high-volume source at 100%/100% is almost certainly yours. A source at 0%/0% is the actual forgery signal.
4. Only then decide policy. In this case the genuinely forged source was the 6-message row at 0%/0%, i.e. 2.7% of volume — not the 48% that looked alarming.

Generalization

Reports that attribute traffic by infrastructure ownership will not use the names you buy services under, and the mismatch is loudest for the vendors you most depend on (they have the biggest IP pools). "I don't recognize this sender" is a statement about your vendor inventory, not about the sender's legitimacy. Build the inventory — brand to ASN to IP ranges — before you read the report, or you will pattern-match your own critical path as an attacker.