Comcast / Xfinity Sender Requirements

Comcast runs the consumer mail service behind comcast.net (the email side of Xfinity) and publishes sender guidance at postmaster.comcast.net. That guidance is unusually concrete for a US ISP - it documents connection limits, a SenderScore-keyed rate-limit table, and a full index of BL/RL/ES block codes. But two facts frame everything below: the postmaster site is legacy (its news entries date to 2010-2012), and Comcast is in the middle of moving comcast.net mailboxes to Yahoo Mail. For most senders in 2026, the practical answer to “how do I reach comcast.net?” is converging on “follow Yahoo’s requirements.”

Scope: this page covers mail sent to comcast.net consumer recipients. It does not cover Comcast Business mailboxes (excluded from the Yahoo migration) and it is not about sending from a Comcast residential line (Comcast does not accept third-party mail from its own dynamic/residential space - see below).

The 60-second version

• Comcast is migrating comcast.net email to Yahoo Mail, phased through 2025-2026, with completion targeted around fall 2026. New comcast.net account creation was halted in June 2024. As accounts move, Yahoo’s filtering and sender requirements govern that mail - see the Yahoo page.
• Reverse DNS is mandatory. A sending IP without a valid PTR (plus matching A/MX) is refused. Dynamic/residential IP space is not accepted at all.
• RFC 5321/5322 compliance is required (“all email must comply with all relevant RFCs”).
• Rate limits are reputation-driven, keyed to SenderScore (now operated by Validity) and authentication - documented in a per-hour table (below).
• Block codes are documented: BL000000 is a spam-pattern block removable via Comcast’s form; the BL00xxxx family maps to third-party blocklists (Spamhaus, Cloudmark CSI, SenderScore, TrendMicro); RL000001 is rate limiting; ES00000x is dynamic-IP rejection.
• Feedback loop exists at feedback.comcast.net (ARF reports, both IP-based and DKIM-based).
• DMARC is honored, but Comcast’s published note says it treats a p=reject request the same as quarantine (marks both as spam) rather than refusing outright.

The Yahoo migration is the real headline

This is the single most important thing to know, and it is verified from official Xfinity and Yahoo pages:

“Starting in June 2025, customers with a comcast.net email will be invited to upgrade their email account to Yahoo Mail… Invitations will roll out gradually through 2026.” (Xfinity Support)

“Xfinity will move Comcast.net email accounts to Yahoo Mail at different times in 2025 and 2026.” (Yahoo Help)

What is confirmed:

• Comcast is shutting down its own email-hosting platform and moving residential comcast.net mailboxes onto Yahoo Mail. Addresses stay the same (@comcast.net); messages, folders, and contacts carry over for accounts that accept Yahoo’s Terms of Service.
• New comcast.net account creation stopped in June 2024.
• Comcast Business customers are not included in the migration (as stated at announcement time).
• Users are given notice and a window (publicly reported as roughly 30 days’ notice plus a 120-day window) to accept Yahoo’s terms or export and close the account.

The operational consequence for senders: a comcast.net recipient who has migrated is a Yahoo-hosted recipient. Yahoo’s authentication requirements, spam-rate expectations, and Complaint Feedback Loop apply to that mail. During the transition you may encounter a mix of Comcast-hosted and Yahoo-hosted comcast.net addresses, so treat Comcast’s legacy postmaster rules as a floor and build to Yahoo’s requirements as the destination state.

Hypothesis to flag: the exact per-recipient cutover dates are not individually published, so you cannot know which specific comcast.net address is on which platform at a given moment. Plan for both.

Connection and infrastructure requirements

Comcast’s “Avoiding blocks” page states these as hard gates - failing them means the connection is refused or the mail is blocked:

Requirement	Comcast’s rule
RFC compliance	”All email must comply with all relevant RFCs.”
Reverse DNS	rDNS check on the sending IP; without a PTR record and a matching MX or A record set up properly, “the connections will not be accepted.”
No dynamic IP space	”Comcast does not accept mail from dynamic IP space.” Dynamic/residential ranges are treated as bot havens.
Stay off DNSBLs	Comcast consults several DNSBLs “including Spamhaus Zen, and ReturnPath” (now Validity). A listing on a reputable, widely used DNSBL is “likely to cause your email to be blocked.”
List hygiene	”A large number of undeliverable emails… will result in a sending IP being blocked. All ‘Not Our Customer’ NDNs should be treated as an unsubscribe request.”
Abuse management	Enforce acceptable-use policies; dictionary/directory-harvest attacks “will quickly lead to the sending IP being blocked.”
IP reputation	”Overall IP reputation is key to successfully sending to Comcast.”

