All Servers & Email 10% Off!limitsiz10
Security

SPF, DKIM and DMARC Explained: Keep Your Email Out of Spam

What SPF, DKIM and DMARC are and how to set them up: sample DNS TXT records, a step-by-step DMARC rollout, test commands and the mistakes that send email to spam.

Limitsiz Bulut TeamInfrastructure and systems engineers Published Updated: 12 min read

You sent a quote, and your customer says it never arrived. After some digging, it turns up in their spam folder. The most common reason for this is missing or misconfigured email authentication records on your domain. Receiving servers ask every incoming message, "did this really come from this domain?", and look for the answer in DNS. The three core mechanisms that provide that answer are SPF, DKIM and DMARC.

This guide explains what each record does, how to configure them with sample DNS TXT records, how to tighten your DMARC policy safely, and how to test everything after setup.

Quick summary: SPF lists the servers allowed to send email on behalf of your domain. DKIM adds a cryptographic signature to each message, proving the content was not altered in transit. DMARC ties SPF and DKIM results to the visible "From" address, tells receivers what to do with messages that fail, and sends you reports. Used together, they improve deliverability and protect your domain from being spoofed.

Why it matters

When the email protocol (SMTP) was first designed, it had no way to verify the sender's identity. Anyone could put any address in the "From" field. Most phishing and fake invoice attacks still exploit that gap. SPF, DKIM and DMARC are the standards developed to close it.

Since 2024, major mailbox providers have started requiring SPF, DKIM and DMARC, especially from high-volume senders. Even for small businesses sending modest volumes, these records are now the de facto standard: without them, your messages may be marked as spam or rejected outright.

MechanismQuestion it answersDNS locationStandard
SPFIs this server authorized to send for this domain?example.com TXTRFC 7208
DKIMWas the message signed by the domain owner and left unaltered?selector._domainkey.example.com TXTRFC 6376
DMARCDo SPF/DKIM results align with the From domain, and what if they fail?_dmarc.example.com TXTRFC 7489

What SPF is and how to write it

SPF (Sender Policy Framework) is a TXT record added at the root of your domain. The receiving server checks whether the sending IP address is on that list. Below is a sample SPF record for a company that uses its own mail server plus an email service. The domain example.com, the IP address and the include value are placeholders; use the values your provider gives you in its panel.

example.com.   3600  IN  TXT  "v=spf1 mx ip4:203.0.113.25 include:_spf.provider.example ~all"

SPF mechanisms

MechanismMeaning
v=spf1Marks the record as SPF version 1; it must always come first.
mxAuthorizes the servers listed in the domain's MX records.
aAuthorizes the IP in the domain's A/AAAA record.
ip4: / ip6:Authorizes a specific IP address or range.
include:Pulls in another domain's SPF record (e.g. an email or newsletter provider).
~all"Softfail" for anything not listed: mark as suspicious.
-all"Fail" for anything not listed: reject.

Things to watch when writing SPF

  • One record only: A domain can have only one SPF record. Two separate v=spf1 records cause a "permerror". When you add a new service, add an include to the existing record.
  • The 10-lookup limit: include, a, mx, exists and redirect each count as a DNS lookup, and nested includes count too. Go over 10 and SPF becomes invalid.
  • List every sending source: If your website contact form, CRM, invoicing system or newsletter tool sends mail on your behalf, each must be in SPF.
  • Never use +all: It lets the whole internet send as you and makes SPF meaningless.
Common mistake: If your website runs on a VPS while email runs on a separate service, and the contact form sends directly from the server, forgetting to add the VPS IP to SPF sends every form message to spam. A better fix is to have the form send through your business email account using authenticated SMTP.

What DKIM is and how it works

DKIM (DomainKeys Identified Mail) means the sending server adds a digital signature to every outgoing message using a private key. The matching public key is published in DNS. The receiving server reads the selector and domain from the DKIM-Signature header, fetches the public key from DNS and verifies the signature. If it is valid, the message was not altered in transit and really did leave an authorized server for that domain.

A sample DKIM record looks like this (key shortened):

mail2026._domainkey.example.com.  3600  IN  TXT  (
  "v=DKIM1; k=rsa; "
  "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu3X...shortened..."
  "...QIDAQAB" )

Practical DKIM tips

  • Key length: A 2048-bit RSA key is today's recommended size; 1024 bits is now considered weak.
  • 255-character limit: A single TXT string in DNS can be at most 255 characters. 2048-bit keys are split into several quoted chunks as above; most DNS panels do this automatically.
  • Selector naming: Date-based selectors such as mail2026 make it easy to publish old and new keys side by side during rotation.
  • Sign every source: Your newsletter tool or CRM should also sign with your domain; otherwise DMARC alignment fails.

One major advantage of DKIM over SPF is that it usually survives forwarding. SPF checks the IP that delivered the message last, so it can fail on forwarded mail; a DKIM signature stays valid as long as the content is not changed.

