How to set up DMARC, DKIM, and SPF for your domain

If your domain doesn't have SPF, DKIM, and DMARC configured, your emails are already landing in spam. Or worse, someone else is sending email as you.

Google and Yahoo made bulk sender authentication mandatory in February 2024. Since then, the requirements have only gotten stricter. As of early 2026, domains without proper authentication face rejection outright — not just spam folder placement, but hard bounces. Microsoft followed with similar enforcement across Outlook and Hotmail domains.

This isn't optional anymore. Here's how to set up all three records correctly.

What these three records actually do

SPF, DKIM, and DMARC are DNS-based authentication mechanisms. Each does something different:

• SPF tells receiving mail servers which IP addresses are allowed to send email for your domain.
• DKIM attaches a cryptographic signature to every outgoing email, proving it wasn't tampered with in transit.
• DMARC ties SPF and DKIM together with a policy that tells receivers what to do when authentication fails.

They work as a system. SPF alone won't save you. DKIM alone won't either. You need all three.

SPF: authorize your senders

SPF (Sender Policy Framework) is a TXT record on your domain that lists every server permitted to send mail on your behalf.

The DNS record

Add a TXT record on your root domain (yourdomain.com):

v=spf1 include:sendkit.dev include:_spf.google.com ~all

Breaking this down:

• v=spf1 — declares this is an SPF record.
• include:sendkit.dev — authorizes Sendkit's mail servers.
• include:_spf.google.com — authorizes Google Workspace (if you use it).
• ~all — soft-fail anything not listed. Use -all for a hard fail once you're confident in your setup.

The 10 lookup limit

SPF has a hard limit of 10 DNS lookups. Every include:, a:, mx:, and redirect= mechanism counts as a lookup. Nested includes count too — if include:sendkit.dev itself references two other domains, that's three lookups total.

Exceed 10 and your entire SPF record becomes invalid. Receivers treat it as if you have no SPF at all.

This bites teams that use multiple SaaS tools for email. Your transactional provider, your marketing tool, your helpdesk, your CRM — each one adds include: directives. It adds up fast.

How to stay under the limit:

• Audit your SPF record quarterly. Remove services you no longer use.
• Use ip4: and ip6: for static IPs instead of include: — IP mechanisms don't count toward the lookup limit.
• Consider SPF flattening tools if you genuinely need more than 10 services (though this introduces its own maintenance burden).

Common SPF mistakes

Multiple SPF records. You can only have one SPF TXT record per domain. If you add a second one, both are invalid. Merge them into a single record.

Using +all. This tells receivers that literally anyone can send as your domain. Never do this.

Forgetting subdomains. SPF records don't inherit. If you send from mail.yourdomain.com, it needs its own SPF record.

DKIM: sign your emails

DKIM (DomainKeys Identified Mail) uses public-key cryptography. Your sending server signs each outgoing message with a private key. The receiving server looks up the public key in your DNS and verifies the signature.

If the signature checks out, the receiver knows the email genuinely came from your infrastructure and wasn't modified after sending.

The DNS record

DKIM records are TXT records published at a specific subdomain:

selector._domainkey.yourdomain.com

The selector is a label chosen by your email provider. It lets you have multiple DKIM keys for different services. A typical record looks like this:

Host: sendkit._domainkey.yourdomain.com
Type: TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2pmMpTj...

The p= value is your public key, base64-encoded. It will be long — often 400+ characters for a 2048-bit key.

Key size matters

Use 2048-bit keys minimum. Some older guides still reference 1024-bit keys, but those are considered weak by current standards and some receivers are starting to flag them. Most providers, Sendkit included, generate 2048-bit keys by default.

How Sendkit handles DKIM

When you add a domain in Sendkit, it generates a unique DKIM key pair for you. You'll get a CNAME record to add to your DNS — Sendkit hosts the public key, so key rotation happens automatically without you touching DNS again.

The CNAME approach looks like:

Host: sendkit._domainkey.yourdomain.com
Type: CNAME
Value: sendkit._domainkey.sendkit.dev

This is cleaner than pasting raw public keys into TXT records and means Sendkit can rotate keys on a schedule without breaking your setup.

Common DKIM mistakes

Line breaks in the TXT record. Some DNS providers don't handle long TXT values well. If your DKIM record isn't validating, check whether your provider split the value into multiple strings incorrectly.

Wrong selector. Each provider uses a different selector. Make sure you're publishing the key at the exact subdomain your provider specifies.

Not signing all outbound mail. If you have multiple sending services and only one has DKIM configured, unsigned messages will fail DMARC alignment (more on that next).

DMARC: set your policy

DMARC (Domain-based Message Authentication, Reporting & Conformance) does two things: it tells receivers how to handle messages that fail SPF and DKIM checks, and it sends you reports about authentication results.