Note Comcast does not publish an SPF/DKIM/DMARC mandate for senders in the way Gmail or Yahoo do. Its sender guidance leans on rDNS, IP reputation, and external blocklists. It does, however, honor sender DMARC as a receiver (below), and authentication factors into the rate-limit tier you are granted.

Sending limits (documented numbers)

These are published verbatim on the error-codes and avoid-blocks pages:

Limit	Value	Error when exceeded
Simultaneous connections per sending IP	25	421 - [Too many sessions opened]
Recipients per message	100	452 - [Too many recipients for message]
Messages per session	1000	452 - [Too many emails sent on this session]
Maximum message size	15 MB	552 - [Message size exceeded]
IPv6 messages per hour, per netblock	1000	(IPv6 sending policy)

Beyond these fixed caps, the per-hour recipient throughput is reputation-gated by the RL000001 table below.

Rate limiting by SenderScore (the RL000001 table)

Comcast applies inbound rate limiting and returns a 4xx temp-fail (RL000001) when you exceed your tier. The tier is set by SenderScore reputation, subject to successful authentication (Comcast’s own footnote). The published table:

Recipients per hour	SenderScore
300	N/A
1,200	0 - 15
3,600	16 - 25
7,200	26 - 30
14,400	31 - 50
50,400	51 - 70
72,000	71 - 85
86,400	86 - 100

RL000001 is a temp-fail by design: “This message is designed to instruct the sending server to try again at a later time.” Honor it with backoff rather than hammering the connection. The practical lever is reputation - a higher SenderScore unlocks a higher tier, and authentication is the gate to getting a tier at all.

DMARC as a receiver

Comcast announced DMARC support for comcast.net and honors sender policies, with one important nuance:

“By [publishing a DMARC policy] the domain can specify what action Comcast should take if they receive unauthenticated messages (no action, quarantine, or reject). Initially, Comcast will treat a ‘reject’ policy request by a sending domain the same as ‘quarantine’ and so will mark unauthenticated messages in both categories as spam. Comcast has also implemented DMARC aggregate reporting… Reports will be sent daily from dmarc-support@alerts.comcast.net.”

So: publish DMARC and you get aggregate reports from Comcast daily. But on the legacy platform, a p=reject failure was downgraded to spam-foldering, not refusal. Flag: that statement is from a dated announcement and predates the Yahoo migration; once a mailbox is Yahoo-hosted, Yahoo’s DMARC handling applies instead. Treat the Comcast wording as historical context, not a guarantee.

Error / block codes you will actually see

Comcast documents its codes in three families. The most operationally relevant:

4xx (temporary - retry with backoff)

Code	Meaning
421 - [Too many sessions opened]	Over the 25-connection-per-IP limit.
421 - [Reverse DNS failure : Try again later]	rDNS lookup failed (often a SERVFAIL upstream). Temp-fail; retry.
421 - [Try again later]	Generic deferral.
452 - [Too many emails sent on this session]	Over 1000 messages per session.
452 - [Too many recipients for message]	Over 100 recipients per message.
RL000001	Rate limit hit; you exceeded your SenderScore-based per-hour tier.

5xx (permanent)

Code	Meaning
550 - [Not our customer]	Recipient does not exist. Treat as an unsubscribe if you are a bulk mailer.
550 - [...too many invalid recipients]	Too many bad recipients in one transaction; none were delivered. Clean the list.
550 - [Invalid sender domain]	Sending domain lacks a valid A or MX record.
550 - [Account not available]	Recipient account currently unavailable.
552 - [Message size exceeded]	Over the 15 MB limit.
554 - [PTR lookup failure]	Sending IP has no valid PTR (an NXDOMAIN for the in-addr.arpa lookup).

ES / BL codes (policy and blocklist)

Code	Meaning
ES000001 / ES000010	Sending from dynamic/residential IP space - not allowed. rDNS does not match static naming conventions.
BL000000	”Email from your mail server has been sent in patterns that are characteristic of spam.” This is the one removable via the self-service form.
BL000001 … BL001111	A bitmask of third-party blocklist hits: Spamhaus SBL/XBL, Cloudmark Sender Intelligence (CSI), SenderScore, and TrendMicro MAPS, alone or in combination. Resolve the listing at the named provider, not with Comcast.

The BL00xxxx family is the clearest documented evidence of Comcast leaning on third-party reputation services (notably Cloudmark CSI) rather than purely in-house scoring - which is the practical meaning of “Comcast outsources filtering.” Flag: Comcast does not publish a contract or architecture statement, so the precise division of labor between Comcast’s own logic and Cloudmark’s is not something I can verify beyond the fact that CSI listings directly drive Comcast block codes.

