Three DNS records decide whether your mail arrives or quietly disappears into a spam folder. No amount of reputation work saves a domain that cannot prove it is you. So we queried our own rather than assuming they were fine.
SPF — present and correct, pointing at our mail
provider.
DKIM — present, returning a valid key.
DMARC — present, set to p=none.
MX — our provider's full set, as expected.
Authentication is not our problem. All three exist and align. That is a boring result and it is the one we wanted, and we would not have known it without looking.
All three present on our own domain, queried directly rather than assumed, 17 August 2026 — the same domain the mail we cannot afford to lose travels through.
The one thing we are not doing about it
p=none is monitor-only. It reports and enforces nothing,
which is the normal starting posture. The obvious next step is to
raise it to quarantine.
We are not going to, yet. Raising DMARC enforcement is a real decision with a real risk of dropping legitimate mail, and mail we cannot afford to lose runs through this domain. Get that wrong and the failure mode is not a missed newsletter.
That change should be made on evidence from the reports we are already collecting, not on the strength of an article. Not everything true is urgent.
What actually goes wrong, and why nobody notices
Every send is graded. Providers sort domains high to bad, and reputation slides gradually: mail to people who never open, a few spam-button presses, dead addresses bouncing. Nobody sends you a warning. Your email still sends. It just lands somewhere nobody looks, and you conclude the offer stopped working.
The free instrument for this is the provider's own postmaster tools — add the domain, add one TXT record, wait a couple of days. Three numbers to read: your reputation grade, your spam rate (keep it under 0.1%), and whether authentication is passing.
The two steps we are refusing
The playbook's step two is a warming service that sends mail into a network of tens of thousands of inboxes which open it and reply, so providers learn you are wanted. That is the correct medicine for a damaged reputation. Ours is not damaged, it is barely used — and manufacturing engagement from strangers to simulate a signal sits badly beside everything else we publish. No.
Step three is tagging spam complaints, unsubscribes and bounces in a CRM we do not have. The logic is right and portable: tag on those three events and use the tags as an exclusion filter on every campaign. The tag is not for reporting, it is a wall. The tool it is sold through is not the point.
Check that you can even see a bounce
Every workflow above assumes a visibility most sending setups do not have.
The usual arrangement gives an automated sender permission to send and no permission to read, and keeps no log of what went out. It is easy to end up there and hard to notice, because sending works perfectly — mail leaves, nothing errors, and every failure lands on the other side of a wall your script cannot see over. The bounce, the complaint and the reply all arrive somewhere it will never look.
So before you design a suppression policy, find out whether you can observe the three events it is built on. A suppression policy you cannot verify is a policy on paper.
What to do
Query your own SPF, DKIM and DMARC today — it takes three commands and the answer is either reassuring or urgent. Then add postmaster tools while you are in the DNS panel anyway. Leave enforcement alone until the reports tell you something.