SPF DKIM DMARC Explained: A Practical Email Authentication Guide
Understand SPF DKIM DMARC explained for email marketing, compare each protocol, publish the right DNS records, and verify your sender authentication.
In this guide
SPF, DKIM, and DMARC are the three DNS-based standards that let receiving mail servers confirm an email really came from the domain it claims to represent. SPF authorizes sending servers, DKIM cryptographically signs messages, and DMARC tells inbox providers what to do when a message fails either check. Together they protect your domain from spoofing and directly influence whether your emails land in the inbox or the spam folder.
If you send any volume of email, from product updates to transactional receipts, you have probably run into these three acronyms without a clear explanation of what they actually do. This guide has spf dkim dmarc explained in plain terms, with the mechanics, the setup steps, and the mistakes that quietly break deliverability for SaaS teams, developers, and info-product creators who manage their own sending domain.
What Are SPF, DKIM, and DMARC?
SPF, DKIM, and DMARC are DNS records published on your sending domain. Each one answers a different question that a receiving mail server asks before deciding whether to deliver, flag, or reject a message. None of them encrypts your email content: they exist purely to prove ownership and integrity of the sending identity.
SPF (Sender Policy Framework)
SPF is a published list of the mail servers and IP addresses allowed to send email on behalf of your domain. When a receiving server gets a message, it checks the "envelope from" address against your domain's SPF record. If the sending IP is not on that list, the message fails SPF. This is the simplest of the three protocols, but it has a known weakness: SPF checks break when a message is forwarded, because the forwarding server's IP is rarely on the original domain's approved list.
DKIM (DomainKeys Identified Mail)
DKIM adds a cryptographic signature to each outgoing message, generated with a private key held by the sending platform. The matching public key is published in your DNS as a TXT record tied to a "selector." The receiving server retrieves that public key and verifies the signature. If anything in the signed content changed in transit, or if the signature does not match, the message fails DKIM. Unlike SPF, DKIM survives most forwarding scenarios because the signature travels with the message itself.
DMARC (Domain-based Message Authentication, Reporting, and Conformance)
DMARC sits on top of SPF and DKIM. It does not perform its own identity check; instead, it tells receiving servers what policy to apply when a message fails SPF, fails DKIM, or fails both, and it requests reports back to the domain owner. A DMARC record specifies one of three policies: monitor only, quarantine, or reject. Without a DMARC record, mailbox providers fall back to their own judgment on how to treat failures, which is inconsistent and gives you no visibility.
| Protocol | What it checks | Where it lives | What a failure looks like |
|---|---|---|---|
| SPF | Is this server authorized to send for this domain? | TXT record on the root domain | Message rejected or sent to spam |
| DKIM | Was this message signed by the real domain and left unaltered? | TXT record on a selector subdomain | Message spam-foldered, trust signals weakened |
| DMARC | What should happen when SPF or DKIM fails? | TXT record on _dmarc subdomain | Inconsistent handling, no reporting data |
Each record on its own only solves part of the problem. That is exactly why mailbox providers and email marketing software now expect all three to be configured together.
How SPF, DKIM, and DMARC Work Together
The three protocols are not interchangeable; they are layered. SPF and DKIM each verify authenticity independently, and DMARC links them to the domain visible in the "From" header through a process called alignment.
Why alignment matters
A message can technically pass SPF or DKIM while still using a domain in the visible "From" field that does not match the authenticated domain. DMARC closes this gap by requiring that at least one of SPF or DKIM not only passes, but also "aligns" with the domain the recipient actually sees. Without alignment, a bad actor could pass SPF using their own domain while spoofing your brand name in the display field. DMARC alignment is what turns two separate technical checks into a real anti-spoofing defense.
What happens when a message fails
If a message fails SPF and DKIM, or passes them without alignment, the receiving server consults your DMARC policy:
- Monitor (p=none): the message is delivered as usual, but a report is generated. This is the recommended starting policy while you confirm all legitimate senders are properly authenticated.
- Quarantine (p=quarantine): the message is typically routed to spam or a junk folder.
- Reject (p=reject): the message is blocked outright before it reaches the inbox.
Moving from monitor to quarantine to reject should be gradual. Jumping straight to reject before you have confirmed every legitimate sending source (marketing platform, transactional API, support tool, invoicing system) is authenticated will silently drop real email, including password resets and invoices your own customers are waiting for.
How to Set Up SPF, DKIM, and DMARC
Setting up authentication is a DNS task, not a code change, which means anyone with access to your domain's DNS provider can do it. The sequence matters: publish SPF and DKIM first, confirm they are working, then layer DMARC on top.
Step 1: Audit your sending sources
Before touching DNS, list every system that sends email using your domain: your email marketing or transactional platform, your CRM, your support desk, your invoicing tool, and any internal scripts. Each one needs to be included in your SPF record and signed with its own DKIM selector. This is the step most teams skip, and it is the most common cause of authentication failures after setup.
Step 2: Publish your SPF record
Create a single TXT record on your root domain listing the mail servers you authorized in Step 1. SPF records have a lookup limit, so consolidating sources and avoiding unnecessary includes keeps the record valid. Once published, DNS propagation can take a few hours, so verify before assuming it is live. A SPF record checker is the fastest way to confirm your domain is authorizing exactly the sending servers you intended, and nothing else.
Step 3: Publish your DKIM record
Your sending platform generates a public/private key pair and gives you a selector value and a TXT record to publish. If you send through more than one platform (for example, campaigns through one tool and transactional email through an SMTP relay or API), each source needs its own selector and key pair. After publishing, use a DKIM record checker to confirm the selector resolves and the public key matches what your sending platform expects. A mismatch here is a frequent, invisible cause of spam placement.
Step 4: Publish your DMARC policy and monitor
Start with a monitor-only DMARC record (p=none) pointed at a reporting address you control. This generates aggregate reports showing every source sending on your behalf and whether each one passes alignment, without affecting delivery. Review those reports for at least a few weeks, fix any unauthenticated sources, then move to quarantine and eventually reject once you are confident no legitimate mail is misclassified. A DMARC record checker helps confirm your policy syntax is valid before you tighten enforcement.
For teams running their own infrastructure, this setup process is usually a one-time task per sending domain, repeated whenever a new subdomain or sending tool is introduced. If you send transactional email through SMTP or an API, as with Lumail's TypeScript SDK and REST API, the same SPF and DKIM records need to cover that sending path too, since transactional and marketing traffic are both judged under the same domain reputation.
| Order | Action | Verification method |
|---|---|---|
| 1 | List every sending source using your domain | Internal audit of platforms and tools |
| 2 | Publish SPF record with all approved servers | SPF record checker |
| 3 | Publish DKIM selector(s) and public key(s) | DKIM record checker |
| 4 | Publish DMARC at monitor policy, then tighten | DMARC record checker and aggregate reports |
| 5 | Send a real email and confirm all three pass and align | Mail tester |
Common Authentication Mistakes to Avoid
Most authentication failures are not caused by missing records; they are caused by records that exist but are incomplete, outdated, or misaligned with how the domain actually sends email.
- Publishing SPF but forgetting a sending source. Every time you add a new tool that sends on your domain's behalf (a new CRM, a new transactional API, a new marketing platform), it needs to be added to the SPF record or it will fail outright.
- Exceeding the SPF lookup limit. SPF records that chain too many "include" statements across multiple vendors can silently stop resolving, which breaks authentication for everyone listed, not just the newest addition.
- Reusing one DKIM selector across unrelated platforms. Each sending source should have its own selector and key pair. Sharing one invites key rotation conflicts and makes it harder to isolate problems.
- Jumping straight to a DMARC reject policy. Enforcing
p=rejectbefore confirming every legitimate source passes alignment will block real mail, including transactional messages your customers depend on. - Ignoring DMARC aggregate reports. A monitor-only policy is only useful if someone actually reviews the reports it generates. Without that review, misconfigurations go unnoticed for months.
- Mismatched "From" and envelope domains. If your visible "From" address uses a different domain than your authenticated sending domain, DMARC alignment fails even when SPF and DKIM individually pass. A mail tester shows alignment the way the receiving server sees it.
- Treating authentication as a one-time setup. Adding a new subdomain, switching email providers, or launching a new product line without updating SPF, DKIM, and DMARC records recreates the exact gaps you fixed the first time.
Email authentication is not a single setting you configure once and forget. It is an ongoing part of domain hygiene, especially as your sending infrastructure grows to include marketing campaigns, automated workflows, and transactional messages triggered by code or AI agents. Keeping SPF, DKIM, and DMARC records accurate as your sending sources change is what keeps your domain's reputation intact and your email landing where it is supposed to: in the inbox.
Frequently asked questions
Why is passing SPF or DKIM alone not enough?
Passing one authentication check does not prove that the visible From address is authorized. SPF authenticates the sending server, while DKIM authenticates a signed message. DMARC adds alignment, requiring SPF or DKIM to match the domain shown to recipients. If neither authenticated method aligns, DMARC can treat the message as unauthenticated, even when SPF or DKIM independently passes.
Does email authentication guarantee inbox placement?
No. SPF, DKIM, and DMARC help receiving providers verify that messages are authorized and reduce spoofing, but they cannot guarantee inbox placement. Filtering decisions may also consider content, recipient engagement, sending reputation, complaint rates, list quality, and technical delivery issues. Authentication is an important foundation for trustworthy sending, not a promise that every message will avoid spam folders.
Do transactional and marketing emails need separate SPF, DKIM, and DMARC records?
They may use different sending services or subdomains, but they still need a coordinated authentication design. A domain generally publishes one SPF record, so multiple providers must be combined correctly rather than adding separate SPF records. Each service may require its own DKIM selector. DMARC can apply to the organizational domain while allowing subdomains to use separate policies when different email streams need different controls.
How often should you check SPF, DKIM, and DMARC?
Check authentication regularly and whenever you add, remove, or change an email provider, platform, subdomain, or sending configuration. Review DMARC reports for unauthorized sources, SPF failures, DKIM failures, and alignment problems. Routine monitoring helps identify forgotten services and DNS changes before they affect delivery. The appropriate review frequency depends on how often your organization changes its email infrastructure and how much mail it sends.
What is DMARC alignment, and why does it matter?
DMARC alignment connects authentication results with the domain recipients see in the From address. SPF alignment compares the visible From domain with the domain used for the SMTP envelope sender. DKIM alignment compares it with the domain in the DKIM signature. At least one aligned method must pass for DMARC authentication to pass, which helps prevent unauthorized senders from impersonating your domain.
Can one domain use more than one DKIM record?
Yes. A domain can publish multiple DKIM public keys by using different selectors, which are included in the DKIM-Signature header. This allows several email providers or systems to authenticate messages without overwriting one another's keys. Each provider must use a unique selector and publish the corresponding DNS record. Removing a key should be done only after confirming that no active mail stream still depends on it.
What should you do if DMARC reports show an unauthorized sender?
First, identify the source, sending service, envelope domain, DKIM signing domain, and authentication results in the report. The source may be a legitimate provider that has not been documented, a misconfigured internal system, or an actual spoofing attempt. Do not immediately reject every failure without investigation. Update authorized sending systems and DNS records when appropriate, then use DMARC monitoring to confirm that alignment and policy behavior are correct.