Getting unblocked

Comcast’s self-service path is narrow and specific:

• The Blocklist Removal Form (postmaster.comcast.net/block-removal-request.html) “will assist in unblocking only if the error you received contains the error code BL000000.” For all other blocks, follow the link inside the bounce.
• A successful BL000000 removal “will take less than 30 minutes” in typical cases. Some blocks “cannot be lifted without first contacting Comcast Customer Security Assurance at 888-565-4329.”
• For dynamic-IP (ES) classifications and persistent IPv6 issues, the documented escalation is Customer Security Assurance (888-565-4329).
• If you are a Comcast residential customer having trouble sending to another domain, the form does not help - that is a CSA matter.

The feedback loop

Comcast operates a complaint feedback loop, distinct from the block-removal tooling:

“Feedback loop data is generated by user complaints as they make use of the ‘This is Spam’ reporting mechanism… an ARF formatted report will be sent to the sender… All feedback loop reports will contain the full headers of the message sent, but are scrubbed of Comcast customers’ email addresses… To sign up for Comcast’s Feedback Loop, please visit https://feedback.comcast.net.”

Key facts:

• Reports are ARF (RFC 5965 format), triggered by “This is Spam” clicks.
• Recipient addresses are redacted from the report and are never re-attached.
• Registration supports both IP-based and DKIM-based feedback loops.
• You must be “the party responsible for a server that sends mail to Comcast customers.” Shared-host senders should have the server owner enroll.
• Comcast “reserves the right to suspend or discontinue providing feedback to any party at any time.”

Process complaints the same way you would any FBL: suppress the complainant immediately and watch the trend, since complaint rate is a primary reputation input.

What Comcast does NOT publish (be honest about the gaps)

• No spam-complaint-rate threshold. Unlike Gmail (below 0.10% target, never 0.30%) and Yahoo (below 0.3%), Comcast publishes no numeric complaint-rate ceiling.
• No sender SPF/DKIM/DMARC mandate in the Gmail/Yahoo sense - authentication helps your rate tier and is honored as DMARC, but is not framed as a pass/fail gate on the sender pages.
• No published one-click-unsubscribe (RFC 8058) requirement.
• No dashboard. There is no Postmaster-Tools-style reputation portal; your signals are bounce codes, the FBL, and (if you publish DMARC) Comcast’s daily aggregate reports.
• No per-account migration calendar, so the Comcast-vs-Yahoo hosting state of any given address is not knowable in advance.

Common mistakes

• Treating the postmaster.comcast.net rules as the whole story in 2026. They are legacy and being superseded by Yahoo. Build to Yahoo’s requirements for this audience.
• Sending from residential/dynamic space. It is rejected outright (ES codes), regardless of content.
• Ignoring RL000001 temp-fails. They are reputation throttling; back off and improve SenderScore rather than retrying aggressively.
• Using the block-removal form for a non-BL000000 block. It only clears BL000000; other listings must be resolved at the blocklist provider (Spamhaus, Cloudmark, etc.) or via CSA.
• Not treating “Not our customer” bounces as unsubscribes. Comcast explicitly asks bulk senders to do so, and ballooning invalid-recipient counts get IPs blocked.

What Egressif does

We send to comcast.net the way the documentation demands and the way the migration points: meaningful reverse DNS with matching forward records on static, non-dynamic IPs; full RFC 5321/5322 compliance; SPF and DKIM published and aligned with a real DMARC policy, both because Comcast honors it (and emails daily aggregate reports) and because the migrated mailboxes are Yahoo-hosted, where authentication is a hard gate. We respect Comcast’s documented limits - 25 connections per IP, 100 recipients per message, 1000 per session, 15 MB - and we treat RL000001 as the reputation signal it is, backing off and protecting SenderScore rather than forcing throughput. We enroll in the feedback loop (feedback.comcast.net, DKIM-based) and suppress complainants immediately, and we treat “Not our customer” bounces as unsubscribes. Because Comcast is moving this audience to Yahoo Mail through 2026, we operate to Yahoo’s requirements as the destination state, not just the legacy Comcast floor. We do not promise the inbox: Comcast states that reputation and external blocklists decide delivery, and once a mailbox migrates, Yahoo’s filtering does.

For the destination-state requirements, see the Yahoo sender requirements and the cross-provider provider rule tracker. For authentication setup, see DMARC in 2026; for the reputation signals Comcast leans on, see the reputation overview.