SPF, DKIM and DMARC Explained: Why Your Emails Land in Spam

You send a quote and the customer says "your email never arrived". Later they find it in their spam folder. Most of the time the problem is not the content of the message but your domain's authentication settings. When the receiving server cannot be sure an email really came from you, it treats it as suspicious.

In this article we explain the three cornerstones of email authentication, SPF, DKIM and DMARC, without the jargon. You will learn what each one does, what its DNS record looks like and how to roll them out step by step.

Why Do Emails Land in Spam?

The email protocol was designed decades ago without any way to verify the sender. That is why anyone can send email in the name of any address. Fraudsters exploit this to send fake messages that appear to come from your domain.

To deal with this, big providers such as Gmail, Outlook and Yahoo check every incoming message: is this server allowed to send for this domain? Was the message changed in transit? What does the domain owner want done with messages that fail these checks? The answers to those three questions are SPF, DKIM and DMARC.

Authentication is not the only factor. The reputation of the sending IP, blocklists, content and how often recipients mark your messages as spam all play a part. But without correct SPF, DKIM and DMARC, deliverability stays weak even if everything else is right.

SPF: Who Can Send on My Behalf?

SPF (Sender Policy Framework) is a list of the servers allowed to send email for your domain. It is published as a TXT record in your domain's DNS. The receiving server checks whether the server that sent the message is on the list.

An example SPF record looks like this:

companyname.com TXT "v=spf1 mx include:spf.provider.com ip4:203.0.113.10 ~all"

• v=spf1: marks this as an SPF record.
• mx: the domain's MX servers may send.
• include: pulls in another provider's list, for example your email or newsletter service.
• ip4: allows a specific IP address, such as an application server in your office.
• ~all: means "treat anything not listed as suspicious". -all means "reject".

DKIM: Was This Message Changed in Transit?

DKIM (DomainKeys Identified Mail) adds a digital signature to every message you send. The signature is created with a private key stored on your mail server. The matching public key is published in DNS. The receiving server verifies the signature with the public key and knows the message really came from your server and was not altered on the way.

An example DKIM record:

mail2026._domainkey.companyname.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...long-public-key..."

• mail2026: the selector. It lets you use more than one key for the same domain.
• k=rsa: the key type.
• p=: the public key itself. Your email provider generates this value; you just add it to DNS.

DKIM also fixes a weakness of SPF: when a message passes through a forwarder, the sending server changes and the SPF check may fail, but the DKIM signature travels with the message and stays valid.

DMARC: What Happens When Checks Fail?

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy layer that ties SPF and DKIM together. It does two jobs:

• It tells receiving servers what to do with messages that fail authentication.
• It sends you reports showing who is sending email in your domain's name.

DMARC also checks alignment: the domain verified by SPF or DKIM must match the domain in the "From" address the recipient sees. That way nobody can pass SPF with a different domain and still impersonate your address.

An example DMARC record:

_dmarc.companyname.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@companyname.com"

DMARC policies

• p=none: monitor only. Nothing happens to failing messages, but reports arrive. This is the starting point.
• p=quarantine: failing messages go to the spam folder.
• p=reject: failing messages are refused outright. This is the strongest protection against your domain being spoofed.

Step-by-Step Rollout

1. Take an inventory. List everything that sends email in your domain's name: business email, e-invoicing software, CRM, newsletter service, website forms, printers and scanners.
2. Create a single SPF record. Collect all these sources in one record and start with ~all.
3. Enable DKIM. Get DKIM keys from your email provider and the other sending services and add them to DNS.
4. Publish DMARC in monitoring mode. Start with p=none and set a report address.
5. Review the reports for a few weeks. Sending sources you forgot about will show up in these reports. Add them to SPF and DKIM.
6. Tighten the policy gradually. Once all legitimate mail passes, move to quarantine and later to reject. To soften the transition, you can use DMARC's pct parameter to apply the policy to only a share of messages at first.

Common Mistakes

More than one SPF record

A domain can have only one SPF record. Adding a second "v=spf1" record for a new service instead of updating the existing one is a very common mistake, and it makes both records invalid.

The 10 DNS lookup limit

An SPF check may perform at most 10 DNS lookups. Every include, mx and a mechanism counts towards that limit, and nested includes count too. As you add more services the limit is exceeded and the SPF check returns an error. Remove services you no longer use and, where appropriate, list fixed IP addresses with ip4.

Starting DMARC at reject

Moving to a reject policy before your inventory is complete can cause legitimate mail such as invoices or notifications to be refused. Always start in monitoring mode.

Enabling DKIM only on the main provider

Third-party services such as newsletters and CRM should also sign with your domain using their own DKIM keys. Otherwise DMARC alignment fails.

Nobody reads the report address

DMARC reports arrive as XML and can be voluminous. You need a tool that makes them readable, or someone responsible for reviewing them regularly.

Authentication Alone Is Not Enough

Even with SPF, DKIM and DMARC set up correctly, emails can still sometimes land in spam. Watch these points too:

• Sending IP reputation: another user on a shared server sending spam can affect your mail from the same IP. Check blocklists regularly.
• List hygiene: mailing purchased lists or people who never opted in raises complaint rates and quickly damages your domain's reputation.
• Content: image-only emails, shortened links and exaggerated wording attract filters.
• Separating newsletters from everyday mail: sending bulk marketing from a separate subdomain protects the reputation of your day-to-day business correspondence.

Sender Rules of the Big Providers

Since early 2024, Google and Yahoo have applied stricter rules to senders, and Microsoft has announced similar requirements for Outlook.com. The general framework is:

• All senders are expected to use at least SPF or DKIM, have a valid reverse DNS record and connect over TLS.
• Bulk senders (in Google's definition, those sending more than 5,000 messages a day to Gmail addresses) must have SPF, DKIM and a DMARC record with at least a p=none policy, and the "From" address must be aligned.
• Marketing messages must offer one-click unsubscribe and keep spam complaint rates low.

Messages that do not meet these rules may land in spam or be rejected entirely. Even if you are a small business, a complete SPF, DKIM and DMARC setup is now a basic requirement.

If you are moving to business email, setting up these records as part of the migration is the easiest path.

Frequently Asked Questions

Is it enough to set up just one of SPF, DKIM and DMARC?

No. The three work together. SPF and DKIM verify identity, and DMARC makes sure that verification matches the "From" address and decides what happens when it fails.

I added the records. When do the changes take effect?

DNS records usually propagate within minutes to a few hours. Domain reputation can take a little longer to recover; with regular, clean sending you will typically see improvement within days or weeks.

How do I check that my records are correct?

Send a message to a Gmail address of your own and use "show original" to see the SPF, DKIM and DMARC results. Online DNS checking tools will also point out syntax errors in your records.

Will a DMARC reject policy block my legitimate email?

Not if your inventory is complete and every sending source is aligned through SPF or DKIM. That is why reviewing reports in monitoring mode before moving to reject is essential.

CloudRUX Business Email

Setting up SPF, DKIM and DMARC may look like a few DNS records, but the details decide deliverability. With CloudRUX business email, our engineers configure these records as part of setup, guide you through your DMARC rollout and, when something goes wrong, you have a Turkish-speaking engineer on the other end. Plans start at 1.19 USD per user per month (excluding VAT), with free setup and migration. See our business email page for details, or get in touch to look into your email delivery issues with us.