start free

$ deliverability

Deliverability is the product, not a support ticket.

Any competent team can build a send endpoint. The hard part is a message that survives a spam filter at nine on a Monday morning. This page explains what actually decides that, and exactly what Pharos does about each part of it.

What decides whether your email reaches the inbox?

Four things, in roughly this order of weight. A receiving mail server evaluates all four before it decides between the inbox, the spam folder and outright rejection.

  • 01 Can it prove who sent it?

    SPF says which servers may send for your domain. DKIM signs the message so tampering is detectable. DMARC ties the two to the address the recipient actually sees. Fail these and you are competing with every phishing attempt that also failed them.

    Pharos: Enforced at send time. A domain that fails cannot send.

  • 02 Who else uses that IP?

    Reputation attaches to the sending IP, and on a large shared pool you inherit the behaviour of everyone else on it. Somebody else's bad week becomes your spam folder, and you will never be told which week it was.

    Pharos: IPs dedicated to Pharos, never a public pool. Isolated IPs on request.

  • 03 Does the infrastructure look legitimate?

    A sending host with no reverse DNS, or one whose PTR record does not resolve back to itself, looks like a compromised machine. Large receivers weight this heavily, and it is the check that quietly rots when nobody re-runs it.

    Pharos: Forward-confirmed PTR, re-scanned daily.

  • 04 How do recipients react?

    Complaints and hard bounces are the strongest negative signals there are. Mailing an address that has already rejected you, twice, is how a good sender becomes a bad one — and it is usually a retry loop, not a decision.

    Pharos: Automatic suppression on bounce and complaint, per account.

How does a Pharos send actually leave?

Four separate DNS planes, each doing one job. Keeping them apart is what lets bounce handling, click tracking and inbound replies operate without any of them weakening the authentication on the message itself.

  • Plane 01

    Send

    The path the message itself takes, signed and aligned before it leaves.

    SPF · DKIM · DMARC

  • Plane 02

    Bounce

    A dedicated return path, so rejections come back to a machine that reads them.

    Return-Path · MX

  • Plane 03

    Tracking

    Opens and clicks on their own hostname, so a tracking domain cannot drag the sending one down.

    CNAME · TLS

  • Plane 04

    Inbound

    Submission and replies, separated from the outbound path entirely.

    MX · submission

signed webhooks · delivered · bounced · complained 01 your app n8n · agent · cron 02 API or SMTP relay one queue, either way 03 sign & align DKIM · SPF · DMARC 04 Pharos email server Pharos IPs · FCrDNS 05 recipient inbox not the spam folder
  1. 01 your app n8n · agent · cron
  2. 02 API or SMTP relay one queue, either way
  3. 03 sign & align DKIM · SPF · DMARC
  4. 04 Pharos email server Pharos IPs · FCrDNS
  5. 05 recipient inbox not the spam folder
  6. ↑ signed webhooks return delivered, bounced and complained events to your app

What is forward-confirmed reverse DNS, and why does it matter?

Reverse DNS turns a sending IP back into a hostname. Forward-confirmed means that hostname resolves back to the same IP — the loop closes. Spam sources rarely close it, so receivers treat an open loop as a strong negative signal.

It is also the check most likely to break silently. A hosting provider reassigns an IP, a PTR record is never updated, and mail that delivered fine last quarter starts landing in spam with no error anyone can see. Setting it once is not the same as knowing it is still true.

→ Pharos re-scans the whole set daily and alerts on drift.

The loop, closed● verified
# IP resolves to a hostname
$ dig -x <sending-ip> +short
  mta1.pharosinfra.net.

# and that hostname resolves back to the IP
$ dig mta1.pharosinfra.net +short
  <sending-ip>

→ forward-confirmed
Run it yourself. This is a claim you can check from a terminal.

What Pharos does not claim.

A deliverability page that only lists strengths is marketing. These are the limits, stated plainly, because you will find them out anyway and it is better that you hear them here.

No inbox placement percentage
Nobody can promise one. Placement depends on your content, your recipients’ behaviour and filtering rules that change without notice at receivers who do not publish them. Any provider quoting you a guaranteed inbox rate is quoting you a number they cannot control.
Authentication is necessary, not sufficient
Perfect SPF, DKIM and DMARC gets your message evaluated on its merits. It does not rescue mail people did not ask for. If your complaint rate climbs, no amount of infrastructure hygiene offsets it.
Your domain reputation is yours
Pharos manages the sending IPs. The reputation of the domain in your From address is built by what you send and who you send it to, and it follows you between providers. Changing gateway does not reset it.
Transactional only, for now
Pharos is built for mail a person triggered and expects — receipts, resets, alerts, notifications. It is not a bulk marketing platform, and mixing the two on one sending identity is how the transactional mail starts getting filtered.

Check the claims, then send something.

Every technical assertion on this page is verifiable from a terminal. The free plan is 3,000 emails a month with all of it switched on.

start free