On 11 September 2026, an outbound email to an enterprise account bounced. The recipient's perimeter was defended by Sophos. The sales representative assumed the prospect had left the company, or that the phrasing in the subject line had triggered a content filter.
Neither was true. The mailbox existed, the recipient was active, and the message text was entirely benign. The bounce was an authentication rejection generated at the mail gateway.
When a subsequent DNS audit was run, the records told the real story: SPF was valid, resolving across 8 of the standard 10 lookup limit. DKIM was signed and fully active. But DMARC was published with an explicit policy of p=none. The receiving mail server looked at that configuration, evaluated sender reputation, and dropped the message.
Most outbound teams spend their energy rewriting opening lines while their technical infrastructure quietly ensures their emails are discarded before reaching the inbox.
The Four Pillars of Deliverability
Deliverability is not governed by sentiment analysis or avoiding words like "synergy". It is decided by four technical factors:
- SPF (Sender Policy Framework): A DNS text record specifying which IP addresses are authorised to send mail on behalf of your domain. The standard has a hard limit of 10 DNS lookups. Exceeding that limit causes SPF to fail outright, but even reaching 8 or 9 lookups introduces lookup latency that some enterprise filters penalise.
- DKIM (DomainKeys Identified Mail): A cryptographic signature attached to the email header. The receiving server uses your public DNS key to verify that the email originated from your domain and was not altered in transit.
- DMARC (Domain-based Message Authentication, Reporting, and Conformance): The policy instruction that tells receiving servers what to do if SPF or DKIM checks fail. It unifies SPF and DKIM under your domain's identity.
- Sending Reputation: The historical behavioural score assigned to your sending IP and root domain by corporate gateway vendors (such as Sophos, Mimecast, or Proofpoint) and consumer inbox providers. This score drops whenever recipients mark mail as spam, when you hit spam traps, or when authentication records fail.
Why a Bounce Is Rarely a Dead Address
When a sales representative sees a hard bounce in a sequence tool, the standard reaction is to mark the contact as "no longer at company" and remove them from CRM records. This is frequently a mistake.
Email gateways issue bounce codes for multiple reasons. An address rejection code can mean the mailbox does not exist (a 550 user unknown error), but enterprise security filters often return generic or misleading rejection notices when an incoming message fails domain security checks or triggers local reputation thresholds.
When gateway security tools inspect an inbound message, they check whether the sending domain authenticates cleanly. If the domain's authentication records are incomplete, ambiguous, or permissive, strict perimeter filters reject the delivery at the SMTP transaction stage. The address is valid; the sender is not trusted.
Treating technical bounces as defunct contacts corrupts pipeline data and discards viable prospects who simply sit behind well-configured enterprise gateways.
The Problem with p=none
In the audit following the Sophos rejection, the offending setting was p=none in the DMARC record.
When organisations first configure DMARC, IT teams typically deploy v=DMARC1; p=none;. This is an observation policy. It instructs receiving mail servers: If authentication fails, do not block the email; simply send an aggregate report back to us.
This policy is meant to be a temporary audit phase while IT catalogues internal sending services. However, in mid-market companies, DMARC records routinely remain at p=none indefinitely.
Modern enterprise security systems increasingly view p=none as an indicator of an unmanaged, unauthenticated, or spoof-vulnerable domain. When outbound volume increases or a recipient gateway runs a strict security posture, an email accompanied by p=none often receives an elevated risk score. If that score crosses the gateway threshold, the message is either silently quarantined or bounced.
To ensure reliable transit into corporate inboxes, domains must move from p=none to an enforcement policy: either p=quarantine (instructing receiving servers to route failing mail to spam) or p=reject (instructing them to block it entirely). Counter-intuitively, declaring an enforced policy makes external mail servers trust your legitimate mail far more than declaring no enforcement at all.
What to Ask IT to Change
Sales leaders do not need access to the DNS zone file, but they must know what to request from their systems administrators. A generic request to "fix deliverability" will result in IT pinging the mail server and reporting that everything is functional.
Send your IT administrator the following specific audit checklist:
- Check SPF lookup count: Ensure the SPF string does not exceed the 10-lookup limit. If third-party tools have bloated the record to 8 lookups or more, request that unused sending services be removed or the record flattened.
- Audit DKIM selectors: Confirm that all outbound sending services are signing with 2048-bit DKIM keys and that the public keys in DNS match.
- Graduate DMARC beyond
p=none: Review the incoming DMARC aggregate reports, confirm that all legitimate outbound mail is aligned, and schedule an update of the DNS record top=quarantineorp=reject. - Monitor gateway reputation: Use postmaster dashboards to verify whether the root domain or dedicated sending IPs have been flagged by major corporate security providers.
Pipeline execution fails when technical infrastructure is ignored. At OppStream, we observe that teams regularly cycle through outbound messaging variants to fix drop-offs in replies, completely unaware that their messages were rejected at the gateway due to a single DNS flag.