What Is DMARC? SPF, DKIM and Email Authentication
What DMARC is, how SPF and DKIM support it, and the concepts behind email trust — before you publish a step-by-step DMARC policy.
DMARC is the DNS policy that tells receiving mail servers what to do when mail claiming to be from your domain fails authentication — and it is what actually stops impersonation. If your invoices land in spam, your password resets never arrive, or scammers send phishing emails that appear to come from you, the cause is almost always missing or misconfigured SPF, DKIM and DMARC. Here is what each record does and how they work together.
SPF: who is allowed to send
Sender Policy Framework (SPF) is a DNS record that lists the servers permitted to send email on behalf of your domain. When a receiving server gets a message claiming to be from you, it checks whether the sending server appears on your list. If not, the mail is suspicious.
v=spf1 include:_spf.google.com include:sendgrid.net -all
The -all at the end means 'reject anything not listed' — the strict, correct setting once you are confident every legitimate sender is included. A common mistake is using ~all (soft fail) forever, or exceeding the limit of ten DNS lookups, which silently breaks the record.
DKIM: proof the message was not tampered with
DomainKeys Identified Mail (DKIM) adds a cryptographic signature to every outgoing message. Your mail provider signs the email with a private key, and the matching public key lives in your DNS. The receiving server verifies the signature, proving two things: the mail genuinely came from your domain, and nobody altered it in transit.
SPF checks where the mail came from; DKIM checks that the content is authentic and unmodified. You want both — DMARC then ties them together.
DMARC: the policy that makes it all enforceable
Domain-based Message Authentication, Reporting and Conformance (DMARC) is the record that tells receiving servers what to do when SPF or DKIM fails, and asks them to send you reports. It is what actually stops impersonation.
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100
- `p=none` — monitor only. Start here to collect reports without affecting delivery.
- `p=quarantine` — send failing mail to spam. Move here once your reports look clean.
- `p=reject` — refuse failing mail outright. The end goal, and the only setting that fully blocks impersonation.
The rollout that does not break your email
- 1Publish SPF listing every legitimate sender, ending in
-all. - 2Enable DKIM in your mail provider and add the public key to DNS.
- 3Publish DMARC at `p=none` and read the reports for a few weeks.
- 4Once reports are clean, move DMARC to `p=quarantine`, then finally `p=reject`.
A DNS health scan reports whether SPF, DKIM and DMARC exist and whether their values are valid — so you find the gap before your customers find your email in their spam folder. Start with the DMARC checker when you only need that policy verified.
Email authentication is one of those tasks that feels obscure until the day it costs you a signed contract or a reset password that never arrived. Set the three records in order, watch the DMARC reports, and tighten the policy as your confidence grows. For the focused rollout from p=none to p=reject, follow our DMARC setup step-by-step. Done right, your mail gets delivered and nobody can pretend to be you.
