Sender Identification and ISP Attribution: How ISPs Know Who You Are

• November 2021
• Engineering Memo · External Release

When an ISP receives an email message, it must decide which entity is responsible for the content and signals that message carries. This attribution decision — mapping an incoming message to a sender identity — is the foundational step in all ISP reputation systems. The reputation model only works if each message can be attributed to the same sender identity that previous messages from that organisation were attributed to. Understanding how ISPs build this attribution is essential for understanding why specific authentication configurations matter and why misconfigurations produce reputation problems that are difficult to diagnose without understanding the attribution mechanism.

This note documents the specific identification signals that ISPs use to attribute sender identity, how they combine multiple signals to establish confident attribution, and the authentication configurations that ensure your intended sender identity is what ISPs use for attribution rather than a default identity that fragments your reputation signals.

The Sender Identification Signal Stack

ISPs evaluate multiple signals to attribute sender identity, and different ISPs weight these signals differently. Understanding the full stack of signals and how they interact explains many attribution-related deliverability problems.

DKIM signing domain (d= value): The most reliable and intentional sender identification signal. The DKIM-Signature header's d= tag specifies the domain whose private key was used to sign the message. This domain is cryptographically verified by the receiver — a valid DKIM signature means the message was genuinely signed by the private key corresponding to the published public key for that domain. Gmail attributes domain reputation to the DKIM d= domain, making this the primary attribution signal for Gmail deliverability purposes. If DKIM is not configured, or if the d= domain does not match the From: header domain (alignment failure), the domain reputation signal is fragmented or absent.

From: header domain: The domain portion of the From: header email address is what recipients see and recognise as the sender. DMARC alignment requires that the From: header domain match the DKIM signing domain (or be a parent domain of it) to establish that the authenticated sender is the same as the visible sender. Without this alignment, a message could be DKIM-authenticated as example-esp.com while appearing to come from brand.com — which is exactly the phishing pattern that DMARC is designed to prevent, and why DMARC alignment verification is required for DMARC to provide meaningful protection.

IP address: The sending IP is visible in the SMTP session and recorded by the receiving server in the Received: header chain. IP reputation — the signal history associated with a specific IP address — is used as a secondary sender identification signal, supplementing or providing fallback for domain reputation in ISP classification systems. For new senders without established domain reputation, IP reputation provides the primary attribution signal; for established senders with strong domain reputation, IP reputation is a supporting signal that can help or hinder based on the IP's own history.

PTR record (reverse DNS): The PTR record for the sending IP translates the IP address to a hostname. ISPs check that this hostname matches what the sending MTA presents in the EHLO command (FCrDNS — Forward Confirmed Reverse DNS). A sending IP without a PTR record, or whose PTR hostname does not resolve back to the same IP (FCrDNS failure), is a weak sender identification signal that some ISPs treat as a signal of unverified or potentially malicious sending infrastructure. PTR records are a baseline authentication requirement rather than a reputation-building signal — they establish that the sending infrastructure is professionally configured, which is a prerequisite for building positive reputation signals.

Envelope sender (MAIL FROM address): The address specified in the SMTP MAIL FROM command (also called the "return path" or "bounce address") determines where bounces are sent and is used by SPF for authentication. The SPF mechanism checks whether the sending IP is authorised by the domain in the MAIL FROM address. For DMARC alignment purposes, SPF alignment checks whether the MAIL FROM domain matches the From: header domain. The envelope sender is often a different domain from the From: header domain when using third-party ESPs — which creates SPF alignment failures that only DKIM alignment can compensate for in the DMARC evaluation.

Why Fragmented Attribution Damages Reputation

Attribution fragmentation occurs when the signals that ISPs use to identify the sender are not consistently pointing to the same identity. The most common fragmentation scenario: a sender uses multiple ESPs or sending services, each signing with their own DKIM domain. From Gmail's perspective, messages attributed to esp1.com's DKIM domain and messages attributed to brand.com's DKIM domain are from different senders — even if both appear to come from @brand.com in the From: header. The domain reputation that campaign 1 builds on esp1.com does not accumulate on brand.com, and vice versa.

