SPF, DKIM, DMARC (Bonus: BIMI) — Setup from Scratch, Common Mistakes, and the Right Way

A single observation gave birth to this article: we've been reviewing hundreds of organizations' DNS records for years, and the most common sight is this — SPF exists but has blown past the 10-lookup limit; DKIM was "set up" once with a single selector and forgotten; and the DMARC record reads rua=mailto:[email protected]. The organization is simultaneously pouring reports into a mailbox nobody opens and broadcasting its most critical admin address to the entire world.

This is the first article of our Mail Technologies Series. Our goal is to do something different from the abundant "what is SPF?" definition posts online: a field-driven setup guide that even an IT manager who has never touched these records can read and apply, showing the common mistakes and the right way. At the end there's a bonus: BIMI — the standard that gets your verified brand logo displayed in the inbox.

1. Three Records, One Purpose: "Did You Really Send This Email?"

Before the technical detail, let's fix the division of labor in one paragraph. SPF declares which servers may send email on behalf of your domain ("only these servers speak for us"). DKIM adds a cryptographic signature to outgoing mail ("this email wasn't altered in transit and truly left us"). DMARC looks at the outcome of both and decides ("if SPF or DKIM fails, reject/quarantine the email and report to me"). Together they form the identity layer that prevents your domain from being impersonated.

2. SPF — How to Set It Up

Step by step

1. Take inventory: List everything sending mail from your domain — your mail platform (Microsoft 365 / Google Workspace), CRM, bulk email tool, accounting software, your website's form mails.

2. Write the TXT record: Add a TXT record at the root of your domain. A typical Microsoft 365 starting point:

   v=spf1 include:spf.protection.outlook.com -all

3. Add the other senders: One include: per legitimate sending service.
4. Finish with -all: It means "reject everyone not on the list." The soft ~all is for the transition period only; don't let it become permanent.

Common mistakes → the right way

• Mistake: exceeding the 10-lookup limit. The SPF standard allows at most 10 DNS lookups; every include: chain eats into this counter. Exceed it and SPF returns "permerror" — protection effectively collapses. The right way: prune unused includes and, where possible, use managed SPF (below).
• Mistake: multiple SPF records. A domain may have only one SPF TXT record; a second invalidates the whole structure. The right way: merge all senders into a single record.
• Mistake: broadcasting your entire sending infrastructure. A classic SPF record lets anyone read which CRM, which marketing tool, which servers you use — a ready-made reconnaissance report for an attacker. The right way: managed SPF / SPF flattening.

One level up: Managed SPF (a live example from our own domain)

Let's demonstrate with our own domain, kinetikbilisim.net — the record is public; anyone can query it:

v=spf1 include:25nfc2tit.spf.checkpoint-spf.com -all

Notice: no Microsoft visible, no CRM visible, no sending infrastructure visible at all. Just a single managed include. Check Point's SPF Management service dynamically manages all our legitimate senders on its side; when we add a new sending service, we don't even touch DNS. The result: our lookup count sits far below the limit (2/10), zero errors — and our sending infrastructure is entirely hidden from the outside. Security moves one level beyond "writing a correct SPF": the attacker's reconnaissance surface closes too.

3. DKIM — How to Set It Up

Step by step

1. Enable DKIM on your mail platform: In Microsoft 365 via the Defender portal (Email authentication settings); in Google Workspace via the Admin console.
2. Add the selector records to DNS: The platform gives you CNAME/TXT records like selector1._domainkey and selector2._domainkey; you enter them in DNS.
3. Turn on signing and verify: Send a test email and confirm DKIM=pass in the headers.

Common mistakes → the right way

• Mistake: setting the key once and forgetting it for years. If the same DKIM key never rotates, a single leak endangers all past and future traffic. The right way: periodic key rotation — ideally a management layer that automates it.
• Mistake: leaving third-party senders unsigned. CRMs and marketing tools need their own DKIM; without it, those emails fall out of DMARC alignment. The right way: a dedicated selector per sending service.
• Mistake: weak 1024-bit keys. The right way: 2048-bit keys.

One level up: Managed DKIM (again from our own domain)

