Shared IP vs Domain Reputation: Attribution Experiment
Design a matched experiment to test whether a deliverability symptom follows shared infrastructure, domain identity, or both.
Product & Engineering · September 25, 2026 · 2 min read
Before you start
Test IP-versus-domain attribution by changing one factor at a time and holding the audience, message, cadence, and authentication constant. A shared IP and a sending domain can both influence provider evidence, but a single dashboard snapshot cannot tell you which one caused a symptom. Design the comparison before moving traffic.
Choose the causal question
Write either “Does the symptom follow the IP or provider?” or “Does it follow the domain identity?” A control cell should keep the current domain, IP or provider, message, audience, and cadence. An infrastructure cell changes only the IP or provider where feasible. An identity cell changes only the domain and its correctly configured authentication. If your migration requires both changes, call it a combined change and do not claim isolated attribution.
Use the fair domain-comparison guide for cohort controls. Record shared-pool ownership and any other senders or streams that may make the IP evidence non-exclusive.
Measure multiple outcomes
For each provider cohort, record SMTP acceptance, deferral and bounce response text, authentication and alignment, seed-test placement, complaint events where available, and relevant live-recipient outcomes. Keep timestamps and message identifiers. A provider reputation dashboard is context, not a complete outcome measure, and a seed result is directional rather than universal.
Run the same recurring message pattern through each cell. Keep links, tracking, From display, recipient selection, volume, and schedule stable. If a difference in a cell appears only after a volume or content change, annotate the confounder instead of assigning the effect to IP or domain.
Interpret cautiously
If the symptom follows the IP across the same domain and provider, infrastructure becomes a stronger hypothesis. If it follows the domain across comparable infrastructure, identity becomes a stronger hypothesis. If only one provider changes, keep the conclusion provider-specific. If both cells change, the experiment did not isolate the cause.
Repeat the test after remediation. A clean result during one window does not erase history or guarantee future placement. Retain the experiment record, configuration hashes or version identifiers, provider responses, and decision made from the evidence.
Where RepMail fits
RepMail teams can pair this worksheet with sender reputation records and domain verification evidence. The product context can help document which stream used which sender, but provider signals remain provider-specific. Recheck current Google guidance at publication time and before making a major infrastructure decision.
Related resources
Use the adjacent workflow and then review the next operational guide to keep this decision connected to the wider RepMail resource graph.
Sources
Resources in this guide
| Cell | Domain | IP or provider | What stays fixed |
|---|---|---|---|
| Control | Current | Current | Audience, content, cadence, auth |
| Infrastructure test | Current | Alternative | Domain, message, cohort, window |
| Identity test | Alternative | Current | IP, message, cohort, window |
| Combined change | Alternative | Alternative | Label as non-isolated evidence |
Common mistakes to avoid
- Changing the IP and domain together, then calling the result an IP or domain effect.
- Assuming a shared-IP signal belongs to one sender without checking the pool and provider evidence.
- Using a provider reputation chart as the only outcome measure.
Frequently asked questions
Can a shared IP affect a clean domain?
Shared infrastructure can create attribution and reputation exposure from other senders, but the effect is provider-specific and must be established with evidence. Do not assume either innocence or causality from the shared label alone.
How do I isolate IP from domain?
Keep the domain and message constant while comparing infrastructure, or keep the infrastructure and message constant while comparing domains. If both must change, label the result as a combined change rather than an isolated effect.
What is a useful experiment outcome?
A provider-specific difference in acceptance, deferral, bounce, or placement within a documented matched window is useful. It supports a next test; it does not prove how every provider will behave.
Continue learning
Apply matched domain controls
Use the domain-comparison worksheet to control audience and message variables.