The practical consequence of attribution fragmentation: each sending identity builds reputation independently, without benefiting from the combined signal history of all the messages sent under the brand. A programme that sends 500,000 messages per month split between two ESPs is effectively running two separate reputation-building campaigns — each at 250,000 messages per month — rather than a single 500,000-message programme. Both sending identities build reputation more slowly and reach high-reputation tiers later than a unified identity would on the same combined volume.

The remediation for attribution fragmentation: configure all sending sources to use the same DKIM signing domain aligned with the From: header domain. Whether the message is sent via ESP A, ESP B, or the organisation's own MTA infrastructure, the DKIM signing domain should be brand.com (or a brand.com subdomain for traffic-type separation), ensuring that all messages are attributed to the same sender identity regardless of which infrastructure sent them. This requires the DKIM private key to be configured on each sending service — either by generating a signing key and providing it to each ESP, or by using a DKIM proxy that signs outgoing messages regardless of which service injected them.

DMARC as the Attribution Enforcement Mechanism

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the protocol that enforces the alignment between authenticated sender identity and visible From: header sender identity. A DMARC record for brand.com specifies that all messages appearing to come from @brand.com must pass either DKIM alignment (the DKIM d= domain matches brand.com or a brand.com subdomain) or SPF alignment (the MAIL FROM domain matches brand.com or a brand.com subdomain). Messages that fail both alignment checks are subject to the DMARC policy action: p=none (monitor but take no action), p=quarantine (route to spam folder), or p=reject (reject the message entirely).

At p=reject, DMARC prevents any message appearing to come from @brand.com from being delivered if it cannot pass at least one alignment check. This is the strongest sender identity protection available — it prevents email spoofing of the brand's domain — but it requires that all legitimate sending sources for the brand.com domain are correctly configured for either DKIM or SPF alignment. Any legitimate sending source that is not aligned will have its messages rejected when p=reject is enforced.

The path to p=reject enforcement: start with p=none and configure DMARC aggregate report collection (the rua= tag in the DMARC record). The aggregate reports show all sending sources that are sending messages with brand.com in the From: header, along with their authentication and alignment status. Review these reports to identify any sending sources that are failing alignment — these are either legitimate sources that need authentication configuration, or illegitimate sources attempting to spoof the brand. Fix the legitimate sources, monitor that alignment passes, and only then upgrade to p=quarantine and eventually p=reject.

Attribution Across Multiple Sending Services

Programmes that use multiple sending services — a transactional ESP, a marketing automation platform, and a dedicated outbound infrastructure — need to configure consistent sender identification across all three. The correct approach: each service signs with the same root domain (brand.com) using a different selector, ensuring that all messages from all services are attributed to brand.com's domain reputation rather than each service's own domain.

The selector naming convention for multi-service environments: use descriptive selector names that identify both the service and the key generation date. For example: tx-2022-01 for the transactional service key generated in January 2022, mktg-2022-03 for the marketing platform key. This naming convention makes the DMARC aggregate reports immediately readable — the source column shows which service generated the message, and the alignment column shows whether each service is correctly configured.

When adding a new sending service to the infrastructure, the attribution configuration — DKIM signing domain alignment with the From: header domain — must be completed before the service sends any production messages. A new service that sends before its DKIM signing is configured contributes messages to DMARC's unauthenticated signal rather than to brand.com's authenticated reputation, and those messages may be rejected or quarantined when DMARC policy is at p=quarantine or p=reject. The pre-production checklist for any new sending service must include DKIM alignment verification via mail-tester.com before the first production message is sent.

