Naming your own mail servers in DMARC reports

Why your own servers show up as unknown senders

Sender identification works by matching the source IP in each DMARC report against a catalog of published vendor ranges. That catalog can only ever contain senders the whole world shares. Your own servers send real, legitimate mail from IPs nobody but you knows about, so every tool files them under "unknown source" next to the port scanners and the forged mail.

If you send from your own infrastructure, this is permanent background noise: the mail that is most yours is the mail your reports can least explain.

It's an accuracy problem, not a cosmetic one

Whether an IP is "known" feeds real calculations, not just labels:

1. False spoofing alarms about yourself. Suppose a migration breaks DKIM signing on your own server for a week. Its mail now fails authentication from an IP no catalog recognizes, which is exactly what a forged message looks like. A monitoring tool that can't tell your server from an attacker will raise a critical alert about your own machine.
2. Skewed enforcement numbers. On a domain that is already enforcing, failing mail from unknown IPs counts as forged mail that receivers turned away. If some of those IPs are actually yours, that number quietly inflates and your real problem, a misconfigured server of your own, stays hidden inside a statistic that looks like good news.
3. An answer you can't give. The whole point of DMARC monitoring is answering "who sends as my domain?" at a glance. A report full of naked IP addresses doesn't answer it, even when every one of those IPs is a machine you own.

Custom senders: tell the reports who you are

The fix is to make your infrastructure a first-class sender. In trustyourinbox, the Senders page has an Add a sender button: give your servers a name ("Our mail servers", "Datacenter relay"), list their IP addresses or CIDR ranges (up to 16 per sender), and optionally upload a small icon so the row reads like the branded vendors do.

From that moment, mail from those ranges is attributed to your name, and not just going forward: past reports are re-attributed too, so the history rereads correctly. The unknown-source noise disappears, the false alarms about your own servers end, and the enforcement numbers are computed against the truth. You can do this before any mail has even flowed; a sender with no traffic yet simply waits for its first report.

Everything stays editable. Rename a sender, add a range when you stand up a new box, remove a range when you retire one. Removing a range or deleting a sender hands its traffic back to whatever is underneath: a catalog vendor if one covers the IP, or unknown again if nothing does. Nothing is ever silently stuck with a stale label.

The guardrails, and why they exist

Because "known sender" feeds the security math above, custom senders deliberately refuse a few things:

1. No whole-internet ranges. The widest range a sender can hold is a /24 for IPv4 (256 addresses) or a /48 for IPv6. A sender covering half the internet would reclassify genuine spoofing as your own known mail, which is the one lie this feature must never tell you.
2. A warning when you claim a vendor's range. If a range you add sits inside a published vendor range (say, Amazon SES's), the sender is still created, but you're told plainly: mail from there will now show under your name instead of the vendor's. Sometimes that is exactly what you want; it should never happen by accident.
3. No two of your senders on one IP. If a range is already covered by another sender you created, the overlap is refused by name, so attribution never comes down to a coin flip between your own labels.

For MSPs: name the smarthost once

This lands hardest for managed service providers. A smarthost that relays for forty client domains is, to a sender catalog, forty separate mysteries. Named once as a custom sender, it reads correctly on every client domain's dashboard at the same time: one label, one icon, one honest answer to "what is this IP?" across the whole fleet.

What this deliberately is not

Naming a range is a statement about your own workspace, not the world. It never affects how receivers treat your mail, it publishes nothing to DNS, and it doesn't "verify" ownership of the IPs; it only changes how your own reports are read. The one thing it cannot do is make failing mail pass: if your server's mail fails SPF and DKIM, naming the server shows you a well-labeled problem instead of an anonymous one, and the fix is still alignment, not labeling.

Where to start

If you already see aligned mail from IPs you recognize under unknown senders, identify them from that list; the form lets you add a second IP to an existing sender instead of creating "Server 2". If you know your ranges up front, add the sender proactively and let the next report land already named. And if the mystery traffic is coming from subdomains rather than IPs, start with subdomains sending as you instead; that is a different question with its own answer.