The short answer
An AI agent's email lands in spam for the same reasons anyone's does: the domain cannot prove the mail is its own, the domain has no record yet, the messages look like a campaign, or earlier mail bounced and drew complaints. Most of those are decided before a filter reads a word, by DNS records and by what the sender did last week. Pidgeon publishes the records, refuses the sends that damage a reputation before they leave, and keeps each customer's reputation in its own pod, but it cannot make a new domain trusted overnight.
Why agents meet this sooner
Nothing in a spam filter looks for "an AI wrote this". What agents do differently is volume and repetition. A person sends a handful of distinct messages a day. An agent can send the same message to two hundred people before lunch, retry a send it believes failed, or answer its own auto-reply in a loop. Mail providers judge a domain by what it does, so the first week of an agent on a fresh domain is often the worst week the domain will have.
So the useful question is not "how do I get out of spam" but "which of these is mine to fix, and which is already handled".
What the receiving server checks first
Before anyone scores the content, the receiving server asks whether the domain in From: sent this mail. Three DNS records answer it.
SPF names the servers allowed to send for your domain. With Pidgeon it is one TXT record at the domain, v=spf1 include:amazonses.com ~all. A domain may have only one SPF record, so if you already send through another provider, merge the two rather than adding a second. When Pidgeon writes the record for you, it never adds a second one.
DKIM signs each message so a receiver can check it came from you unchanged. Pidgeon's records are three CNAMEs under _domainkey. They usually verify within an hour. The provider looks for up to 72 hours from when the domain was added, then stops; publishing the records after that changes nothing. Pressing "Check again", or POST /v1/domains/{id}/verify, starts it over, with three new records to publish.
DMARC ties the visible From: domain to the other two and tells receivers what to do when they fail. Pidgeon publishes p=none with reports sent to us: it asks for nothing to be rejected while you may still send through another service, and tightening it is your call. If your domain already has a DMARC policy, Pidgeon leaves it alone. On a subdomain it publishes none, because a subdomain inherits its parent's policy.
The domain page shows each record's state on its own (connected, published, missing, wrong_value or wrong_name), so a record at the wrong name in your DNS panel is named as such rather than reported missing. See domains. This part is yours to finish once, and then it stays done.
What a new sender is allowed
A domain registered last week has no record, and a provider treats no record with suspicion. Nothing makes a brand-new domain trustworthy overnight, so the honest fix is to start small and let the record build.
Pidgeon does that whether you ask or not. A new account starts with a smaller daily allowance and earns its way up. A Free account in its first 72 hours sends 20 messages a day, at most 5 recipients for one body, and its outbound stops after 3 hard bounces or a single complaint. Confirming your email, verifying a domain and time without complaints raise the account's trust score, and with it the share of the plan it may send.
If your company's main domain already sends mail people rely on, give the agent a subdomain such as agents.yourcompany.com. Its records are its own, and your company's mail server is never touched. When you add a domain that already receives mail, Pidgeon says who receives it and offers that subdomain.
What Pidgeon refuses before it leaves
Most of what ruins a sender's record is a handful of patterns, and each one is refused at send time rather than discovered in a bounce report:
- A loop. A message that is not a reply, to somebody the address already wrote to three times in the last ten minutes, is refused by default. That is the loop stopped at the fourth copy.
- The same body to many people. Pidgeon refuses the same body to more than 20 recipients in 24 hours. Tracking tags in links are ignored when it compares, so a mailing that differs only by its tracking tags still counts as one body; a password reset, whose link differs for each person, does not.
- An address that already bounced or complained. A permanent bounce or a complaint adds the address to your account's suppression list, and a later send to it is refused loudly instead of sent again. Transient bounces never suppress. You can lift a suppression in Settings → Delivery when you know the address works again.
- A burst. Sending is capped per plan per five minutes and per day (20 and 100 on Free, up to 5,000 and 50,000 on Enterprise), and a refusal carries
Retry-After. Underneath, every send passes through one pacer kept under the provider's own sending rate, so a burst queues for a moment instead of arriving all at once.
POST /v1/messages/check runs every one of these checks and sends nothing, so an agent can ask before it writes to someone new.
What the agent writes is still yours. Cold outreach from a new domain is the case filters are built for; an agent that replies to mail it received sits in an existing conversation, which is the strongest position a sender can have. On Free, Pidgeon adds one "Sent via Pidgeon" line to each message; paid plans add nothing.
When one customer's mail sinks another
If you send for several customers from one account, one of them mailing a stale list can drag down everyone. Put each customer in a pod: each pod has its own sending reputation at the provider, so one customer's bounces stay on their pod. GET /v1/metrics?pod_id=… shows the pod's bounce and complaint counts, and reputation.sending turns paused if the provider stops that pod alone.
The suppression list and the daily caps are the account's, not the pod's, so a pod limits the damage to reputation rather than to your allowance.
Spam, or never sent?
An agent that sees no reply cannot tell, on its own, whether its mail was filtered or never went. Pidgeon reports each outcome as an event: message.delivered, message.bounced, message.rejected and message.complained. A refused send comes back at once with the reason, so "not sent" is never silent.
What no sender can see is the folder. A delivery event means the receiving server accepted the mail, not that it reached the inbox. Test sends to accounts you control are the only check for that.
What Pidgeon cannot fix
It cannot give a new domain a history, or make a filter trust mail its recipients did not want. It sets DMARC to p=none and leaves enforcement to you. And it cannot tell you which folder a message landed in.
Start
Add your domain from domains, publish the records it lists and wait for each one to read connected. Sending explains every refusal, limits has the numbers per plan, and webhooks lists the delivery events to watch.