Sender identification and ISP attribution is the foundation of all reputation-based email deliverability. ISPs cannot reward consistent positive signal history if they cannot consistently attribute signals from the same sender to the same identity. The authentication configuration that ensures consistent attribution — correctly aligned DKIM, DMARC policy enforcing alignment, PTR/FCrDNS for all sending IPs — is not advanced email configuration. It is the baseline that makes all reputation management meaningful. Without it, the deliverability investments in IP warming, list quality, and monitoring are building reputation on a fragmented foundation that the ISPs cannot consistently recognise and reward.

Reading DMARC Aggregate Reports for Attribution Analysis

DMARC aggregate reports (rua= reports) are XML files sent daily by ISPs to the email address specified in the DMARC record's rua= tag. Each report covers a 24-hour period and shows every message that the reporting ISP received that claimed to come from the monitored domain, along with the authentication and alignment results for each sending source.

The aggregate report structure includes: the source IP address (or CIDR range) of the sending server, the count of messages from that source, the DKIM authentication result (pass/fail), the DKIM alignment result (pass/fail), the SPF authentication result (pass/fail), the SPF alignment result (pass/fail), and the disposition applied (none/quarantine/reject). This data reveals exactly which sending sources are passing or failing attribution requirements.

Commercial DMARC report processing tools (Dmarcian, Valimail, Postmark's DMARC Digests, and others) parse these XML reports and present them in readable dashboards that identify the highest-volume sending sources, their alignment status, and any sources that appear unexpectedly (potential spoofing attempts or unconfigured legitimate sending services). For programmes with multiple sending services, the aggregate report dashboard is the definitive reference for whether each service's attribution is correctly configured.

The aggregate report review should be part of the monthly authentication maintenance review: are all legitimate sending sources consistently passing DKIM alignment? Are there any new sending sources that appeared this month that are not correctly configured? Are there any unexpected sources attempting to use the brand's From: domain without authorisation? Each of these questions is answerable from the DMARC aggregate report data, and acting on the answers maintains the authentication integrity that clean sender identification depends on.

Attribution in B2B Sending: Corporate Mail Server Considerations

B2B senders face specific attribution challenges because corporate email recipients use Microsoft 365 or Google Workspace environments that apply their own spam filtering layers on top of the ISP-level filtering that consumer email uses. Corporate mail servers may attribute sender identity differently than consumer ISP reputation systems — in particular, corporate Exchange Online Protection (EOP) applies policy-based filtering that can be stricter than consumer Outlook's filtering for the same sender.

For B2B senders, PTR and FCrDNS configuration is particularly important: corporate mail administrators who review sender credentials for allowlisting decisions check PTR records and EHLO hostname consistency as indicators of professional sending infrastructure. A sending IP whose PTR hostname is a generic datacenter hostname (server123.datacenter.com) rather than a descriptive mail server hostname (mail.brand.com) is less likely to be reviewed favorably by corporate mail administrators making manual allowlisting decisions than an IP with a clearly branded hostname.

The branding of the EHLO hostname and PTR record — using mail.brand.com or smtp-out.brand.com rather than generic datacenter identifiers — is a low-cost signal of professional sending infrastructure that matters more in B2B attribution contexts than in consumer ISP contexts. Configure PowerMTA's smtp-source-host directive with a descriptive, branded hostname for each VMTA, and ensure the corresponding PTR record and FCrDNS are correctly configured to match.

The Attribution Audit: Verifying Your Sender Identity Stack

An attribution audit verifies that all components of the sender identification stack are correctly configured and consistently applied. The audit steps:

Step 1 — DKIM verification: Send a test message from each major sending source to a Gmail address. View the raw message source and check the Authentication-Results header. Confirm that DKIM shows dkim=pass (key found) and that the signing domain (d=) matches the From: header domain for DMARC alignment.

Step 2 — SPF verification: Check the SPF record at mxtoolbox.com for each sending domain. Confirm that all sending IPs are included in the SPF record or in an include: reference. Verify that the SPF lookup count is under 10 mechanisms.

Step 3 — DMARC alignment verification: Review the DMARC aggregate report from Gmail for the past 7 days. Confirm that all legitimate sending sources show dkim_aligned=pass and that there are no unexpected sources appearing in the report.

Step 4 — PTR/FCrDNS verification: For each sending IP, run dig -x [IP] to confirm the PTR record exists and points to the expected hostname. Run dig A [hostname] to confirm the hostname resolves back to the same IP (FCrDNS). If using a managed hosting provider, verify that PTR records are correctly configured for each IP — many providers do not automatically configure PTR records and require explicit requests.

The attribution audit is a one-time investment of 2-3 hours that provides an end-to-end verification of the sender identification stack. Running it annually — or after any significant infrastructure change such as adding a new sending service, migrating to new IPs, or changing the From: address domain — ensures that attribution integrity is maintained as the infrastructure evolves. Attribution problems that are caught in an audit are fixed before they affect reputation; attribution problems discovered through DMARC aggregate report anomalies are fixed after they may have contributed to reputation fragmentation or spoofing events. Proactive auditing is always preferable.

When Attribution Goes Wrong: Diagnosing Misattribution

Attribution problems manifest as deliverability anomalies that are difficult to explain through standard reputation metrics. The diagnostic signs of misattribution: Postmaster Tools domain reputation showing lower tier than expected given the programme's send volume and historical quality; DMARC aggregate reports showing authentication failures from IP ranges that should be passing; inbox placement rates for a subdomain sending type that differ dramatically from other subdomains on the same root domain; or FBL complaint data attributed to a different domain than expected.

Each of these symptoms points to the same underlying cause: the sender identification stack is not consistently attributing all messages to the intended sender identity. The investigation protocol: start with the DMARC aggregate report to identify which sending sources have alignment failures, then trace those sources back to the specific sending service or MTA configuration that is producing the misalignment. The most common root causes — DKIM signing domain mismatch, SPF record missing a sending IP, PTR misconfiguration on a new IP — are all fixable within a day once identified from the aggregate report data.

Misattribution is almost always a configuration problem rather than a deliberate choice or a fundamental infrastructure limitation. The remediation is configuration correction rather than infrastructure replacement. Understanding the attribution stack clearly enough to diagnose misattribution quickly is the operational knowledge that converts a confusing deliverability mystery into a solvable configuration problem -- and solvable problems are the only kind worth having.

Sender identification and ISP attribution is the invisible infrastructure that makes everything visible in email deliverability monitoring meaningful. Without correct attribution, monitoring data is noisy, reputation building is fragmented, and DMARC protection is incomplete. Getting it right -- the full stack of DKIM alignment, SPF coverage, DMARC enforcement, PTR configuration, and EHLO hostname branding -- is the configuration investment that makes all other deliverability investments produce their intended returns. Audit it, maintain it, and use the DMARC aggregate reports to verify that it continues to work correctly as the infrastructure evolves.

Attribution clarity is reputation clarity. When ISPs can consistently attribute every message from a programme to the same sender identity -- because DKIM alignment, SPF, DMARC, PTR, and EHLO are all correctly configured and maintained -- the reputation model works as intended. Every positive signal builds on every previous positive signal. Every negative signal is correctly attributed and addressed at the source. The sender identity that the programme has invested in building is the identity that receives the reputation benefit of that investment. That alignment between intention and attribution is what authentication configuration provides -- and it is worth getting right.

The sender identification stack is not a compliance checklist -- it is the technical infrastructure that makes reputation-based email deliverability function correctly. Invest in it, maintain it, and audit it annually. The operational discipline required is modest; the deliverability foundation it provides is essential. Every programme that manages email deliverability seriously already has this configuration in place; those that do not are building on foundations that ISP attribution systems cannot consistently recognise and reward.

Configure correctly. Verify annually. The rest follows.