SPF, DKIM, and DMARC explained

SPF, DKIM, and DMARC are the three DNS-based standards that prove an email genuinely came from your domain. Configured together, they stop attackers from spoofing your exact domain in the From address. They are essential, and they have one important blind spot that this guide makes plain.

SPF: which servers may send for your domain

Sender Policy Framework (SPF) is a DNS TXT record that lists the mail servers authorized to send email on behalf of your domain. When a receiving server gets a message, it checks the sending server's IP address against your published SPF record. If the sender is not on the list, the message fails SPF.

A simple SPF record looks like v=spf1 include:_spf.google.com -all, which authorizes Google's mail servers and tells receivers to reject everything else. SPF validates the envelope sender (the hidden return path), not the From address your users see, which is part of why it cannot stand alone.

DKIM: a cryptographic signature on each message

DomainKeys Identified Mail (DKIM) adds a digital signature to outgoing messages. Your mail server signs each message with a private key, and the matching public key is published in a DNS TXT record under your domain. The receiving server fetches that public key and verifies the signature. A valid signature proves two things: the message genuinely came from your domain, and it was not altered in transit. If a single header or byte covered by the signature is changed, DKIM fails.

DMARC: the policy that ties it together

Domain-based Message Authentication, Reporting and Conformance (DMARC) is the record that makes SPF and DKIM useful for stopping spoofing. DMARC checks that the domain validated by SPF or DKIM aligns with the visible From domain your users actually read. It then tells receivers what to do when a message fails:

• p=none takes no action and only collects reports. Use it briefly while you roll out, not as a destination.
• p=quarantine sends failing mail to spam or junk.
• p=reject blocks failing mail outright. This is the goal.

DMARC also enables aggregate and forensic reporting, so you receive data on who is sending mail that claims to be from your domain. For real spoofing protection, aim for p=reject, or at minimum p=quarantine, with SPF and DKIM both aligned to your From domain.

How the three work together to stop exact-domain spoofing

Individually, each mechanism has a gap. SPF checks the envelope, not the visible From. DKIM proves integrity but does not by itself require alignment with the From domain. DMARC binds them to the From address and adds enforcement. Together they mean that if an attacker tries to send mail from your exact domain without your keys and your authorized servers, the message fails authentication and your DMARC policy tells the receiver to quarantine or reject it. This is what blocks classic spoofing of your real domain.

The critical limit: none of this stops lookalike domains

Here is the part that trips up many teams. SPF, DKIM, and DMARC only protect the exact domain you publish them on. They say nothing about a different domain that merely looks like yours.

Suppose your domain is acmebank.com, fully locked down with p=reject. An attacker registers acmebank-secure.com and sets up SPF, DKIM, and DMARC on that lookalike. Mail sent from acmebank-secure.com authenticates perfectly, because it is legitimately authenticated for that attacker-owned domain. DMARC passes. Your customer sees a plausible bank name and a green authentication result, and the protection you built does nothing, because it was never about that domain.

This is not a flaw in DMARC. DMARC is doing exactly what it is designed to do: protect your exact domain. The point is that email authentication and lookalike-domain monitoring solve different problems and are complementary, not substitutes. You need email authentication to stop exact-domain spoofing, and you need monitoring to catch the cousin domains that authentication will never touch. These cousins are often built with typosquatting techniques: a transposed letter, an extra word, or a different suffix.

Closing the lookalike gap

Once your SPF, DKIM, and DMARC are at p=reject, the remaining attack surface is registration of confusingly similar domains. Continuous monitoring of newly registered lookalikes, their DNS and MX records, and their certificates, catches those domains early, often as soon as a certificate appears in Certificate Transparency logs. VigilDNS does exactly this, flagging mail-capable lookalikes that are positioned to impersonate your domain. If someone has already registered one, here is what to do when someone registers a lookalike of your domain.

Frequently asked questions

Do I need all three of SPF, DKIM, and DMARC?

Yes. SPF and DKIM each prove part of the picture, and DMARC ties them to the visible From domain and adds an enforcement policy. Without DMARC at quarantine or reject, attackers can still spoof your exact domain even if SPF and DKIM exist.

Will DMARC stop lookalike or typosquatted domains?

No. DMARC only protects the exact domain it is published on. A lookalike such as acmebank-secure.com can publish its own valid SPF, DKIM, and DMARC and will pass authentication. Stopping lookalikes requires separate monitoring of similar domain registrations.

What DMARC policy should I use?

Aim for p=reject, which blocks mail that fails authentication. Start at p=none only briefly to review reports and confirm your legitimate senders pass, then move to p=quarantine and finally p=reject with SPF and DKIM aligned to your From domain.

Email authentication locks your exact domain; a lookalike scan covers the rest. Run a free check with our free typosquat checker to see which lookalikes of your domain already exist.