Your ISP's domain almost certainly has a spoofing problem. Not "might have" or "could have." If you haven't specifically configured DMARC, DKIM, and SPF, set them correctly, and verified they're actually doing what you think they're doing, your domain is available for anyone on the internet to use as a sender address in phishing and spam campaigns. This isn't a risk that lives somewhere in the future: it's a real-time problem that's either happening already or will start happening the moment someone with bad intent decides you're a useful cover.
For ISPs specifically, the stakes are higher than they are for most businesses. Your domain is associated with connectivity and technical services, which makes it a credible impersonation target for phishing campaigns aimed at your subscribers, your corporate clients, and other operators you peer or transit with. A convincing email from your domain telling a subscriber their account needs urgent verification, or telling a corporate client their invoice is attached, doesn't require any compromise of your actual systems. It requires nothing from you at all.
What These Three Protocols Actually Do
SPF, DKIM, and DMARC are three separate mechanisms that work together. Understanding what each one does, and doesn't do, matters because ISPs often have one configured and assume it covers all three.
SPF, Sender Policy Framework, is a DNS record that lists the IP addresses and mail servers authorized to send email on behalf of your domain. When a receiving mail server gets a message claiming to be from your domain, it checks your SPF record to see whether the sending IP is on your list. If it isn't, the message fails SPF. What SPF does not do is tell the receiving server what to do with a failure: that decision belongs to DMARC.
DKIM, DomainKeys Identified Mail, works differently. It attaches a cryptographic signature to outgoing emails, generated by a private key your mail server holds. The receiving server looks up the corresponding public key from your DNS and verifies the signature. If it matches, the message content hasn't been tampered with in transit and the sender controls the domain whose key was used. DKIM survives email forwarding in a way SPF doesn't, which is one reason you need both rather than picking one.
DMARC, Domain-based Message Authentication Reporting and Conformance, is the policy layer that ties them together. It tells receiving servers what to do with messages that fail SPF or DKIM, and crucially, it tells them to send you reports about what they're seeing. Without DMARC, SPF and DKIM failures result in inconsistent handling across different mail providers, some will deliver anyway, some won't, and you get no visibility into either outcome. DMARC gives you both the enforcement and the data.
How to Check Where You Actually Stand
Before changing anything, find out what you currently have. For each of your domains and any subdomains you send email from, run the following checks. MXToolbox and similar free tools will show you these records if you don't have direct DNS access handy, though given you're running an ISP, you should have that access.
For SPF: look up your domain's TXT records and find the one starting with "v=spf1". If it doesn't exist, you have no SPF record. If it exists, check that every IP address and mail server you actually send from is listed, gaps here mean legitimate mail you send will sometimes fail SPF, which creates its own deliverability problems independent of the security issue.
For DKIM: check whether your mail server is signing outgoing mail. This varies by platform. On most mail servers, you'll find a selector, a short label added to the DNS lookup, that you can verify is publishing a valid public key. If your mail server isn't signing, there's no DKIM record to look for.
For DMARC: look for a TXT record at _dmarc.yourdomain.com. If it doesn't exist, you have no DMARC policy. If it exists, check the "p=" value: "p=none" means monitoring only, no enforcement, "p=quarantine" sends failures to spam, and "p=reject" tells receiving servers to drop failing messages entirely.
Most ISPs we assess have one of two configurations: no DMARC at all, or DMARC set to "p=none" and never changed from the initial setup, which provides monitoring data but zero enforcement. Neither stops your domain from being used by someone else to send phishing mail.
Why ISPs Sit at p=none and Never Move Forward
The standard advice is to start at p=none, collect reports for a few weeks to understand your legitimate mail flows, then move to quarantine and eventually reject. That advice is correct. The reason it gets stuck at p=none indefinitely is that reading and acting on DMARC aggregate reports is tedious without tooling, the XML format they arrive in wasn't designed for human consumption, and moving to enforcement requires confidence that you've captured every legitimate sending source first.
The actual path forward is: get your SPF record right first, covering every IP your mail genuinely sends from, set up DKIM signing on your primary mail server, then add DMARC at p=none with a reporting address you'll actually check. Give it two to three weeks to collect data, specifically looking for legitimate mail sources that aren't yet in your SPF record or aren't signing with DKIM. Once those gaps are closed, move to p=quarantine. If your legitimate mail delivery rates stay normal after two weeks at quarantine, move to p=reject. That's the whole process. The reason to do it in stages rather than jumping straight to reject is that a misconfigured SPF record combined with p=reject means your own legitimate mail gets rejected along with the spoofed mail, and diagnosing that in production is more painful than the staged rollout.
What DMARC Has to Do With CTDISR-2025
If you're a PTA licensee, this isn't just operational hygiene. CTDISR-2025 Section 12 covers endpoint and device security including organizational communication channels, and Section 14's staff security and HR controls implicitly depend on organizational email being trustworthy as an internal communication channel. More directly, Section 9's network security controls and the general security awareness requirements throughout CTDISR create an environment where an ISP whose domain is actively being used in phishing campaigns is in a poor position to demonstrate competent security management during a PTA audit. A third-party audit firm finding that your own domain lacks basic email authentication is a straightforward adverse finding.
DMARC, DKIM, and SPF configuration is one of the faster fixes in any security posture improvement program: it's a DNS change, there's no infrastructure to deploy, and it's verifiable immediately. The sequencing work, understanding your mail flows before enforcing policy, takes a few weeks, but the records themselves take an hour to create once you know what they should say.
If you want help getting this done properly, covering all your domains including any subdomains used for billing systems, NOC communications, or client-facing services, the Cloud & Email Security engagement covers exactly this, and we include it as a standard check in every Cybersecurity for ISPs assessment. For operators preparing for a PTA audit, it comes up as part of CTDISR Audit Readiness as well.