The DNS record

Add a TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:[email protected]

The key parameters:

• v=DMARC1 — protocol version.
• p= — the policy. What should receivers do with failing messages?
• rua= — where to send aggregate reports (XML files with authentication stats).

Policy levels

DMARC has three policy levels. Start permissive and tighten over time:

p=none — Monitor only. Failing messages still get delivered normally. You receive reports showing what's passing and failing. Start here.

p=quarantine — Failing messages go to spam. Move to this once your reports show legitimate mail is passing consistently.

p=reject — Failing messages get bounced outright. This is the goal. It prevents anyone from spoofing your domain.

A realistic rollout timeline:

1. Deploy p=none and monitor reports for 2-4 weeks.
2. Review reports. Fix any legitimate senders that aren't aligned.
3. Move to p=quarantine for another 2-4 weeks.
4. Once clean, switch to p=reject.

DMARC alignment

Here's the part most people miss. DMARC doesn't just check that SPF and DKIM pass — it checks alignment. The domain in the From: header must match the domain that passed SPF or DKIM.

If your From: address is [email protected] but SPF passes for bounce.sendkit.dev, that's an SPF pass but a DMARC alignment failure. You need either SPF or DKIM (or both) to align with the From: domain for DMARC to pass.

This is exactly why DKIM matters so much for transactional email providers. Sendkit signs messages with your domain's DKIM key, so DKIM alignment passes even when the envelope sender differs.

A more complete DMARC record

Once you're past the monitoring phase:

v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=s; aspf=s; pct=100

• ruf= — forensic reports (per-message failure details). Not all providers send these.
• adkim=s — strict DKIM alignment (exact domain match, no subdomains).
• aspf=s — strict SPF alignment.
• pct=100 — apply the policy to 100% of messages. You can ramp this up gradually, e.g., pct=25 to start.

Verify your setup

Don't trust that your DNS changes propagated correctly. Verify.

Using dig

Check SPF:

dig +short TXT yourdomain.com | grep spf

Check DKIM (replace sendkit with your selector):

dig +short TXT sendkit._domainkey.yourdomain.com

Check DMARC:

dig +short TXT _dmarc.yourdomain.com

Using nslookup (Windows)

nslookup -type=TXT yourdomain.com
nslookup -type=TXT sendkit._domainkey.yourdomain.com
nslookup -type=TXT _dmarc.yourdomain.com

Online tools

A few free tools worth bookmarking:

• MXToolbox (mxtoolbox.com/SuperTool) — checks SPF, DKIM, and DMARC in one shot.
• Google Admin Toolbox (toolbox.googleapps.com/apps/checkmx) — good for verifying Google-specific config.
• Mail Tester (mail-tester.com) — send a test email and get a deliverability score with specific authentication results.

Send a real test email after configuring everything. Check the raw headers in the received message — look for Authentication-Results headers showing spf=pass, dkim=pass, and dmarc=pass.

Common mistakes and how to fix them

SPF record exceeds the 10 lookup limit. Run your SPF through a lookup counter (MXToolbox does this). Remove unused includes. Flatten if necessary.

DKIM record not found. Double-check the selector name and the exact subdomain. DNS propagation can take up to 48 hours, but most changes appear within minutes. Also verify your DNS provider isn't silently truncating long TXT values.

DMARC reports going to a different domain. If your rua address is on a different domain than the one publishing the DMARC record, the receiving domain needs a special DNS record to authorize it: yourdomain.com._report._dmarc.reportdomain.com TXT "v=DMARC1".

Subdomain mail failing DMARC. DMARC policies apply to subdomains via the sp= tag. If you don't set it, subdomains inherit the parent's policy. If you send from notifications.yourdomain.com, make sure it has its own SPF and DKIM or that your DMARC record accounts for it.

Using p=reject too early. You will block legitimate email. Always start with p=none, read the reports, fix alignment issues, then escalate. Skipping the monitoring phase is the single most common cause of self-inflicted deliverability damage.

Forgetting to authenticate all senders. Audit every service that sends email as your domain. Marketing platforms, helpdesk tools, billing systems, monitoring alerts — every one needs to be covered by SPF and ideally DKIM-signing with your domain.

Wrapping up

Getting SPF, DKIM, and DMARC right is a one-time setup that pays off permanently. Your emails land in inboxes instead of spam. Nobody can spoof your domain. And you meet the authentication requirements that major providers now enforce.

The order matters: set up SPF first, then DKIM, then DMARC in monitor mode. Give yourself a few weeks of report data before tightening the DMARC policy. Rushing to p=reject without that data is asking for trouble.

If you're using Sendkit for transactional email, most of the heavy lifting is handled for you — DKIM keys are generated and rotated automatically, and the DNS records you need are provided in the dashboard. You just need to add them to your DNS and verify.