KoltrixBefore Any Email Migration: Inventory Everything That Sends as You
Most email migrations break something nobody listed: a CRM, a form, a scanner. How to find every service that sends as your domain before you change DNS.
On this page(6 sections)
When an email migration goes wrong, the mailboxes are rarely the problem. What breaks is the invoicing tool nobody remembered, the contact form that relayed through the old provider, or the office scanner configured by someone who left two years ago.
Every one of those is a system sending mail as your domain. Find them all before you touch DNS, and the migration becomes predictable.
Why this matters
When you change mail providers, three things can break for a third-party sender:
- Authentication. If you rewrite SPF and drop an include, or the sender relied on the old provider's DKIM signing, its mail may start failing SPF, DKIM and DMARC checks and land in spam or be rejected.
- Relaying. Some tools don't send directly; they log in to your mailbox provider's SMTP server with a username and password. When that mailbox disappears, sending stops.
- Replies. If a tool sends with a Reply-To pointing at an address you're retiring or recreating, replies may bounce or go somewhere unexpected.
An inventory lets you check all three for every sender.
Where to look
No single source lists everything. Use several and combine the results.
1. Your SPF record
Look up the TXT record on your root domain that starts with v=spf1. Each include: usually corresponds to a service authorized to send for you:
v=spf1 include:_spf.google.com include:sendgrid.net include:mail.zendesk.com ip4:203.0.113.25 ~all
That example says Google Workspace, SendGrid and Zendesk send as the domain, plus one server at a specific IP address. Bare IP addresses deserve extra attention: they're often an old server or office connection whose purpose has been forgotten.
SPF also tells you about things that were set up and abandoned. An include for a tool you stopped paying for years ago is worth removing, which also helps with SPF's limit of ten DNS lookups.
2. DMARC aggregate reports
If your domain publishes DMARC with a rua= address, receiving providers send daily reports listing every IP address that sent mail claiming to be from your domain, with pass and fail counts. This is the most complete picture you can get, because it shows what actually sends, not what's configured.
If you don't have DMARC yet, publish a p=none record with reporting a few weeks before your migration. It changes nothing about delivery and gives you data. Our DMARC checker shows what you currently publish.
3. DKIM records
Look for TXT or CNAME records ending in ._domainkey. Each selector usually belongs to a service signing mail for you. You can't list all DNS records from outside, so check your DNS provider's dashboard directly.
4. Your tools' settings
Go through the admin settings of everything your company uses and look for "email," "sender," "from address" or "SMTP":
- Billing and invoicing
- CRM and sales tools
- Help desk and live chat
- Marketing and newsletter platforms
- Website forms, e-commerce and booking systems
- HR, payroll and recruiting tools
- Monitoring and alerting
- Your own application's transactional email
5. Devices and scripts
The forgotten category: printers and scanners that email scans, cron jobs that send reports, NAS devices that send alerts, and old servers. These often authenticate with a mailbox username and password on the old provider.
6. Ask people
A short message to the team: "What tools send email as our domain on your behalf?" Someone always remembers one more.
Build the inventory
One row per sender:
| Sender | Purpose | From address | How it sends | Auth today | Owner | Migration action |
|---|---|---|---|---|---|---|
| Invoicing tool | Invoices to customers | billing@ |
Its own servers | SPF include + DKIM | Finance | None; keep include |
| Website form | Contact form notices | hello@ |
SMTP login to old provider | Via old provider | Marketing | Repoint to new SMTP relay |
| Office scanner | Scan to email | scanner@ |
SMTP login to old provider | Via old provider | Office manager | Repoint or retire |
| Old server 203.0.113.25 | Unknown | Various | Direct | SPF ip4 | Unknown | Investigate, then remove |
| Product app | Password resets, receipts | noreply@ |
Transactional API | SPF include + DKIM | Engineering | Review Reply-To |
The "How it sends" column is the important one. Anything that logs in to the old provider's SMTP server will break at cut-over unless you reconfigure it. Anything sending from its own servers with its own DKIM will keep working, as long as you don't remove its SPF include or DKIM record by accident.
Decide what moves and what stays
For each row, pick one:
- Keep as is. Third-party senders with their own authentication. Carry their SPF include and DKIM record forward unchanged.
- Repoint. Anything that relayed through the old provider. Switch it to the new provider's SMTP relay or API and test.
- Consolidate. If you're moving app email too, this is a chance to send it from the same provider as your mailboxes.
- Retire. Unknown or unused senders. Remove their DNS entries once you're sure nothing depends on them.
If a third-party tool sends from your root domain and you're worried about SPF lookups, consider moving it to a subdomain such as mail.yourdomain.example with its own records.
Test after cut-over
After switching MX and SPF, trigger a message from every row in your inventory and check the headers for SPF, DKIM and DMARC results. Keep watching DMARC aggregate reports for a couple of weeks; any new failing source is something you missed.
The full cut-over sequence is in our Google Workspace DNS checklist, and the same order applies to other providers.
Key takeaways
- Migrations usually break third-party senders, not mailboxes.
- Combine SPF, DMARC reports, DKIM records, tool settings, devices and the team's memory to find every sender.
- Record how each one sends; SMTP logins to the old provider are the ones that break.
- Decide for each sender whether to keep, repoint, consolidate or retire it, and test every one after cut-over.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
