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.
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.
| Mechanism | Question it answers | DNS location | Standard |
|---|---|---|---|
| SPF | Is this server authorized to send for this domain? | example.com TXT | RFC 7208 |
| DKIM | Was the message signed by the domain owner and left unaltered? | selector._domainkey.example.com TXT | RFC 6376 |
| DMARC | Do SPF/DKIM results align with the From domain, and what if they fail? | _dmarc.example.com TXT | RFC 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
| Mechanism | Meaning |
|---|---|
v=spf1 | Marks the record as SPF version 1; it must always come first. |
mx | Authorizes the servers listed in the domain's MX records. |
a | Authorizes 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=spf1records cause a "permerror". When you add a new service, add anincludeto the existing record. - The 10-lookup limit:
include,a,mx,existsandredirecteach 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.
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
mail2026make 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:
- 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.
- 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
| Tag | Example | Description |
|---|---|---|
p | none / quarantine / reject | Policy for the main domain: monitor only, send to spam, or reject. |
sp | reject | Separate policy for subdomains. |
rua | mailto:... | Address that receives daily aggregate reports. |
pct | 25 | Percentage of messages the policy applies to; used for gradual rollout. |
adkim / aspf | r / s | Alignment mode: r (relaxed) accepts subdomains, s (strict) requires an exact match. |
fo | 1 | Failure 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:
- Weeks 1-2 – Monitor: Start with
p=noneand collect reports. Identify every IP and service sending as you. - Weeks 3-4 – Fix: Add legitimate sources from the reports to SPF and enable DKIM signing for them.
- Weeks 5-6 – Partial quarantine: Use
p=quarantine; pct=25to send some failing messages to spam, then raise the percentage step by step. - 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]"
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
_dmarcand 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.