Once you are known as the person who did the email security work, you will be sent problems that sound like email security problems and are not. Recognising them quickly is a service to everyone, including the person asking.
Five that will arrive
| The request | What it actually needs |
|---|---|
| “Staff are receiving phishing. Can DMARC stop it?” | Inbound filtering, and client-side warnings on external mail. Your DMARC policy governs mail claiming to be from you, which is outbound-facing. It contributes only insofar as other domains enforce theirs. |
| “Our mail goes to spam. Can we tighten DMARC?” | Complaint rate, list hygiene, sending consistency. Authentication is a precondition that this domain has probably already met, and tightening the policy affects failing mail, not filtered mail. |
| “Someone registered a domain like ours.” | Registration monitoring, certificate-transparency watching, and a takedown process. No record you publish affects a domain you do not own. |
| “Can we stop people forwarding our emails?” | Nothing in email can. Forwarding is a recipient action on a message they hold, and any control that appears to prevent it is cosmetic. |
| “Make sure only approved staff can email customers.” | Identity and access management, plus outbound policy on the mail platform. DMARC authorises domains and infrastructure, not people. |
How to redirect without dismissing
Each of these is a real problem and the person asking is right to raise it. The useful response names the control that does address it and, where possible, the team that owns it. “That is not what DMARC does” is accurate and unhelpful; “that is inbound filtering, which sits with the platform team — here is what I would ask them” is both.
The one that is genuinely yours
“Are we sure nobody is sending as us?” is the question this entire track answers, and it has a specific answer once aggregate reports exist: a number, from evidence, updated daily. Being able to give that answer immediately is most of what the programme bought.