Anyone looking at kinetikbilisim.net's DNS will see this: the _domainkey.kinetikbilisim.net subdomain is delegated via NS records to a managed DNS zone. This is Check Point DKIM Management's approach: all DKIM selectors live in a zone managed on our behalf; key generation, rotation, and adding new services run automatically. We don't enter and remove DNS records each time; there's no such thing as a forgotten selector, an expired key, or a copy-paste error. DKIM's biggest operational risk — human forgetfulness — leaves the equation.

4. DMARC — How to Set It Up (And the Most Critical Mistake Lives Here)

Step by step

1. Start in monitor mode: A TXT record at the _dmarc subdomain: v=DMARC1; p=none; rua=mailto:... — p=none blocks nothing; it only collects reports.
2. Watch the reports for 2–4 weeks: Identify which legitimate senders fall out of SPF/DKIM alignment and fix them.
3. Tighten gradually: p=quarantine (partially at first, e.g. pct=25), then p=reject. The destination is always reject; staying in p=none for years is like installing an alarm and muting it.

Common mistakes → the right way

• Mistake: adding only ruf without rua. DMARC's real value — the aggregate reports — travels via rua; ruf (forensic reports) is no longer sent by most major providers, including Gmail, for privacy reasons. An organization that defines only ruf believes "DMARC is set up" while receiving no reports at all — an alarm with its cable unplugged. The right way: rua must always be defined; ruf is optional.
• Mistake: adding default values to the record for no reason. Tags like pct=100, ri=86400, adkim=r, aspf=r are already the defaults; writing them gains nothing. They lengthen the record, hurt readability, and raise the risk of error in manual edits. The right way: write only the tags that deviate from the defaults. A short record is a clean record.
• Mistake: entering a duplicate DMARC record. The DMARC version of the duplicate-SPF mistake: if there's more than one TXT record under _dmarc, receiving servers treat the record as invalid and behave as if DMARC didn't exist. It usually happens when two tools/agencies add records unaware of each other. The right way: one record; always query the existing _dmarc TXT before adding a new one.
• Mistake: not testing after setup. If no verification is done once the SPF, DKIM, and DMARC work is finished, a typo, a missing selector, or an alignment issue can go unnoticed for weeks — while everything looks "set up." The right way: make the 5-minute verification below the standard final step of every deployment.

After setup: the 5-minute verification

The simplest test: send a test email from your domain to a Gmail address. Open the message → the three dots at top right → "Show original." Gmail shows the SPF, DKIM, and DMARC results on a single screen — you should see PASS on all three. If one says FAIL, the headers on the same screen tell you which layer the problem lives in.

Online verification tools: For deeper analysis, you can send a test email to — or run a domain query on — these tools:

• learndmarc.com — you send a test email to the address it gives you; it walks through the SPF/DKIM/DMARC evaluation step by step with a visual flow. Especially valuable for teams new to the topic.
• mail-tester.com — scores your test email out of 10; reports spam score and content issues alongside authentication.
• MXToolbox (Domain Health) and Google Admin Toolbox CheckMX — without sending any email, they check your SPF/DMARC records and overall DNS health in a single query.

The mistake we see most in the field: rua/ruf addresses

The rua (aggregate reports) and ruf (forensic/failure reports) addresses in a DMARC record are published in public DNS. And the most common sight in the field is this:

rua=mailto:[email protected]  or  rua=mailto:[email protected]

That single line produces two vulnerabilities at once. First: you broadcast your organization's most privileged mailbox, or a real employee's address format, to the whole world — a ready target for spear phishing and password spraying. Second, and more common: dozens of compressed XML reports land in that mailbox daily and nobody opens them. Even someone who does can't see the big picture from individual XMLs: the fact that "4,000 emails impersonating my domain were sent from Vietnam this week" stays invisible inside hundreds of files.

The right way: route the reports to a service whose job this is

rua/ruf addresses should point not to personal mailboxes, admin accounts on your own domain, or free third-party services of unclear provenance — but to the DMARC management service of a cybersecurity vendor you already work with. Two good examples by scale and need:

