SPF, DKIM, and DMARC: What They Are and How to Configure Them Correctly

Why These Three Records Define Your Email Reputation

Every email your company sends is evaluated by the receiving mail server before it reaches the inbox — or the spam folder — or nowhere at all. That evaluation is largely based on three DNS records: SPF, DKIM, and DMARC.

These are not optional for businesses that send email at any meaningful volume. Without them, your domain has no authentication credentials. Mail servers treat unauthenticated email with significant suspicion. Google, Microsoft, and Yahoo have all formalized requirements for authenticated email as a condition of inbox delivery for bulk senders.

Setting them up incorrectly is nearly as damaging as not having them at all. Misconfigured SPF causes legitimate mail to fail authentication. A DMARC policy at p=none provides no protection against spoofing. This guide covers each record correctly so you can configure them once and trust them indefinitely.

SPF: Sender Policy Framework

SPF specifies which mail servers are authorized to send email on behalf of your domain. When a receiving server gets email from your domain, it checks your SPF record to verify that the sending server is on your approved list.

The DNS record format:

Your SPF record is a TXT record published at your root domain (or subdomain if you are authenticating a subdomain).

A basic SPF record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Breaking this down: v=spf1 identifies the record as SPF version 1. include: directives authorize the IP ranges belonging to the listed services. The ~all at the end is a softfail — mail from unauthorized senders is marked suspicious but not rejected outright.

The softfail vs. hardfail decision:

Using -all (hardfail) instead of ~all (softfail) instructs receiving servers to reject mail from unauthorized senders. This is more secure but also more dangerous if your SPF record is incomplete and legitimate sending sources are missing. Start with ~all and migrate to -all once you have confirmed all your sending sources are covered.

The critical SPF include count limit:

SPF records have a 10 DNS lookup limit. Every include: directive and ptr mechanism triggers a DNS lookup. Exceed 10 lookups and SPF evaluation fails — which means SPF fails — which damages deliverability. If you are using multiple ESPs (email service providers), CRM platforms that send email, marketing automation tools, and transactional email services, you can hit the limit quickly. Use SPF flattening tools to convert include: chains into flat IP lists when necessary.

Common SPF mistakes:

Multiple TXT records with v=spf1 at the same hostname — only one SPF record is permitted per hostname. Forgetting to add ESPs when you add a new email-sending service. Over-broad mechanisms like +all that authorize every server in the world. Listing IP addresses that no longer exist as active sending sources.

DKIM: DomainKeys Identified Mail

DKIM adds a cryptographic signature to outgoing messages. The signature is generated by your sending server using a private key. The corresponding public key is published in DNS. Receiving servers verify the signature against the public key, confirming the message has not been modified in transit and that it was authorized by the key holder.

The DNS record format:

DKIM records are TXT records published at a specific selector subdomain:

selector._domainkey.yourdomain.com

The record value contains your public key and looks like:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...

Selector management:

Each sending source (ESP, mail server) typically has its own DKIM selector and key pair. Google Workspace uses the selector "google". SendGrid generates a unique selector per customer. You can have multiple DKIM records at different selectors simultaneously — there is no limit equivalent to SPF's lookup constraint.

Key rotation:

Best practice is to rotate DKIM keys periodically (annually at minimum). Publish the new key at a new selector, update your ESP to use the new selector, verify the signature is valid, then remove the old key after a few weeks to allow cached DNS to expire.

Common DKIM mistakes:

Not enabling DKIM signing in the ESP (the DNS record alone does nothing — the sending server must actually sign outbound mail). Publishing the record at the wrong subdomain. Key truncation when copying the public key from the ESP dashboard.

DMARC: Domain-based Message Authentication, Reporting & Conformance

DMARC tells receiving servers what to do when SPF or DKIM checks fail, and it tells your domain what is happening with your email authentication globally by generating aggregate and forensic reports.

The DNS record format:

DMARC records are TXT records published at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; rua=mailto:dmarc-forensic@yourdomain.com; pct=100

The three policy levels:

p=none — Monitor mode. Authentication failures are reported but mail is not affected. This is where everyone should start. It allows you to observe your authentication landscape before enforcing.

p=quarantine — Failures are sent to the spam folder. Use this after reviewing reports and confirming all legitimate senders are authenticated.

p=reject — Failures are rejected outright. This is the target state for fully deployed DMARC and provides complete protection against domain spoofing and phishing using your domain.

DMARC alignment:

DMARC requires alignment between the authenticated domain (in SPF or DKIM) and the From header domain. If your From address is @yourdomain.com but your SPF is authenticating a subdomain, DMARC alignment may fail. Strict vs. relaxed alignment affects how precisely the domains must match.

Reading DMARC reports:

Aggregate reports (rua) arrive as XML files and are difficult to read manually. Use a DMARC report processing service such as Postmark, Valimail, or DMARC Analyzer to make the reports actionable. Look for unauthorized senders using your domain, legitimate senders that are failing authentication, and volume breakdowns by sending source.

The Implementation Order

1. Publish SPF in monitor mode (~all) and verify all sending sources are included

2. Enable DKIM signing for each sending source and publish the public key

3. Publish DMARC at p=none with a valid rua reporting address

4. Monitor reports for 2–4 weeks; fix any legitimate senders that are failing authentication

5. Move DMARC to p=quarantine; monitor for 2–4 weeks

6. Move DMARC to p=reject once reports confirm all legitimate mail is authenticated

Testing Tools

MXToolbox (mxtoolbox.com/SuperTool.aspx) — check SPF, DKIM, and DMARC record syntax. mail-tester.com — send a test message and receive a deliverability score with specific diagnosis. Google Postmaster Tools — track domain reputation and authentication performance for mail delivered to Gmail. DMARC Analyzer — process aggregate DMARC reports into actionable dashboards.

BIMI: The Next Step

Once DMARC is at p=quarantine or p=reject, you are eligible to publish a BIMI (Brand Indicators for Message Identification) record. BIMI attaches your brand logo to authenticated email in supported mail clients, providing a visible trust signal to recipients. It requires a Verified Mark Certificate (VMC) from a qualified authority and a DMARC policy of quarantine or reject.

Key Takeaways

• ▸SPF authorizes which servers can send from your domain — watch the 10 DNS lookup limit
• ▸DKIM signs outbound mail cryptographically — the DNS record does nothing without enabling signing in your ESP
• ▸DMARC specifies what to do with failures and provides reporting visibility — start at p=none, move to p=reject over 6–12 weeks
• ▸Implementation order: SPF → DKIM → DMARC p=none → DMARC p=quarantine → DMARC p=reject
• ▸Use MXToolbox and mail-tester.com to verify before moving to the next policy level
• ▸BIMI is the brand-visibility reward for fully deployed DMARC