SPF, DKIM and DMARC explained (and why your mail goes to spam)

If your messages keep landing in spam, or someone is sending mail that pretends to come from your domain, the answer is almost always the same three DNS records: SPF, DKIM and DMARC. Together they let receiving servers verify that a message really came from you.

SPF: who is allowed to send

An SPF record is a TXT record listing the servers permitted to send mail for your domain. A receiving server compares the sending server against that list and treats unlisted senders with suspicion. A minimal record looks like v=spf1 include:_spf.yourprovider.com -all.

Two rules matter in practice. Publish one SPF record per domain — two records invalidate each other. And include every legitimate sender: your mail provider, but also any marketing platform, CRM or invoicing tool that sends on your behalf.

DKIM: proof the message was not altered

DKIM adds a cryptographic signature to each outgoing message. The private key stays on the sending server; the matching public key is published in your DNS. The recipient verifies the signature and knows both that the message came from your domain and that its content was not modified in transit.

Providers generate the key pair for you; your job is to publish the record they give you, at the selector name they specify.

DMARC: what to do when checks fail

SPF and DKIM report a result. DMARC decides what that result means. A starter record — v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com — asks for reports without changing how mail is treated. The policy value is the part that matters:

• p=none — monitor only, and send me reports
• p=quarantine — put failing mail in spam
• p=reject — refuse it outright

Start with p=none, read the aggregate reports for a few weeks until every legitimate sender passes, then tighten the policy. Going straight to reject is the classic way to lose invoices sent by a forgotten third-party tool.

Why mail lands in spam anyway

Authentication is necessary but not sufficient. Other common causes:

• A new domain with no sending history. Reputation builds over weeks; start slowly.
• Missing or invalid reverse DNS (PTR) for the sending server.
• Spam-trigger content: all caps subject lines, link shorteners, a single large image and no text.
• Poor list hygiene. Repeatedly mailing addresses that bounce damages reputation quickly.
• Shared IP neighbours. On cheap shared infrastructure, someone else's behaviour affects you.

How to check your setup

Send a message to one of the free mail-testing services and read the report: it shows SPF, DKIM, DMARC and PTR results plus a spam score. Command line tools work too — dig TXT yourcompany.com shows your SPF and DMARC records. Re-test after any DNS change.

Frequently asked questions

Do I need all three records? SPF and DKIM are the minimum. DMARC is what turns them into an enforceable policy and gives you visibility, so treat it as required rather than optional.

Will DMARC break my newsletters? Only if the sending platform is not authorised. Add each platform to SPF and set up DKIM for it before tightening the policy.

How long do DNS changes take? Usually minutes, occasionally up to 48 hours depending on TTL values and caching.

Can I use ~all instead of -all in SPF? ~all (softfail) is a gentle start. Once you are confident the list is complete, -all is stricter and better.

Authentication at imail.com.tr

On imail.com.tr business plans, SPF, DKIM and DMARC are part of adding your domain: the panel shows the exact records for your DNS and flags anything missing. See the business plans, or read our own-domain setup guide first.