Who Sends Mail as Your Domain — and Why It's the Key to Email Security

Who Sends Mail as Your Domain?

Most people, asked who sends mail as their domain, name one service: their primary mailbox provider — Google Workspace or Microsoft 365. That answer is almost always incomplete.

Walk through a typical company and the real list grows fast. Your primary mail flows through Google Workspace or Microsoft 365. Marketing sends campaigns and newsletters through a platform like Mailchimp. Your application sends password resets, receipts, and notifications through a transactional service like Amazon SES or Postmark. Your CRM sends sequences on behalf of the sales team. Your helpdesk sends ticket replies. Your billing system sends invoices and payment reminders. Each of these is a separate service, often run by a separate team, and every one of them puts your domain in the From: address of the mail it sends.

That full set — every service authorized to send mail as your domain — is your Senders. It is the single most important fact about your email authentication, because everything else is built on it. SPF, DKIM, and DMARC are not abstract DNS chores. They are three ways of answering one question: is this message really from one of your senders, or from someone impersonating you? You cannot answer that question correctly until you know who your senders are.

A sender inventory is just that list, written down and kept current: every service that legitimately sends as your domain, the way each one authenticates, and whether it is accounted for. Get the inventory right and the protocols fall into place. Get it wrong — or never build it — and you are configuring authentication blind.

Why Your Senders Are the Foundation of SPF, DKIM, and DMARC

The three protocols each look at your senders from a different angle.

SPF authorizes sending servers by IP address. Your SPF record is a published list of the servers and services allowed to send as your domain. When a receiving inbox gets a message, it checks whether the sending server is on your list.

DKIM signs mail cryptographically, per sender. Each service that sends as you publishes a public key and signs its outbound mail with the matching private key. The receiver verifies the signature to confirm the message genuinely came from that service and wasn't altered in transit.

DMARC ties the two together and adds the decisive test: alignment. DMARC checks not just that a message passed SPF or DKIM, but that the sender it passed for lines up with the domain in the visible From: address. Alignment is what makes spoofing hard — an attacker can pass SPF for their own server, but they can't make that pass align with your domain.

The rule that matters for your inventory is simple: each of your senders needs to pass SPF or DKIM — only one of the two has to pass — and that pass needs to align with your domain. A sender that passes neither, or passes but doesn't align, is treated by DMARC as unauthenticated. Once your DMARC policy moves to enforcement, that mail is the mail receivers act on.

This is why the inventory comes first. SPF, DKIM, and DMARC are configuration of your sender list. Every entry in the list needs one working authentication path; every authentication path needs to align. The protocols are the mechanism — your senders are the thing being protected.

For the full mechanics of how each protocol works and how they chain together, see the Complete Guide to Email Authentication.

The Senders You Don't Know About

You can authorize a sender only if you know it exists. The senders that cause trouble are the ones nobody told you about.

The canonical case: a marketing lead, under deadline, signs up for a new newsletter tool and starts sending campaigns from your domain. IT never hears about it. The new tool isn't in your SPF record and isn't set up to DKIM-sign for your domain, so its mail fails authentication. While your DMARC policy is still in monitoring mode, those campaigns land in spam or get a deliverability penalty — bad, but survivable. The day you move to enforcement, the story changes: receivers now act on the failure, and those campaigns are quarantined or refused outright. Marketing's mail stops arriving, and the first anyone hears of it is an angry message asking why the newsletter "broke."

Nothing broke. The sender was simply never on the list. This is the structural risk of an incomplete inventory: an unknown legitimate sender looks identical to an impersonator until you account for it, and enforcement treats them the same.

The way you find these senders is DMARC aggregate reports. When DMARC is enabled, receiving mail servers send you regular reports of every source that sent mail claiming to be your domain — authorized or not, passing or failing. That report stream is the only complete, observed view of who is actually sending as you. It surfaces the forgotten marketing tool, the legacy server still relaying mail, the SaaS app a department signed up for two years ago — and, separately, the genuine impersonators. Reading those reports is how a guessed inventory becomes a verified one.

For how to read the reports and what each field tells you, see Understanding DMARC Reports.

Building Your Senders Inventory

Turning "who sends as us" into a working list is a short, concrete process.

1. List what you already know. Start from the obvious: primary mail (Google Workspace / Microsoft 365), marketing, transactional, CRM, helpdesk, billing. Walk the teams, not just the DNS record — the people who set up these tools know about senders that never made it into SPF.

2. Turn on DMARC reporting to surface what you don't. Enable DMARC at p=none (monitoring) so no mail is affected, point the reports at an address you watch, and let a few weeks of data accumulate. The reports will show you every source sending as your domain, including the ones your list missed.

3. Classify each source. Sort every source the reports show into three buckets:

• Authorized — a legitimate sender, already passing SPF or DKIM and aligning. Nothing to do.
• To authorize — a legitimate sender that's failing. Add it to your SPF record, set up DKIM signing for it, or both, until it passes and aligns.
• Unknown / unauthorized — a source you don't recognize and didn't set up. This is the impersonation bucket. It stays off your list, and enforcement is what stops it.

The output is a list where every legitimate sender is accounted for and authenticating, and everything else is known to be unauthorized.

That list is the prerequisite for safe enforcement. You cannot safely move your DMARC policy to p=reject until every legitimate sender is in the "authorized" bucket, because at reject any authorized-but-unaccounted-for sender's mail gets refused by the receiver. The inventory is what lets you advance with confidence instead of crossing your fingers. For the staged path from monitoring to enforcement, see the DMARC enforcement journey.

How mxio Uses Your Senders List

mxio is built around the Senders list. It works in one of two modes, and the difference is who does the work — not who is in control.

Self-managed. mxio shows you your senders by name — the marketing tool, the transactional service, the CRM — and tells you, per sender, whether each one is passing SPF or DKIM and aligning. Where a sender isn't accounted for, it flags the gap and tells you exactly what to publish to close it: the SPF entry to add, the DKIM record to set up. You make the DNS changes yourself. mxio is the advisor; you remain the operator.

Managed. You delegate the work of maintaining the records. You make one last DNS change to point the relevant record at mxio, and from then on mxio builds and maintains your SPF and DMARC records from your Senders list for you. It tracks vendor IP changes so your SPF record stays correct as providers rotate their ranges, keeps your record under the lookup limit automatically, and surfaces new senders it sees in your reports so the list stays current.

It's worth being precise about what "managed" means here, because the word can be read two ways. Managed mode means you delegate the responsibility for keeping the records correct. You still own your DNS and your records — your zone, your nameservers, your domain. You can see everything mxio publishes on your behalf, at any time. And it is reversible: if you want to take the work back, mxio hands you a working record to publish and you're self-managing again. The honest way to put it: you delegate the upkeep, not the ownership. The decision is "do I want to keep doing this maintenance myself, or hand it off?" — and you can change that answer whenever you want.

For the full picture of how delegated management works and what stays in your hands, see Managed Email Authentication.

Start by Seeing Your Senders

You can't authorize, authenticate, or enforce a sender you can't see. Everything in this guide starts with one step: getting the list in front of you.

Run the Domain Health Check for a full read of your domain's SPF, DKIM, and DMARC status, or the DMARC Checker to see your current policy and reporting setup. Both are the front door to seeing who sends mail as your domain — and once you can see your senders, every decision that follows gets simpler.