• Cloudflare DMARC Management (free): If your DNS is on Cloudflare, reports flow to a private address Cloudflare generates; the panel summarizes sources and pass rates in charts. Zero-cost "big picture" visibility for small and mid-size organizations.
• Check Point DMARC Management (professional): As part of Harmony Email & Collaboration; beyond collection and visualization, it offers end-to-end management under the same roof as the SPF Management and DKIM Management described above. Reports are collected on your behalf, sources are auto-classified, and the road to reject is run from the panel.

The rule is simple: have a system read the XML, not a human. DMARC's value isn't in the report — it's in making the report visible.

One small but important technical detail: when you route reports to an address outside your own domain, the DMARC standard requires the receiving side to publish an external destination verification record meaning "I accept reports on behalf of this domain" — otherwise many providers won't send reports at all. Frequently missed in manual setups, this step is configured automatically by managed services; it's also one of the most common answers to "why aren't my reports arriving?"

5. Bonus: BIMI — Your Logo in the Inbox

BIMI (Brand Indicators for Message Identification) is the visible reward for organizations that have taken DMARC to reject/quarantine: your verified brand logo is displayed next to your emails in Gmail and other supporting clients. Setup has three parts:

1. DMARC at least at p=quarantine (ideally reject),
2. your logo prepared in SVG Tiny-PS format,
3. a default._bimi TXT record — plus, for Gmail, a VMC (Verified Mark Certificate, proving the logo is your registered trademark).

By the way, if you've taken your DMARC to reject/quarantine, you've probably noticed: when you query your domain on MXToolbox, the tool now starts showing a [SUPPLEMENTAL] Brand Logo not appearing in inboxes warning. This isn't an error — it's an invitation. MXToolbox is telling you "your authentication is ready to display a logo, but you have no BIMI record." If you're seeing that warning, you've already completed BIMI's prerequisites.

BIMI's real value isn't aesthetic: the logo signals to recipients that "this domain has completed its authentication," making (logo-less) phishing emails easier to distinguish. Very few organizations in Türkiye have completed BIMI — a genuine inbox differentiation for early movers.

Frequently Asked Questions

How do I quickly check my domain's current state?

You can check all three records in minutes: a TXT query on your domain for SPF and on _dmarc.yourdomain.com for DMARC, and a query with your platform's selector for DKIM. Tools like MXToolbox do it on one screen. If you prefer, we produce a report card of all three — together with look-alike domain risk — as part of a free field audit.

Is staying at p=none really a problem? Isn't it better than no DMARC?

For collecting reports, yes — better than nothing. But in protection terms, p=none allows emails impersonating you to be delivered. p=none is not a destination; it's a transit station of a few weeks at most.

I set SPF to -all and some of our legitimate emails started landing in spam. What did I do?

Most likely a sending service was missed in the inventory (a web form, accounting software, an old CRM). This is exactly why DMARC reports exist: see all legitimate sources in the reports and bring them into SPF/DKIM alignment before moving to reject. With managed SPF, adding the new service in the panel is enough — you don't touch DNS.

Once all of this is set up, does phishing end?

No — and this needs to be said plainly. SPF/DKIM/DMARC stop the impersonation of your domain. Look-alike domains (like kinetlkbilisim.net), display name spoofing, and BEC from compromised real accounts fall outside these protocols. Above this layer you need behavioral analysis; details in our BEC article.

What Should You Do Now?

If you have five minutes: look at your domain's SPF record (lookup count? ends with -all?), then your _dmarc record (still p=none? where does rua point?). If any answer made you uncomfortable:

1. Free Field Audit: Your SPF/DKIM/DMARC/BIMI report card, with lookup analysis, the rua/ruf exposure, and look-alike domain risk.
2. Managed transition: Deployment of SPF Management, DKIM Management, and DMARC Management for your organization, with a staged roadmap from p=none to reject.

Schedule an intro meeting

About this article: This is the first article of our Mail Technologies Series; the next will cover email encryption with S/MIME and PGP. Kinetik Bilişim is the Türkiye partner of Check Point Software Technologies at the Advanced Partner 2026 level, holding Email, Endpoint & Browser, Mobile, and SASE Solution Specialization accreditations. The author, Kemal Özleyen, is a cybersecurity engineer certified as a Check Point Workspace Security Expert. The kinetikbilisim.net examples in this article are public DNS records.