Loading
Loading
We use strictly necessary cookies to run this site, and analytics cookies to understand how it's used. See our Privacy Policy for details.
Three DNS records that determine whether someone can spoof your domain in a phishing email, what each one does, and how to check whether yours are actually enforced.
SPF, DKIM, and DMARC are three separate DNS records that, together, determine whether someone can send an email that appears to come from your domain without ever touching your actual mail servers. Missing or misconfigured, they're one of the most common, and most invisible, gaps we find, because a broken record doesn't break anything for the sender; it just fails to protect anyone else.
An SPF (Sender Policy Framework) record is a DNS TXT entry listing which mail servers are authorized to send email on behalf of your domain. A receiving mail server checks the sending server's IP against this list; if it's not there, the message fails SPF.
The detail that trips people up is the qualifier at the end of the record: -all (hard fail, reject anything not listed), ~all (soft fail, accept but flag it), or +all (explicitly allow anyone, this is the misconfiguration itself, not a fallback). A soft fail is meaningfully weaker than a hard fail, and it's a very common leftover from an initial rollout that was never tightened once things were confirmed working.
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing mail, generated with a private key and verifiable against a public key published in DNS. Where SPF checks where a message came from, DKIM checks whether it was tampered with after leaving your server. A domain can have SPF configured perfectly and still have no DKIM selector published at all, which is a gap we check for specifically because it's easy to overlook once SPF is "done."
DMARC (Domain-based Message Authentication, Reporting and Conformance) is what actually tells receiving mail servers what to do when a message fails SPF or DKIM, and it's the record most commonly missing entirely, even on domains that have SPF configured. A DMARC record without an enforced policy (p=none, monitoring-only) provides visibility but doesn't stop anything; p=quarantine or p=reject are what actually block spoofed mail from reaching a recipient's inbox.
A domain with weak or missing SPF/DMARC is significantly easier to spoof convincingly in a phishing campaign, including one impersonating your own company to your customers or partners, which is a brand and trust problem independent of whether your own inbox is affected at all. This is a large enough real-world attack pattern that the CISA BOD 18-01 directive specifically mandated DMARC enforcement across federal agencies for exactly this reason.
Our free Domain Footprint Analyzer checks a domain's SPF, DMARC, and DKIM configuration directly, including whether DMARC is actually set to enforce, not just monitor, and scores the overall email spoofing risk based on what it finds. It's the same passive check we described above, run against your own domain in about ten seconds.
If you've already had a domain or executive impersonated in a phishing attempt, or want to check whether your own email address has surfaced in a known data breach, our Email Breach Checker is a good next step, and if the gaps run deeper than DNS records, that's exactly what a full penetration test or security consulting engagement is built to find. For what a spoofed-domain email actually turns into once it lands, see our piece on business email compromise. For a different DNS-level exposure entirely, a forgotten record that lets an attacker take over part of your own domain, see subdomain takeover, explained.
Tell us about your environment and goals, we'll help you scope the right engagement.