SPF, DKIM and DMARC: How to Check Your Domain's Email Security

A quick SPF, DKIM and DMARC check on your domain tells you in seconds whether attackers can forge email in your name and why your legitimate messages keep vanishing into spam. It all comes down to three TXT records published in DNS. A domain without them is trivially spoofable. A domain with them misconfigured is almost as bad, because the records authenticate nothing while your real mail still gets filtered. This post explains what each record does, what a passing posture looks like, and how to run a free email security check on any domain.

Why an SPF, DKIM and DMARC Check Matters

Email was designed in the 1970s without any authentication. SMTP has no built-in way to prove who sent a message, so anyone can connect and claim to be anyone. Attackers abuse this constantly: they send phishing from your domain, forge invoices, and burn your brand. Gmail, Outlook and Yahoo began enforcing DMARC in 2024, which means a large share of mail that fails authentication is now rejected outright by default.

There is also a cost to legitimate senders. Every major mailbox provider runs a filtering pass that scores unauthenticated mail as suspicious. Newsletters, receipts and notifications from a domain with broken records end up in spam. A proper SPF, DKIM and DMARC check is therefore not just anti-phishing hygiene; it is deliverability maintenance.

How SPF Works

Sender Policy Framework (SPF) publishes a list of servers allowed to send mail for your domain, in a TXT record. Receivers look it up at the envelope address, not the From header, and compare the connecting server’s IP against the list:

v=spf1 ip4:203.0.113.10 include:_spf.google.com -all

The mechanisms say “allow 203.0.113.10, include Google’s published list, and reject everything else” (-all is the hard fail). SPF passes when the sending IP is authorized. But SPF has a well-known hole: it only checks the envelope, so an attacker who gets around the envelope can still spoof the visible From address. That is why SPF alone is never enough.

How DKIM Works

DomainKeys Identified Mail (DKIM) attaches an asymmetric signature to each message. The sending server signs the body and selected headers with a private key and publishes the matching public key in DNS at a selector record like default._domainkey.example.com. The receiving server fetches the key and verifies the signature, proving the message was not altered in transit and that it passed through a server holding the private key:

default._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GN..."

The signature survives forwarding, which SPF does not, which is why DKIM is often the record that rescues legitimate mail from spam filters.

How DMARC Ties Them Together

Domain-based Message Authentication, Reporting and Conformance (DMARC) tells receivers what to do when SPF and DKIM both fail, and it lives at _dmarc.example.com:

_dmarc.example.com TXT "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@example.com"

The real power of DMARC is alignment. For mail to pass, either SPF or DKIM must pass AND the domain in the envelope or signature must match your domain. That closes the SPF envelope gap. A domain publishing p=reject with a matching signature effectively cannot be spoofed, because every validating receiver drops mail that does not authenticate.

Alignment also catches a trap that SPF alone cannot: a third-party service sending on your behalf may pass SPF against its own domain while your domain appears in the From header. DMARC alignment forces that service to either sign with your domain key or use a subdomain you explicitly permit, so the address the recipient sees is the address that was verified.

What a Good Email Security Check Should Tell You

A well-designed email security check reports three things: whether each record exists and parses, whether the DMARC policy is actually enforced (quarantine or reject rather than none), and whether the SPF and DKIM mechanisms are syntactically valid. The SPF/DKIM/DMARC generator pairs with the check when you need to build corrected records from scratch. Re-run the check after you change mail providers or add a sending service, since an include: mechanism that stops resolving quietly breaks the entire record.

Next step: run a free email security check on your domain and close whatever it finds, starting with a DMARC none policy you can watch via reports before tightening to reject.

More posts →