What DMARC is: policy and reporting

DMARC (Domain-based Message Authentication, Reporting and Conformance) combines SPF and DKIM in a layer above them. It has two key jobs:

  1. Alignment: Passing SPF or DKIM is not enough on its own; the authenticated domain must match the domain in the "From" address the user sees. For DMARC to pass, at least one of SPF or DKIM must both pass and be aligned.
  2. Policy and reporting: It tells receivers what to do with failing messages (none, quarantine, reject) and asks them to send you aggregate reports.

A recommended DMARC record for the first phase:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; fo=1"

DMARC tags

TagExampleDescription
pnone / quarantine / rejectPolicy for the main domain: monitor only, send to spam, or reject.
sprejectSeparate policy for subdomains.
ruamailto:...Address that receives daily aggregate reports.
pct25Percentage of messages the policy applies to; used for gradual rollout.
adkim / aspfr / sAlignment mode: r (relaxed) accepts subdomains, s (strict) requires an exact match.
fo1Failure reporting option; 1 requests a report when either SPF or DKIM fails.

A safe, step-by-step DMARC rollout

Starting straight at p=reject can get every message from a forgotten sending source (say, your accounting software) rejected. We recommend a gradual approach:

  1. Weeks 1-2 – Monitor: Start with p=none and collect reports. Identify every IP and service sending as you.
  2. Weeks 3-4 – Fix: Add legitimate sources from the reports to SPF and enable DKIM signing for them.
  3. Weeks 5-6 – Partial quarantine: Use p=quarantine; pct=25 to send some failing messages to spam, then raise the percentage step by step.
  4. Week 7 onward – Full protection: Once reports show no legitimate failures, move to p=reject.
; Intermediate phase
_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]"

; Target policy
_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; sp=reject; adkim=r; aspf=r; rua=mailto:[email protected]"
Tip: DMARC aggregate reports arrive as XML and can be bulky. A dedicated mailbox for reports keeps your main mailboxes' quota free.

Setup checklist

  • MX records point to the correct mail server.
  • The domain has exactly one SPF record covering every legitimate sending source.
  • The SPF record stays under the 10-lookup limit.
  • DKIM signing is enabled and the public key is published in DNS.
  • A DMARC record is published at _dmarc and the report address works.
  • The sending server's reverse DNS (PTR) record matches its hostname.
  • Web forms and applications send via authenticated SMTP.

How to test your records

DNS changes can take anywhere from a few minutes to a few hours to propagate, depending on TTL. After that, you can query the records from a terminal:

# SPF
dig +short TXT example.com

# DKIM (replace the selector with your own)
dig +short TXT mail2026._domainkey.example.com

# DMARC
dig +short TXT _dmarc.example.com

# On Windows
nslookup -type=TXT _dmarc.example.com

The most reliable test is sending a real message. Send one to an address you own at a different provider and open the headers with "show original" or "view source". The Authentication-Results line should show all three passing:

Authentication-Results: mx.receiver.example;
  spf=pass smtp.mailfrom=example.com;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

Still landing in spam with correct records?

SPF, DKIM and DMARC are necessary but not sufficient on their own. If your records are correct and the problem persists, check the following:

  • IP reputation: The sending IP may be on a blocklist (RBL). If you send from a shared server, another user's behavior can affect you.
  • Content: Image-only messages, shortened links and aggressive sales wording can trigger filters.
  • Bulk sending: Sending to hundreds of recipients at once from a business mailbox quickly damages your reputation. Use suitable infrastructure for bulk sending.
  • New domain: Newly registered domains have no reputation yet; ramp up volume gradually.

With Limitsiz Bulut business email, incoming messages pass through SPF, reverse DNS, RBL and self-learning (Bayesian) filters, and on the outgoing side our support team helps you create correct SPF, DKIM and DMARC records. If you need bulk sending, take a look at our Business Mail Server plans.

Going further: MTA-STS and BIMI

Once the core trio is in place, two additional standards are worth considering. MTA-STS enforces TLS encryption for server-to-server email delivery; because its policy file is served over HTTPS, you need a valid certificate on the subdomain (for example, DV SSL). BIMI lets domains with a DMARC policy of quarantine or reject display their brand logo in supporting email clients.

Conclusion

SPF, DKIM and DMARC are the core security layers that get your email delivered and protect your domain from spoofing. Setting them up takes only a few DNS records, but they need to be added in the right order and tested. If you do not have a domain yet, start with domain search; for the fundamentals, read What is business email?, and for plan options see our Business email pricing 2026 guide.

Frequently asked questions

What people ask most about this topic

Technically none of them is mandatory, but major mailbox providers check them more strictly every year. For good deliverability, we recommend setting up all three.

Found this guide useful? Share it:
Recommended solution

Business Email

Reliable, spam-filtered email on your own domain with high deliverability.

  • DDoS-protected infrastructure
  • 24/7 expert support
Back to all blog posts
Blog

You might also like

All posts