The four records
MX. The MX record names the servers that accept mail for a domain. It plays no part in authentication. It is read because a domain without one cannot receive replies, nor the DMARC reports its own mail produces.
SPF (RFC 7208). A TXT record at the domain itself listing the servers allowed to send with that domain in the return path. A receiver evaluating it may make at most 10 DNS lookups (section 4.6.4): include, a, mx, ptr, exists and redirect cost one each, and ip4, ip6 and all cost none. Past 10 the result is a permanent error, and receivers treat the record as absent. Toreject counts the live record through every include, and composes one record per order from the listed services, refusing to sell a record set that would pass 10. The counter is checked against the RFC's own examples in Appendix A.
DKIM (RFC 6376). A public key published at <selector>._domainkey.<domain>. A sending service signs each message with the matching private key, and the selector names where the key lives. Most services publish the key behind a CNAME they control, so they can rotate it. Toreject asks for a key at every selector the listed services use, and at 20 common names.
DMARC (RFC 7489). A TXT record at _dmarc.<domain> telling receivers what to do with a message whose From domain does not match the domain of a passing SPF or DKIM result: p=none reports and delivers, p=quarantine treats the message as suspicious, usually the spam folder, and p=reject refuses it. Aligned means the domain that passed is the domain in the From line. The record also names where aggregate reports go (rua); receivers send them daily by default, since the ri tag defaults to 86400 seconds (section 6.3). Enforcement means quarantine or reject.
The step rule, and why seven days
Step up one rung when the daily record shows 7 days in a row with every listed service's DKIM key published and the SPF record within 10 lookups. Paste p=quarantine on the day the record says safe, then p=reject after 7 more clean days at quarantine.
Seven, because a small business sends on a weekly rhythm: the newsletter one day, the invoices another, the shop's receipts every day. A week of clean reads covers one full turn of it, so every listed service has signed real mail while its key was published. A day the read could not reach DNS breaks the run instead of counting toward it, and a day the cron did not run is left empty, never filled in.
The rule reads keys and lookups. It cannot see a service nobody listed. That service shows up in the aggregate reports, which is why p=none comes first and why its reports go to a mailbox you read.
What is not done
- No message is examined. Alignment is inferred from published records, and the receipt says so in its own first line:
no message was examined; alignment is inferred from published records. - The aggregate reports go to the buyer's own mailbox. Reading them is the buyer's job, or the call's, in this version.
- A DKIM key is found only at the selector names asked for. HubSpot numbers its selectors by account, and Shopify names its records per store, so neither can be read by name until the buyer supplies the names.
- This version does not read aggregate reports, publish BIMI, or set policies for sub-domains beyond the
sp=tag a receiver inherits. - Nobody can promise an inbox, and this page does not. The promise is a DNS state on a date, which anyone can check with
dig.
Where the record is kept
Toreject keeps no database. The order's details (domain, services, DNS host and email) sit in the Stripe Checkout Session's metadata. Each morning at 06:00 UTC the daily read writes one entry to the payment's metadata, under keys d00 to d44, and the step dates under a key named steps. Each entry is one line: the time, the resolvers, the policy, the SPF lookup count, the DKIM selectors that carried a key, and a one-word verdict. The plan and record pages rebuild everything from those keys on every visit, and the receipt is sealed fresh from them.
The alternatives, and what they cost
| Who | What is sold | Published price |
|---|---|---|
| dmarcian | Monitoring: a dashboard of DMARC reports | Basic $24/mo ($239.88/year, up to 2 domains) |
| EasyDMARC | Monitoring | DMARC Plus $35.99/mo on annual billing (regular $44.99), 2 domains |
| A freelancer on Contra | One day of set-up | $30 |
| izivizi on Gumroad | One-time set-up | EUR 159, five business days (unverified: read from a search summary, not the page) |
| Valimail, on Vendr | Enterprise DMARC | "Median buyer pays $16,281 per year", from 32 purchases |
Prices read on 9 October 2026. A job that ends should be sold as a job that ends. Once a domain is at p=reject and the record shows it, the set-up is done; a dashboard rented month after month suits a company with a mail team and fits an office with none badly. Toreject sells the job, for one price, or the money back.
The sending services the record set covers
| Service | SPF at your domain | DKIM selectors read | The vendor's own page |
|---|---|---|---|
| Google Workspace | include:_spf.google.com, 1 lookup | google | SPF, DKIM |
| Microsoft 365 | include:spf.protection.outlook.com, 1 lookup | selector1 selector2 | SPF, DKIM |
| Mailchimp | none | k2 k3 | set-up page |
| Klaviyo | none | km1 km2 kt1 kt2 ks1 ks2 kl1 kl2 | set-up page |
| Shopify | none | named per store | set-up page |
| SendGrid | none | s1 s2 | set-up page |
| Brevo | none | brevo1 brevo2 mail | set-up page |
| HubSpot | include:<account>.spf0<n>.hubspotemail.net, 1 lookup | named per account | set-up page |
| Zendesk | include:mail.zendesk.com, 1 lookup | zendesk1 zendesk2 | SPF, DKIM |
| Intercom | none | intercom | set-up page |
| Resend | none | resend | set-up page |
Each include's lookup count was measured on live DNS on 10 October 2026 UTC. Each vendor page answered 200 on the same date, and its address, final address and status are in sources.json. "None" means the service's own set-up asks for no line in the SPF record at your domain; its SPF lives on a subdomain or a return path it controls.
Why the bounces started
Google's sender guidelines: from 1 February 2024 every sender to Gmail needs SPF or DKIM, and a sender of 5,000 or more messages a day needs SPF, DKIM and DMARC. Yahoo asked the same of bulk senders from February 2024. Microsoft (2 April 2025, updated): domains sending more than 5,000 messages a day to Outlook.com need SPF, DKIM and DMARC, and from 5 May 2025 their non-conforming mail goes to Junk, with rejection (550 5.7.515) to follow.
Gmail's bounce, word for word from its SMTP error list: 550 5.7.26 This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM. The same code also names a domain whose own DMARC policy refused the message.
Sources
- S. Kitterman, RFC 7208, Sender Policy Framework, April 2014. Vendored into the tests; its Appendix A records are the SPF receipts.
- M. Kucherawy and E. Zwicky, RFC 7489, DMARC, March 2015. Vendored; its Appendix B records are the DMARC receipts.
- D. Crocker, T. Hansen and M. Kucherawy, RFC 6376, DKIM Signatures, September 2011.
- The DNS read is the mailready check, vendored byte for byte with its source commit in
server/vendor/VENDORED-FROM.md. - Every vendor, receiver and price above is cited from its own page and named as a source. None of them is affiliated with Toreject.